ネットワークレベルの攻撃を使用してアプリケーション層のトラフィックを傍受しようとしています。特に、この興味深い記事をここで偶然見つけました。
簡単に言うと、ARPポイズニングを使用して攻撃者のマシンをmitmにし、iptablesを使用してhttpおよびSSLトラフィックを転送し、攻撃者のマシンでげっぷをします。
私のセットアップ:
すべて正常に機能し、ARPポイズニングが機能し、Wiresharkでパケットを確認できます。行われたすべてのDNS要求と暗号化されていないすべてのHTTPデータがWiresharkに表示されます。また、げっぷはうまく設定されており、HTTPSトラフィックでさえトラフィックを傍受します。たとえば、 https://barracuda.com を試したところ、げっぷでそれを見ることができました。
次に、bing.comをテストしましたが、げっぷでも確認できました。しかし、犠牲PCからFacebookやGoogleに接続しようとしたとき、げっぷのトラフィックはまったく見えません。げっぷのFacebookやGoogleへのトラフィックの兆候はありません。エラーメッセージもありません。ただし、WiresharkでFacebookおよびGoogleに対して行われたDNS要求を確認できます。次に、いくつかのTCPストリーム交換が続きます。これは、明らかにこれらの2つのサイトからの要求応答である必要があります。これは、トラフィックが私のKali Linuxマシンを通過することを意味します。げっぷのトラフィック?
私はこの問題を、犠牲PCのChrome 66とOperaブラウザ)(両方とも最新)の両方でテストしました。どちらも同じ動作をします。
ゲップCAを被害者の信頼されたルートにインポートする前に、hsts固有のエラーを確認できました。インポート後、bing.comへのトラフィックを傍受できるのに、FacebookやGoogleへのトラフィックを傍受できないのはなぜですか?げっぷでそれを見ることを妨げているどんな魔法が働いていますか?
どんなリードもいただければ幸いです。ありがとう。
気にしないで。これらのWebサイトはIPv4 over IPv4を使用していたため、IPv6の暗号化のためにトラフィックを確認できませんでした。ネットワークアダプターがいくつかのタイプのアドレスを持っている場合、WindowsはIPv4よりもIPv6を優先することが判明しています。 (多分セキュリティのため?)
Wiresharkで、FacebookとGoogleへのDNSリクエストがIPv4アドレスとIPv6アドレスを受け取っていることがわかりました。しかし、ビングとバラクーダのものはそうではありませんでした。また、IPv4よりもIPv6が優先されているため、IPv6が使用されました。問題のアダプターを介してWindowsでIPv6サポートを無効にしたところ、予想通り、正常に戻りました。
そして、私が言及したTCP交換はおそらく別のものであり、GoogleやFacebookからのリクエスト応答ではないことがわかります。WindowsマシンでWiresharkを実行するだけでこれに気づき、これに慣れました私はいくつかの調査を行い、MicrosoftのサポートからIPv4よりもIPv6の優先についてどこかで知りました。
これがどこかのペンテスターに役立つことを願っています。