web-dev-qa-db-ja.com

arpspoofで偽装されたアドレスに接続できないのはなぜですか？

Webサイトとブラウザの組み合わせのうち、（HSTSを実装したり、クリアテキストHTTPを完全に無効にしたりすることによる）tlsストリッピング攻撃に対して依然として脆弱な組み合わせがいくつあるのかを知りたいと思っていました。それを行うには、sslstripツールを使用して直接確認したかったのですが、（プロジェクトページ自体の指示に従って）機能させることができませんでした。ターゲットPCはもう閲覧できないため、ARPスプーフィングは明らかに正常に機能しています、しかしsslstripは何も受け取りません。

TCPソケットをiptablesによってリダイレクトされたポートでリッスンしようとしましたが、何も受信しなかったため、iptablesも除外しましたが、使用しているポートで直接接続を受信しようとしています。被害者のクライアントによるものです。IP転送の有効化と無効化の両方を試みました（/proc/sys/net/ipv4/ip_forward）、および攻撃ホストからのインターフェースとしてwifiまたはイーサネットを使用しますが、何も変更されません。

これは私が攻撃ホストから使用しているコマンドです（アドレス192.168.1.33ホスト名macbook、Linux 3.11ボックス）：

Sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

（192.168.1.1はゲートウェイです）

Sudo socat TCP4-LISTEN:80 STDOUT

被害者のホスト（192.168.1.31）：

socat - TCP4:192.168.1.1:80

接続を開くことはできますが、何かを試みても、攻撃しているホストには何も届きません（攻撃者のIPアドレスをsocatに指定すると、明らかに機能します）。

tracerouteは、明らかにARPスプーフィングが成功していることを示しています。

> traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 Hops max, 60 byte packets
 1 macbook.local (192.168.1.30) 2.719ms 5.932ms *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 [snip]
28 * * *
29 * * *
30 * * *

arp -n被害者のホストからの出力

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.33             ether   00:1d:4f:fc:af:fc   C                     wlan0
192.168.1.1              ether   00:1d:4f:fc:af:fc   C                     wlan0
networkman-in-the-middlearp-spoofing
3
berdario

IPの衝突が発生しています。 192.168.1.31は次のコマンドで192.168.1.1であると確信していますが（ルーティングテーブルに影響を与えたことを意味します）：

Sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

... 192.168.1.1は依然として192.168.1.1を認識しているため、独自のIPに対するarp要求を検出すると、マシンとルーターの両方がMACアドレスで応答します。受信した最初のMACアドレスは、パケットを取得するためのものです（arp -nに有害なIPのエントリが表示されるため、そのIPに対するarp要求は必ず停止するとは考えないでください）。また、犠牲ＰＣにパケットを送信しないこと、またはそのＰＣから来たように見える他のパケットに応答することを知らない。

通常、man-in-the-middleは「中間」なので、次のことを試してください。

Sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

Sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.31

2つ目は、元の犠牲マシンではなく、IP 192.168.1.31宛てのパケットを送信するようにルーターに指示します。犠牲マシンがそのマシンの実際のMACアドレスを含む実際の192.168.1.1からパケットを取得した場合、その動作はどうなるか知っていますか？そのため、真ん中にいると想定しているため、実際の192.168.1.1から192.168.1.31宛てのパケットをリダイレクトして、この可能性を回避するのが最善です。

1
user34445