IT用語集 2024/11/26

カミンスキー攻撃とは？ 10分でわかりやすく解説

コラム

カミンスキー攻撃は、DNSキャッシュポイズニングの代表例です。DNSリゾルバーへ偽の応答を先に受理させ、名前解決結果を改ざんします。現在は修正策が広く普及し、一般的な最新環境では成功しにくくなっていますが、古い機器、不適切な設定、運用上の制約が重なると同系統のリスクは残ります。確認対象は、DNSリゾルバーの更新状況、送信元ポートのランダム化、DNSSEC検証、参照先の統制です。

カミンスキー攻撃とは

カミンスキー攻撃とは、DNSリゾルバーのキャッシュへ偽のDNS応答を混入させ、ドメイン名と応答先の対応を攻撃者の意図した内容へ書き換える攻撃手法です。利用者は正しいドメイン名やURLを入力していても、偽サイトへ誘導される可能性があります。2008年にダン・カミンスキー氏が問題提起し、当時のDNS応答照合の弱点が広く認識されました。

何が危険か

この攻撃が厄介なのは、利用者側の操作ミスがなくても被害が起こり得る点です。DNSが通信の前提にあるため、名前解決結果が汚染されると、Web閲覧、メール、API連携など複数の通信へ影響が波及します。組織内で共通のDNSリゾルバーを使っている場合は、同じ誤った応答を複数の端末が参照するおそれがあります。

現在の位置づけ

現在の主要なDNS実装では、送信元ポートのランダム化や応答照合の強化が進み、2008年当時より成功難度は大きく上がっています。ただし、古いDNS機器、更新が止まったアプライアンス、ポート利用を狭めるネットワーク機器の設定、DNSSEC未検証の環境では、偽応答を受理する余地が残ります。過去の攻撃手法として片付けるより、DNS基盤の設定点検項目として扱う方が実務に合います。

DNSキャッシュポイズニングとの関係

DNSキャッシュポイズニングは大きな分類名で、DNSリゾルバーのキャッシュへ偽情報を混入させる攻撃全般を指します。カミンスキー攻撃は、その中でも成功確率を高めるやり方が注目された代表例です。特徴は、毎回異なるサブドメインへの問い合わせを大量に発生させ、偽応答を差し込む機会を何度も作る点にあります。

つまり、DNSキャッシュポイズニングが攻撃カテゴリ、カミンスキー攻撃はその具体的な成立手順として理解すると整理しやすくなります。

カミンスキー攻撃の仕組み

キャッシュにない名前を使って問い合わせを発生させる

攻撃者は、毎回異なる存在しないサブドメイン名を使い、DNSリゾルバーに上流DNSへの問い合わせを発生させます。キャッシュ済みの名前では上流へ出ていかないため、キャッシュにない名前を大量に作ることで、偽応答を差し込む機会を増やします。

偽応答を正規応答より先に送り込む

DNSでは、問い合わせと応答の対応付けにトランザクションID（TXID）が使われます。2008年当時は、この識別だけでは推測耐性が十分でない実装がありました。攻撃者は、正規の権威DNSから応答が返る前に、TXIDを当てた偽応答を大量送信し、DNSリゾルバーへ先に受理させようとします。

送信元ポートのランダム化で難度が上がった

主要な対策の一つが、UDP送信元ポートのランダム化です。現在は、TXIDに加えて送信元ポートも一致しなければ応答として受理しにくくなっており、推測対象が増えています。一方で、NATやファイアウォールの設定によって利用できるポート範囲が狭まると、この防御効果が落ちることがあります。

単発のAレコードだけで終わらない場合がある

影響はAレコードの改ざんだけに限りません。条件によっては、NSレコードなどの委任情報へ影響が及び、特定ドメイン配下の名前解決全体を攻撃者が用意したDNSへ向ける足がかりになることがあります。そのため、単発の誤誘導ではなく、継続的な誘導へつながる点が問題視されました。

問い合わせの誘発	毎回異なるサブドメイン名を使い、DNSリゾルバーから上流DNSへの問い合わせを何度も発生させます。
偽応答の送信	正規応答より先に、TXIDや送信元ポートの条件が一致する偽応答を大量に送り込みます。
キャッシュ汚染	DNSリゾルバーが偽応答を受理すると、不正な名前解決結果がキャッシュへ残ります。
被害の発生	利用者は正しいドメイン名やURLを入力していても、偽サイトや不正な接続先へ誘導される可能性があります。

組織で取るべき対策

DNSリゾルバーの更新と設定見直し

最優先は、DNSソフトウェアやアプライアンスの更新です。既知の弱点へ対処したバージョンを使い、送信元ポートのランダム化が有効か、応答照合の挙動が適切かを確認します。再帰問い合わせを必要な利用者だけに限定し、オープンリゾルバー化を避ける設定も欠かせません。

DNSSECの検証

DNSSECは、DNS応答へ署名を付与し、受信側で改ざんの有無を検証する仕組みです。対象ゾーンが署名され、DNSリゾルバー側で検証が有効になっていれば、偽応答の受理を防ぎやすくなります。ただし、導入では署名対象、鍵管理、失効対応、検証設定まで含めて設計する必要があります。

HTTPSとデジタル証明書検証を前提にした運用

DNSが改ざんされても、HTTPSの証明書検証が正しく機能すれば、多くのケースで偽サイトを正規サイトとして成立させにくくなります。それでも、利用者が警告を無視したり、別の手口と組み合わされたりすると被害に至る余地は残ります。ブラウザー警告を無視しない運用、重要システムへの多要素認証、接続元条件の確認を併用した方が被害を抑えやすくなります。

DNS参照先の統制と監視

端末が任意の外部DNSを参照できる状態では、社内で対策したDNSリゾルバーを迂回されることがあります。ネットワーク側でDNSの参照先を統制し、監視では大量のランダムサブドメイン問い合わせ、異常なNXDOMAIN比率、特定ドメインの解決先変化を検知できる状態にしておきます。

更新管理	DNSソフトウェアやアプライアンスを更新し、既知の弱点を残さない状態にします。
ポートランダム化	TXIDに加えて送信元ポートも推測対象にし、偽応答の一致確率を下げます。
DNSSEC検証	署名検証を通じて、改ざんされた応答を受理しにくい構成にします。
利用統制	端末のDNS参照先を統制し、オープンリゾルバー化や勝手な外部DNS利用を避けます。
監視	ランダムサブドメイン問い合わせ、解決先の急変、異常な失敗応答の増加を監視します。

被害とインシデント対応で見る点

攻撃が成功すると、偽サイトへの誘導により認証情報、個人情報、決済情報が入力されるおそれがあります。組織内の共通DNSリゾルバーが汚染された場合は、複数の利用者へ同時に影響が広がる可能性があります。インシデント対応では、DNSキャッシュのフラッシュ、正規の参照先確認、影響範囲調査、利用者への注意喚起、DNSログの保全を手順化しておくと初動が速くなります。

まとめ

カミンスキー攻撃は、DNSキャッシュへ偽応答を混入させるDNSキャッシュポイズニングの代表例です。現在は、送信元ポートのランダム化、実装修正、DNSSEC検証の普及で2008年当時より成功しにくくなっています。それでも、古い機器、更新不足、ポート利用を狭めるネットワーク設定、DNSSEC未検証の環境では同系統のリスクが残ります。組織として確認すべき点は、DNSリゾルバーの更新、送信元ポートの扱い、DNSSEC検証、参照先統制、監視体制です。