☰

カミンスキーのバグ - 管轄区域

tag-icon • tag-icon security domain-name-system
カミンスキーのバグ - 管轄区域

私はカミンスキー DNS バグについて読んで、それがどのように機能するかをよりよく理解しようとしています。要点は理解していると思いますが、Dan は、ファイアウォールの背後にある DNS サーバーをターゲットにするために使用される bailiwicks について言及しています。

誰か、bailiwick とは何かを説明し、それがファイアウォールの背後にあるサーバーをターゲットにして kaminsky バグを悪用するためにどのように使用されるかの例を挙げてもらえますか?

答え1

管轄区域

Linuxジャーナル記事それエティヤルこの記事には、管轄権とは何か、DNS とどのように関係するかについて非常によく説明されています。基本的に、DNS 応答に追加のレコードが追加され、委任 DNS サーバーを見つけやすくなります。記事から例を引用すると、次のようになります。

$ dig @ns1.example.com www.example.com
;; ANSWER SECTION:
www.example.com.    120      IN    A    192.168.1.10

;; AUTHORITY SECTION:
example.com.        86400    IN    NS   ns1.example.com.
example.com.        86400    IN    NS   ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    604800   IN    A    192.168.2.20
ns2.example.com.    604800   IN    A    192.168.3.30


攻撃

攻撃の詳細はダンのスライド(スライド 24/25 を参照) ファイアウォールの背後にあるサーバーを攻撃するには:

  • 攻撃者が制御するドメインのサブドメイン (例: ' 1.badguy.com') の検索がトリガーされます。
  • 攻撃サーバーは、ポイズニングしようとしているドメインの CNAME レコード (例: ' debian.org') で応答します。これにより、ターゲットから ' debian.org' への DNS クエリが発生します。
  • 攻撃サーバーが CNAME 参照を送信するとすぐに、追加の応答 (たとえば、' security.debian.org' の IP アドレスを指す ' badguy.com') を含む偽装された DNS 応答のストリーミングが開始されます。
  • 応答内のトランザクション ID が正しく推測された場合、ファイアウォールの背後にあるサーバーは、「security.debian.org」が悪意のあるユーザーのアドレスに解決されると考えます。

ファイアウォールの背後にあるサーバーにIPアドレス、内部クライアントリクエスト、サーバーログ内のIPアドレスの解決などを検索させる方法はたくさんあります。ボルツマイヤーこの攻撃ではファイアウォールはほとんど無関係であると述べています。

答え2

マーク・ジョンソンが述べたように、DNSサーバーの管轄範囲とは、そのサーバーが権限を持つドメインの集合です。かつて、再帰ネームサーバーは、権限を持つネームサーバーから管轄外のデータを受け入れていました。そのため、foo.exampleの権限を持つネームサーバーは、www.bar.exampleのIPアドレスを示す追加データを応答に追加することができ、それが信頼されました。これが、カシュプレフ攻撃長い間、ネームサーバーは管轄外のデータを信じなくなりました。RFC 2181、セクション5.4.1。

カミンスキー攻撃はない管轄外のデータを使用するため、最近のネームサーバーでも機能しました。 LinuxジャーナルLuke Quinane 氏が言及した記事では、この点について非常にわかりやすく説明されています (ただし、Luke Quinane 氏の投稿の残りの部分、特にファイアウォールに関する部分は疑問が残ります)。

ファイアウォールに関しては、これはほとんど関係のない問題です。ネーム サーバーがクエリに対する応答を受信する場合、そのサーバーは到達可能である必要があるため、ファイアウォールがあるかどうかは関係ありません。カミンスキー攻撃には、DNS チャネルという 1 つのチャネルだけが必要です。

カミンスキー攻撃はクライアント マシンが使用するネーム サーバーに対して行われるため、これらのマシンがファイアウォールによって保護されているかどうかは関係ありません。(ファイアウォールが魔法のデバイスではなく、すべてを保護できるわけではない理由を示す良い例です。)

関連情報