DNS スプーフィングは、 DNS キャッシュ ポイズニングとも呼ばれ、破損したドメイン ネーム システムデータをDNS リゾルバのキャッシュに導入し、ネーム サーバーがIP アドレスなどの誤った結果レコードを返すようにするコンピュータ セキュリティハッキングの一種です。これにより、トラフィックは攻撃者が選択した任意のコンピュータに 転送されます。
ドメインネームシステムの概要
ドメインネームシステムサーバーは、人間が読めるドメイン名(などexample.com)を、ノード間の通信のルーティングに使用される数値のIPアドレスに変換します。[1]通常、サーバーが要求された変換を認識していない場合は、別のサーバーに問い合わせ、プロセスが再帰的に続行されます。パフォーマンスを向上させるために、サーバーは通常、これらの変換を一定期間記憶(キャッシュ)します。つまり、同じ変換の別の要求を受信した場合、そのキャッシュの有効期限が切れるまで、他のサーバーに問い合わせることなく応答できます。
DNSサーバーが誤った変換を受信し、パフォーマンスの最適化のためにそれをキャッシュすると、DNSサーバーはポイズニングされているとみなされ、クライアントに誤ったデータを提供します。DNSサーバーがポイズニングされると、誤ったIPアドレスを返し、トラフィックを別のコンピューター(多くの場合、攻撃者のコンピューター)に転送する可能性があります。[2]
キャッシュポイズニング攻撃
通常、ネットワークに接続されたコンピュータは、インターネット サービス プロバイダー (ISP) またはコンピュータ ユーザーの組織が提供する DNS サーバーを使用します。DNS サーバーは、組織のネットワークで、以前に取得したクエリ結果をキャッシュすることで解決応答のパフォーマンスを向上させるために使用されます。単一の DNS サーバーに対するポイズニング攻撃は、侵害されたサーバーによって直接サービスを受けているユーザー、または該当する場合はその下流のサーバーによって間接的にサービスを受けているユーザーに影響を与える可能性があります。[3]
キャッシュ ポイズニング攻撃を実行するために、攻撃者はDNS ソフトウェアの欠陥を悪用します。サーバーは、DNS 応答が信頼できるソースからのものであることを確認するために、DNS 応答を正しく検証する必要があります (たとえば、DNSSECを使用する)。そうしないと、サーバーは誤ったエントリをローカルにキャッシュし、同じ要求を行う他のユーザーに提供してしまう可能性があります。
この攻撃は、ユーザーをウェブサイトから攻撃者が選択した別のサイトにリダイレクトするために使用できます。たとえば、攻撃者は特定の DNS サーバー上のターゲット ウェブサイトの IP アドレス DNS エントリを 偽装し、自分の管理下にあるサーバーの IP アドレスに置き換えます。次に、攻撃者は自分の管理下にあるサーバー上に、ターゲット サーバー上のファイルと一致する名前のファイルを作成します。これらのファイルには、通常、コンピューター ワームやウイルスなどの悪意のあるコンテンツが含まれています。汚染された DNS サーバーを参照しているコンピューターのユーザーは、偽のサーバーからのコンテンツを受け入れるように誘導され、知らないうちに悪意のあるコンテンツをダウンロードします。この手法はフィッシング攻撃にも使用できます。フィッシング攻撃では、本物のウェブサイトの偽バージョンが作成され、銀行やクレジット/デビット カードの詳細などの個人情報を収集します。
DNSキャッシュポイズニングに対するシステムの脆弱性は、直接的な影響にとどまらず、フィッシング、マルウェアの注入、サービス拒否、システムの脆弱性によるウェブサイトの乗っ取りなど、さらなるリスクにユーザーをさらす可能性があります。ソーシャルエンジニアリング戦術の使用からDNSサーバーソフトウェアに存在する弱点の悪用に至るまで、さまざまな方法がこれらの攻撃につながる可能性があります。[4]
バリエーション
以下のバリアントでは、サーバーのエントリns.target .example攻撃者のネームサーバのIPアドレスwxyzにリダイレクトされる。これらの攻撃では、ターゲット例はns.target.example。
攻撃を成功させるには、攻撃者はターゲット DNS サーバーに、攻撃者のネームサーバーの 1 つによって制御されるドメインへの要求を強制する必要があります。[引用が必要]
対象ドメインのネームサーバーをリダイレクトする
DNS キャッシュ ポイズニングの最初の変種では、攻撃者のドメインのネーム サーバーをターゲット ドメインのネーム サーバーにリダイレクトし、そのネーム サーバーに攻撃者が指定した IP アドレスを割り当てます。
DNSサーバーのリクエスト: アドレスレコードは何のためのものかサブドメイン.攻撃者.例?
サブドメイン.攻撃者.例. IN A
攻撃者の反応:
- 答え:
(応答なし)
- 権限セクション:
攻撃者.example. 3600 IN NS ns.target.example.
- 追加セクション:
ns.target.example.INAw.xyz
脆弱なサーバーは、追加のAレコード(IPアドレス)をキャッシュし、ns.target.example攻撃者はクエリを解決して、ターゲット例ドメイン。
NSレコードを別のターゲットドメインにリダイレクトする
DNS キャッシュ ポイズニングの 2 番目の変種では、元のリクエストとは無関係な別のドメインのネーム サーバーを、攻撃者が指定した IP アドレスにリダイレクトします。[引用が必要]
DNSサーバーのリクエスト: アドレスレコードは何のためのものかサブドメイン.攻撃者.例?
サブドメイン.攻撃者.例. IN A
攻撃者の反応:
- 答え:
(応答なし)
- 権限セクション:
ターゲット.example. 3600 IN NS ns.attacker.example.
- 追加セクション:
ns.attacker.example. IN A w.xyz
脆弱なサーバーは、無関係な権限情報をキャッシュし、ターゲット例のNSレコード(ネームサーバエントリ)を攻撃者が取得し、攻撃者がクエリを解決して、ターゲット例ドメイン。
予防と緩和
DNS サーバーに対するキャッシュ ポイズニング攻撃の多くは、他の DNS サーバーから渡される情報をあまり信頼せず、クエリに直接関係のない DNS レコードを無視することで防ぐことができます。たとえば、BIND 9.5.0-P1 [5]以降のバージョンでは、これらのチェックが実行されます。[6] DNS 要求の送信元ポートのランダム化と、送信元ポートと 16 ビットの暗号化 nonceの両方を選択するための暗号的に安全な乱数の使用を組み合わせると、DNS レース攻撃が成功する可能性を大幅に減らすことができます。[引用が必要]
ただし、ルーター、ファイアウォール、プロキシ、その他のゲートウェイデバイスがネットワークアドレス変換(NAT)、より具体的にはポートアドレス変換(PAT)を実行する場合、接続状態を追跡するために送信元ポートを書き換えることがあります。送信元ポートを変更すると、PATデバイスはネームサーバーとスタブリゾルバーによって実装された送信元ポートのランダム性を削除する可能性があります。[引用が必要] [7]
セキュア DNS ( DNSSEC ) は、信頼された公開鍵証明書で署名された暗号化デジタル署名を使用して、データの信頼性を判断します。 DNSSEC はキャッシュ ポイズニング攻撃に対抗できます。 2010 年に DNSSEC はインターネット ルート ゾーン サーバーに実装されましたが、[8]すべてのトップ レベル ドメインサーバーにも展開する必要があります。 これらの DNSSEC の準備状況は、インターネット トップ レベル ドメインのリストに示されています。 2020 年の時点で、すべてのオリジナル TLD は DNSSEC をサポートしており、ほとんどの大国の国コード TLD も同様ですが、多くの国コード TLD はまだサポートしていません。
この種の攻撃は、接続が確立されたらエンドツーエンドの検証を実行することで、トランスポート層またはアプリケーション層で軽減できます。一般的な例としては、トランスポート層セキュリティとデジタル署名の使用があります。たとえば、 HTTPS ( HTTPの安全なバージョン)を使用すると、ユーザーはサーバーのデジタル証明書が有効であり、Webサイトの想定される所有者に属しているかどうかを確認できます。同様に、セキュアシェルのリモートログインプログラムは、セッションを続行する前にエンドポイント(わかっている場合)でデジタル証明書を確認します。更新を自動的にダウンロードするアプリケーションの場合、アプリケーションは署名証明書のコピーをローカルに埋め込み、埋め込まれた証明書に対してソフトウェア更新に保存されている署名を検証できます。[9]
参照
参考文献
- ^ Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). 「分散型ドメインネームシステムキャッシュポイズニング攻撃の検出と識別のための情報融合ベースの方法」IET 情報セキュリティ. 10 (1): 37–44. doi :10.1049/iet-ifs.2014.0386. ISSN 1751-8717. S2CID 45091791.
- ^ Son, Sooel; Shmatikov, Vitaly. 「DNS キャッシュポイズニングのヒッチハイクガイド」(PDF)。コーネル大学。2017 年 8 月 14 日時点のオリジナルよりアーカイブ(PDF) 。2017年4 月 3 日閲覧。
- ^ Storms, Andrew (2006). 「ベンダーのソフトウェア配布方法を信用してはいけない」.情報システムセキュリティ. 14 (6): 38–43. doi :10.1201/1086.1065898X/45782.14.6.20060101/91858.8. S2CID 15167573 – ProQuest Central経由。
- ^ m. Dissanayake, IM (2018). 「DNS キャッシュポイズニング: その手法と対策のレビュー」2018 National Information Technology Conference (NITC) . pp. 1–6. doi :10.1109/NITC.2018.8550085. ISBN 978-1-5386-9136-6. 2024年1月31日閲覧。
- ^ 「BIND セキュリティ マトリックス」。ISC Bind。2011年 11 月 11 日時点のオリジナルよりアーカイブ。2011 年5 月 11 日閲覧。
- ^ 「ISC Bind Security」。ISC Bind。2011年11月11日時点のオリジナルよりアーカイブ。2011年5月11日閲覧。
- ^ Dearing, Christopher (2019). 「攻撃ベクトルとしての個人情報:プライバシーが米国国家安全保障の運用上の側面であるべき理由」 † Journal of National Security Law & Policy . 10 : 351–403. ProQuest 2395864954 – ProQuest経由。
- ^ 「Root DNSSEC」 ICANN/Verisign p. 1. 2017年9月10日時点のオリジナルよりアーカイブ。2012年1月5日閲覧。
- ^ 「サーバーを保護するための適切な構成」IONOS Digitalguide 。 2022年4月29日閲覧。
