dns-rebinding-attacks

概要dns-rebinding-attacks

本ガイドは、被害者がすでに読み込んだホスト名の背後にあるIPアドレスを変更することで、ブラウザの同一生成元ポリシーを迂回するクライアントサイドの手法に焦点を当てた、DNSリバインディング攻撃の手引書です。その核心となる洞察は、同一生成元ポリシーがチェックするのはホスト名の文字列であり、解決されたIPアドレスではないという点にあります： 自身のドメインの権威DNSを制御する攻撃者は、最初の解決時（攻撃者のIP）に悪意のあるJavaScriptを配信し、その後同じホスト名を内部IPに再解決することで、ブラウザが内部サービスへのリクエストを同一オリジンとして扱い、スクリプトがレスポンスを読み取れるようにすることができます。

DNSリバインディングはSSRFのクライアントサイド版にあたるため、本稿ではSSRFとの違いを明確にし、実用上の課題や回避策について詳述しています。 ブラウザは、短いTTL（Chrome、Edge、Firefoxではおよそ60秒）を無視する独自のDNSキャッシュを保持しているため、本稿では、キャッシュの有効期限切れを待つ手法、攻撃者のIPをブロックした複数のAレコード応答によるフォールバックの強制、新しい解決を行うためのサブドメインへのフラッディング、およびサービスワーカーによる遅延など、キャッシュを迂回する戦略について記載しています。 攻撃のバリエーションには、従来のHTTPリバインディング、WebSocketリバインディング、サーバーサイドTOCTOUとのハイブリッド、および高速な複数Aレコードアプローチが含まれます。

この手法は、オリジンチェックにDNSを信頼しているアプリケーションや、攻撃者が制御するドメインに対してクライアント側でfetch/XHRを行うアプリケーションをテストする際に活用してください。特に、サーバーサイドSSRFが実行不可能な場合に有効です。高価値な標的のリストには、クラウドメタデータ（169.254.169.254）、 DockerおよびKubernetes API、内部管理パネル、Elasticsearch、Redis、Consul/etcdが記載されており、IMDSv2のトークン要件については、no-corsモードではカスタムヘッダーを容易に設定できないため、リバインディングが困難であるとの注記がある。 対象となるツールには、Singularity、セットアップ不要の rbndr.us サービス（16進数IP形式のサブドメインを使用）、whonow、および最小限のPython DNSサーバーが含まれており、SSRFおよびCORSの設定ミスに関するスキルと相互参照されている。

FAQ

DNSリバインディングはSSRFとどう違うのですか？

SSRFはサーバーサイドの攻撃であるのに対し、DNSリバインディングは被害者のブラウザ上で実行されるクライアントサイドの攻撃です。これは、同一オリジンポリシーが解決されたIPではなくホスト名文字列をチェックするという点を悪用しています。

TTLを0に設定しても、なぜすぐに機能しないのですか？

ブラウザは独自のDNSキャッシュを保持しており、低いTTL（Chrome、Edge、Firefoxでは約60秒）を無視するため、このスキルでは、待機、フォールバック付きの複数のAレコード、サブドメインのフラッディング、サービスワーカーによる遅延などの回避策を網羅しています。

価値の高い内部ターゲットにはどのようなものがありますか？

169.254.169.254 にあるクラウドメタデータ、Docker API、Kubernetes API、内部管理パネル、9200 ポートの Elasticsearch、6379 ポートの Redis、および Consul/etcd です。

リバインディングによってIMDSv2からAWSの認証情報を盗み出すことは可能か？

簡単にはできません。IMDSv2ではPUTリクエストに対して「X-aws-ec2-metadata-token」ヘッダーが必要ですが、no-corsモードでは、リバインディングによって初期のトークンリクエストにカスタムヘッダーを設定することは容易ではありません。IMDSv1の方が脆弱性が高くなります。

どのようなツールが推奨されていますか？

Singularity（フルフレームワーク）、rbndr.us（セットアップ不要、16進数のIPペアのサブドメインを使用）、whonow（動的なリバインディングサーバー）、および最小限のカスタムPython DNSサーバーです。