web-dev-qa-db-ja.com

スプーフィングされたDNSパケットが無視されるのはなぜですか？

まず、この質問は教育目的のみを目的とした私的なプロジェクトに言及していることを明確にしておきます。

自分で「DNSスプーフィング」を書いてみました。心配しないでください。この質問はコーディングの慣行とは関係ありません。

現在の設定

オペレーティングマシンはローカルネットワーク内のMacBook（OSX付き）です（したがって、他にも重要でないデバイスがいくつかあります）。ローカルDNSサーバーとして別のマシン（ローカルネットワーク内）を使用する基本的なルーターがあります。この設定は少し珍しいですが、問題（以下で説明）の原因ではないはずです。

目標

DNSスプーフィング-MacBookがDNS要求を送信するとき、偽のIPアドレスで応答を送信します。

私の現在のアプローチ

BPF（ Berkeley Packet Filter ）を使用して、データリンク層への生のアクセスを取得します。

今、私はMacBookのイーサネットネットワークインターフェース（以下の部分では「MB」と呼びます）でクエリをリッスン/キャプチャしています。

MBでIPv6を無効にしました。

次のコマンドを使用して、MBのDNSキャッシュを削除します。

Sudo killall -HUP mDNSResponder;Sudo killall mDNSResponderHelper;Sudo dscacheutil -flushcache

手順

  1. MBはいくつかのクエリでDNS要求を送信します
  2. すべてのAタイプ（IPv4）クエリに対して同じクエリと回答を使用してDNS応答を作成し、この応答を送信します
  3. MBは2つの応答を受信します。最初に私の偽の応答、次に実際のローカルDNSサーバーによって送信された実際の応答です。

各偽のDNS応答パケットには次のものが含まれます。

  • イーサネット送信元アドレスとして要求されたDNSサーバーのイーサネットMACアドレス
  • 要求されたDNSサーバーのIPアドレスをIP送信元アドレスとして
  • 送信元ポートとしてのポート53
  • dNS要求の発信元の宛先ポートとしてのポート
  • 正しいIPヘッダーチェックサム
  • 正しいUDPチェックサム
  • 正しい フレームチェックシーケンス/イーサネットチェックサム 。

各DNS応答は、私が聞いているのと同じネットワークインターフェイスを介して送信されます。

クエリが送信されるたびに、2つの応答があります。

  1. 「DNSスプーフィング」によってすぐに送信された最初のパケット、「偽の」パケット/ DNS応答は、2番目の前に到着します
  2. 2つ目は、ローカルDNSサーバーによって送信される「実際の」DNS応答です。

私はまた仮定（これについてはよくわかりませんが）OSXは常にドメイン名をIPアドレスに解決するために取得する最初のDNS応答を選択します。

これを要約すると、チェックサムとDNS応答IPアドレスが異なることを除いて、両方のDNS応答は同じです。 また、「実際の」DNSサーバーは（何らかの理由で）FCS（フレームチェックシーケンス）を送信しません。計算されておらず、ゼロに設定されている（ゼロに設定されている）だけですが、私はそうします。

問題

OSXは、偽のDNS応答を無視しているようです。また、OSに過度の負担がかかっている可能性もあります。 Safariを使用してWebサイトを開くときの動作は次のとおりです。

Safariを使用して、アドレスバーに「 http://some-url.com "」と入力しても、何も起こりません。実際のサイトに接続したり、偽のページに接続したりすることはありません。ページは永久に読み込まれるようです。時々、10年後、それは実際のページに接続します。

例（ Wireshark でキャプチャ）

ランダムな例。

Request: 
0000   b8 27 eb b9 a0 0f a0 ce c8 10 75 8c 08 00 45 00   
0010   00 33 74 2c 00 00 ff 11 62 06 c0 a8 b2 1f c0 a8   .3t,..ÿ.b.À¨².À¨
0020   b2 16 f2 7e 00 35 00 1f 49 71 67 00 01 00 00 01   ².ò~.5..Iqg.....
0030   00 00 00 00 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01                                                .



Fake Response:
0000   a0 ce c8 10 75 8c b8 27 eb b9 a0 0f 08 00 45 00   
0010   00 43 12 34 00 00 40 11 82 ef c0 a8 b2 16 c0 a8   .C.4..@..ïÀ¨².À¨
0020   b2 1f 00 35 f2 7e 00 2f 46 44 67 00 81 80 00 01   ²..5ò~./FDg.....
0030   00 01 00 00 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01 c0 0c 00 01 00 01 00 00 07 08 00 04 ac d9 17   .À...........¬Ù.
0050   8e 22 4f 80 1c                                    ."O..



Real Response:
0000   a0 ce c8 10 75 8c b8 27 eb b9 a0 0f 08 00 45 00   
0010   00 7c 9c 19 40 00 40 11 b8 d0 c0 a8 b2 16 c0 a8   .|..@.@.¸ÐÀ¨².À¨
0020   b2 1f 00 35 f2 7e 00 68 83 00 67 00 81 83 00 01   ²..5ò~.h..g.....
0030   00 00 00 01 00 00 01 32 03 63 6f 6d 00 00 01 00   .......2.com....
0040   01 c0 0e 00 06 00 01 00 00 03 84 00 3d 01 61 0c   .À..........=.a.
0050   67 74 6c 64 2d 73 65 72 76 65 72 73 03 6e 65 74   gtld-servers.net
0060   00 05 6e 73 74 6c 64 0c 76 65 72 69 73 69 67 6e   ..nstld.verisign
0070   2d 67 72 73 c0 0e 5c 83 f7 73 00 00 07 08 00 00   -grsÀ.\.÷s......
0080   03 84 00 09 3a 80 00 01 51 80                     ....:...Q.

1]2]

どんな助けでも非常に高く評価されています。詳細が必要な場合はお知らせください。賞金をご希望の場合はお知らせください。

networkingmacosdnsspoofing
3
user0800

まず、イーサネットフレームには常にFCSが接続されていますが、受信したフレームをホストに渡すときにすべてのイーサネットNICがFCSを接続したままにするわけではありません。つまり、スニファはFCSを常に認識したり、有効か無効かを知ることができません。 。

したがって、FCSを正しく取得する必要があります。

インジェクター/スプーファーデバイスのプラットフォーム上のBPFのバージョン、またはそのNICドライバーまたはハードウェア）が、省略した場合に正しいFCSを計算するという事実がわからない場合または、ゼロで埋める場合は、おそらく最初にそれを理解する必要があります。正しく設定されていない状態でパケットを挿入しようとすると、修正されないため、自分で計算して挿入する必要があります。 bpf_write（）を実行する前に、パケットバッファの最後にある正しい値。

次に、16進ダンプを目で確認しているだけですが、精神的に正しくデコードしている場合、DiffServフィールドは偽物に見えます。どうしたらよいかわからない場合は、デフォルトで0xffではなく0x00に設定します。

第三に、IPの全長フィールドは偽物（ゼロ）に見えます。おそらくそれを計算して正しく設定する必要があります。チェックサムを計算する前に、必ずそれを行ってください。

他に何も私に飛び出しません。ですから、もし私があなたなら、これら3つの問題を修正して、もう一度やり直します。

4
Spiff