web-dev-qa-db-ja.com

ARPポイズニングとポートフォワードを一緒に

次の仮定を想定します。

ルーターのIPアドレス：192.168.1.1

ルーターのMACアドレス：00：00：00：00：00：

私のIPアドレス：192.168.1.2

私のMACアドレス：00：00：00：00：00：01

被害者のIPアドレス：192.168.1.

被害者のMACアドレス：00：00：00：00：00：

ルーターと被害者の間でEttercapを使用してARPポイズニング攻撃を実行した場合、被害者が外部ホストにパケットを送信したい場合、次のようになります。

被害者は、（wiresharkが示す内容に従って、パケットを送信します）：

ソースIP：192.168.1.3

ソースMAC：00：00：00：00：00：03

宛先：IP「DEST」。 「DEST」は「47.32.1.6」などの外部IPです。

宛先MAC：00：00：00：00：00：01

パケットは外部ホストに配信される必要があるため、被害者の視点からのMACアドレスが'00：00：00：00：00であるルーターに最初に配信される必要があります：01 '

ルーターはこのパケットを受信し、MACが私を（攻撃者として）指し示しているため、パケットをインターフェースに転送します。

Ettercapはパケットを取得し、送信元IPを被害者のIP（「192.168.1.3」）として認識し、宛先IPをルーター（2番目の被害者）として認識し、このパケットを送信してパケットを実際のホストに転送し、ストリーミングを許可します。

ソースIP：192.168.1.3
ソースMAC：00：00：00：00：00：01
宛先IP：DEST
宛先MAC：00：00：00：00：00：00

このプロセスは、被害者からEttercapに受信するすべてのパケットに対して行われますが、IPtablesルールによるポート転送を使用する場合、被害者から私のマシンに受信したパケットは、ルーターに2回送信する必要があるようです。

  1. Ettercapはパケットを受信し、それが被害者からである限り、ルーターに転送します。

  2. OSは、事前定義されたポートでリッスンしているローカル実行アプリにパケットを配信します。たとえば、次のコマンドを使用するとします。

    iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

次に、ポート80をターゲットとするパケットは、8080でリッスンしているローカルアプリに配信され、アプリは外部ホストにパケットを送信できます。 （たとえば、プロキシの場合）

しかし、驚くべきことに、これは起こりません。実際に発生するのはステップ2のみです。パケットはローカルアプリに配信され、先に処理されます。

これは、OSが受信パケットの「宛先IPアドレス」をインターフェースIPアドレスに変更するためだと思います。Ettercapがパケットをキャッチし、宛先IPが自分のマシンのアドレスであることを検出すると、パケットを無視します。ただし、Wiresharkは変更されたIPアドレスではなく、正しいIPアドレスを表示します。何人かの専門家がここで正確に何が起こるか説明できますか？

networkman-in-the-middlewiresharkarp-spoofing
4
CS.

パート1：一般的な説明。質問を読んだ場合は読む必要はありません。

最初の（パケットが攻撃者に到着する方法）：

被害者は、送信元IP '192.168.1.3'および送信元MAC '00：00：00：00：00：03 'のパケットを宛先IP' DEST 'および宛先MAC '00：00：00：00：00：01'に送信します。ここで、「DEST」は「47.32.1.6」のような外部IPです。ルーターはパケットを受信します。MACが私を指しているため（攻撃者として）、パケットはインターフェースに転送されます。

被害者は、送信元IP '192.168.1.3'および送信元MAC '00：00：00：00：00：03 'のパケットを宛先IP '47 .32.1.6'に送信します。被害者はこのアドレスへの直接ルートを見つけることができないため（サブネットにないため）、デフォルトルート経由でパケットを「192.168.1.1」（この場合、デフォルトゲートウェイ、この場合はルーター）に送信します。ただし、イーサネット上にいるため、被害者はパケットを送信するためにMACアドレスを必要とします。あなたはルータがMACアドレス'00：00：00：00：00：00 'を持っているが、攻撃者が被害者のARPテーブルを汚染したと述べました。エントリの代わりに

192.168.1.1           00:00:00:00:00:00

被害者のARPテーブルには次のエントリがあります。

192.168.1.1           00:00:00:00:00:01

（これは、被害者のPCでコマンドラインを開いて、Ettercapを起動する前後にコマンド「arp -a」を実行することで確認できます）。

これは、被害者がルーターにパケットを送信しようとするときは常にOR=が外部ネットワークに送信されると、被害者を「RE-ARP」するまで、このパケットが攻撃者に到達することを意味します。

2番目（パケットが実際の宛先に到着する方法）：

Ettercapはパケットを取得し、送信元IPを被害者のIP（「192.168.1.3」）として認識し、宛先IPをルーター（2番目の被害者）として認識し、このパケットを送信してパケットを実際のホストに転送し、ストリーミングを許可します。

攻撃を開始する前に、攻撃者は次のように、ARPテーブルに正しいエントリが含まれていることを確認します。

192.168.1.1           00:00:00:00:00:00 (the router)
192.168.1.3           00:00:00:00:00:02 (the victim)

ここで、最初のセクションでは、外部パケットが攻撃者のPCに到着した時点で停止しましたが、もちろん、パケットが「実際の」宛先に到達することを確認する必要があります。さもなければ、被害者は本当の反応を決して得ないでしょう、そしてそれで何かがオフであることをかなりすぐにそれに気づくでしょう。したがって、攻撃者はパケットを実際の宛先であるデフォルトゲートウェイ（ルーター）に転送しようとしています。攻撃者はルーターの実際のMACアドレスを知っているため、これは可能です。被害者から次のパケットを実際に受信します。

ソースIP：192.168.1.3
ソースMAC：00：00：00：00：00：03
宛先IP：47.32.1.6
宛先MAC：00：00：00：00：00：01
宛先IPが攻撃者のMACアドレスに変換されるという事実は、被害者が宛先IPをルーティングテーブル（ルートプリント）で検索し、このパケットを送信する必要があることが判明したためですデフォルトゲートウェイ。したがって、ARP要求を送信し（または彼のARPテーブルarp -aを参照）、パケットの送信先のMACアドレスが'00：00：00：00：00：01 'であることに気付きます。

ここで重要なのは、攻撃者がこれが実際には自分宛ではないパケットであることを認識しているという事実です。彼を対象としたパケットは次のようになります。

ソースIP：192.168.1.3
ソースMAC：00：00：00：00：00：03
宛先IP：192.168.1.2
宛先MAC：00：00：00：00：00：01

したがって、攻撃者がパケットを受信するたびに、送信元と宛先のIPを確認し、無害化されたARPテーブルを使用して、この場合は「00：00：00：00：00：00」（ルーター）に転送します。

パート2：質問の要約

最初は、質問が完全に明確ではありませんでした。ただし、CSがチャットでそれをより慎重に説明した後、問題は次のようになります。Ettercapがアクティブで、ポート8080でリッスンしているカスタムアプリケーションがトラフィックを（被害者に）アクティブに転送している設定と、ポート転送ポート80に着信するトラフィックをポート8080（カスタムアプリ）にリダイレクトするためにアクティブですが、これらのパケット（元々はポート80を対象としたもの）が一度だけ被害者に到着するのはなぜですか？

次のようなことが起こると思われるかもしれません：-パケットはポート80に着信し、実際には被害者向けですが、ARPポイズニング攻撃により攻撃者にリダイレクトされます-Iptablesはこのパケットをポート8080にリダイレクトします-Ettercapがパケットを被害者に転送します-パケットを転送するために明示的に構築されたカスタムアプリケーションは、パケットを被害者に転送します

ただし、被害者はパケットを1回しか受信しません。どうして？

パート3：最終的な答え

Ettercapは、次の特性を持つトラフィックのみを転送します。

  • パケットの宛先MACアドレスが攻撃者のMACアドレスと同じである
  • dest ipはnotは攻撃者のIPアドレスと同じです

ここでの問題は、iptables REDIRECTコマンドを使用すると、次のことが発生することです。

  • 宛先ポートが変更された（この特定のケースでは80から8080に）
  • 宛先IPは、iptablesが実行されているデバイスのメインIPアドレスに変更されます。
  • これはPREROUTINGルールであるため、パケットがEttercapに到達する前に上記が発生します

パケットが2回転送されない理由を尋ねるのは、「宛先IPの変更」です。被害者からの外部Webサーバー向けの次のパケットを想像してください。

ソースIP：192.168.1.3
ソースMAC：00：00：00：00：00：03
宛先IP：47.32.1.6:8
宛先MAC：00：00：00：00：00：01

このパケットがEttercapに到着した場合、転送条件は満たされているはずです。パケットの宛先MACは攻撃者のものですが、宛先IPはそうではありません。

現在、このパケットはその形式で到着しません。iptablesREDIRECTコマンドはそれを次のように変換します。

ソースIP：192.168.1.3
ソースMAC：00：00：00：00：00：03
宛先IP：192.168.1.2:808
宛先MAC：00：00：00：00：00：01

192.168.1.2は、リダイレクトコマンドが実行されるデバイスのメインIPアドレスであるためです。したがって、このパケットはEttercapによって無視されます。

パート4：最終的な洞察

さて、上記は実際にはSSL解剖を有効にした場合と同じです。 SSL解剖を有効にするには、etter.confで次の行のコメントを解除する必要があります。

redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport" 
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

お気づきかもしれませんが、これは質問で述べたiptablesコマンドとほぼ同じコマンドです。したがって、同じことが当てはまります。ettercapは、ポート443に着信したパケットを転送しません。

  • 被害者からのトラフィックが入ってくる、それはhttpsサーバーに行くことになっている
  • Iptablesによってリダイレクトされるため、ettercapはそれを転送しなくなります（宛先IPが変更されるため）。つまり、すべてのSSLトラフィックが攻撃者のPCに留まります。
  • 次に、Ettercapは偽の証明書を使用して偽のサーバーを作成します。 HTML/JSを提供するために実際のsslサーバーと通信を開始しますが、クライアントはettercapに直接通信します。パケットは転送されなくなりました。

これは質問で説明されているケースと同じですが、TSによって作成されたアプリケーションは引き続きトラフィックを転送しますが、SSLディセクタはトラフィックを転送しません。

10
Michael