この記事では、WiFiネットワークにMiTMを実装する別の方法について説明します 。これは最も簡単ではありませんが、機能します。 この記事を読む前に、 最初の部分をよく理解することを強くお勧めします。 最初の部分では、DHCPプロトコルの原理と、それを使用してクライアントとサーバーを攻撃する方法を説明しようとしました。
いつものように、この攻撃にはいくつかの制限があります。
- 攻撃されたアクセスポイントに接続する必要があります。
- ネットワーク上のブロードキャストトラフィックを聞くことができるはずです。
そして、それはどのように機能しますか？ 攻撃はいくつかの段階に分かれています。
- DHCP攻撃を飢v状態にします。
- WiFi DeAuthパケットを送信します。
- クライアントからのARP要求をインターセプトし、それらに応答してIPアドレスの競合を作成し、クライアントにDHCPDECLINEを送信するよう強制します。
- DHCPDISCOVERおよびDHCPREQUEST要求をインターセプトし、それらに応答します。
- 利益！
このスキームをさらに詳しく理解します。
DHCPの枯渇
攻撃を受けたWiFiネットワークに接続し、 DHCP飢v攻撃を実行して、空きIPアドレスのプールをオーバーフローさせます。
仕組み：
ブロードキャストDHCPDISCOVER要求を作成して送信すると同時に、DHCPリレーエージェントとして提示されます。 giaddr （リレーエージェントIP）フィールドで、IPアドレス192.168.1.172を chaddr （クライアントMACアドレス）フィールドで指定します-ランダムMAC 00：01：96：E5：26：FCと同時に、 SRC MACを設定しますMACアドレス： 84：16：F9：1B：CF：F0 。
サーバーはDHCPOFFERメッセージでリレーエージェント（us）に応答し、クライアントにMACアドレス00：01：96：E5：26：FC IPアドレス192.168.1.156を提供します。
DHCPOFFERを受信した後、ブロードキャストDHCPREQUEST要求を送信し、DHCPオプションでコード50（ 要求されたIPアドレス ）でクライアントIPアドレス192.168.1.156をオプションコード12（ ホスト名オプション ）-ランダム文字列dBDXnOnJに設定します。 重要： DHCPREQUESTおよびDHCPDISCOVERのxid （トランザクションID）およびchaddr （クライアントMACアドレス）フィールドの値は同じである必要があります。そうでない場合、サーバーは同じクライアントからの別のトランザクションまたは同じトランザクションを持つ別のクライアントのように見えるため、リクエストをドロップします。
- サーバーはDHCPACKメッセージをリレーエージェントに送信します 。 これ以降、IPアドレス192.168.1.156は、MACアドレス00：01：96：E5：26：FCを12時間 （デフォルトのリース時間）持つクライアント用に予約されていると見なされます。
WiFi DeAuth
次のステップはWi-Fi Deauthです。 このスキームは次のように機能します。
無料のワイヤレスインターフェイスを監視モードにする：
攻撃されたクライアントを切断するために認証解除パケットを送信します84：16：F9：19：AD：14 WiFiネットワークESSID： WiFi DHCP MiTM ：
DHCPDECLINE
クライアント84：16：F9：19：AD：14がアクセスポイントから切断された後、おそらく、WiFiネットワークWiFi DHCP MiTMへの接続を再試行し、 DHCP経由でIPアドレスを取得します。 彼は以前にこのネットワークに接続していたため、ブロードキャストDHCPREQUESTのみがポイズニングします。
クライアントのリクエストを傍受しますが、もちろん、アクセスポイントよりも速く応答することはできません。 したがって、クライアントは以前に受信したDHCPサーバーからIPアドレス192.168.1.102を受信します。 次に、 ARPプロトコルを使用するクライアントは、ネットワーク上のIPアドレスの競合を検出しようとします 。
当然、このようなリクエストはブロードキャストされるため、インターセプトして応答できます。
その後、クライアントはIPアドレスの競合を修正し、 DHCP失敗メッセージ-DHCPDECLINEを送信します 。
DHCPDISCOVER
そして、攻撃の最終段階。 DHCPDECLINEを送信した後、クライアントは最初からIPアドレスを取得する手順を実行します。つまり、ブロードキャストDHCPDISCOVERを送信します。 正当なDHCPサーバーはこの要求に応答できません。これは、 DHCP枯渇攻撃後に空きIPアドレスのプールがいっぱいになり、したがって大幅に速度が低下するためです。ただし、DHCPDISCOVER- 192.168.1.172に応答できます。
クライアント84：16：F9：19：AD：14 （Win10デスクトップ）はブロードキャストDHCPDISCOVERを送信します：
DHCPOFFERに答えます：
DHCPOFFERでは 、クライアントにIPアドレス192.168.1.2を提供しました。 私たちからのみこのオファーを受け取ったクライアントはDHCPREQUESTを送信し、 要求されたIPを192.168.1.2に設定します。
クライアント84：16：F9：19：AD：14 （Win10デスクトップ）はブロードキャストDHCPREQUESTを送信します：
DHCPACKに答えます ：
クライアントはDHCPACKを受け入れ、そのIPアドレスをデフォルトゲートウェイおよびDNSサーバーとして設定します ： 192.168.1.172、2秒後にアクセスポイントから送信されたDHCPNAKは単に無視されます。
質問：アクセスポイントが2秒後に DHCPOFFERとDHCPNAKを送信し、クライアントが拒否したために同じIPアドレス192.168.1.102を提供したのはなぜですか？
この質問に答えるために、WireSharkのフィルターを少し変更して、アクセスポイントからのARP要求を見てみましょう。
回答： DHCP枯渇攻撃の後、DHCPサーバーには、クライアントのいずれかによって拒否されたIPアドレス192.168.1.102以外に、空きIPアドレスがありませんでした。 したがって、DHCPDISCOVER要求を受信すると、DHCPサーバーは2秒以内に3つのARP要求を送信して、誰がIPアドレス192.168.1.102を使用しているかを確認します。答えなかった、クライアントにそれを与えます。 しかし、すでに遅すぎたため、攻撃者はなんとかより速く応答することができました。
結果：
したがって、ネットワークパラメータ、つまりデフォルトゲートウェイ、DNSサーバーなどを、攻撃されたWiFiネットワークの接続済みまたは新規クライアントに設定できます。ただし、既に接続されており、ブロードキャストトラフィックをリッスンできる場合に限ります。
MacOS SieraおよびWindows 10に対する攻撃のビデオ：