web-dev-qa-db-ja.com

Fedora24のSSLストリップ

自分のネットワークでMITM攻撃を実行したいので、sslstrip、iptables、arpspoofの使用方法に関するいくつかのチュートリアルを実行しました。

しかし、攻撃を実行するたびに、google、facebook、その他を除くほとんどすべてのWebサイトのターゲットデバイスの接続が失われます。大きなWebサイトのように、HTTPSで保護されていてHTTPSではないWebサイトへの接続が失われる可能性がありますか？

Sslstripが実行されている場合でも、sslstrip.logファイルは常に空です。ここに私が使用するコマンドの順序があります：

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 8080
arpspoof -i wlp3s0 -t 192.168.178.125 -r 192.168.178.1
sslstrip -l 8080

何が起こっているのかを確認するには、tail -f sslstrip.log

私が間違っていることを教えていただければ幸いです。

man-in-the-middlearp-spoofingiptablessslstrip
4
fullcowl

私はあなたがコマンドを上手にやっていると思います...しかし、sslstripテクニックはあなたの側だけに依存しません。それは多くの要因に依存します... "被害者"が常にhttps://whateverpageを使用してブックマークを使用している場合、何もする必要はありません。彼/彼女は常に暗号化されたページを直接尋ねます。

「被害者」がhttpsの前に配置せずにwhateverpage.comを使用するページを要求している場合、彼はhttpページを要求します。サイトでHSTSがアクティブ化されている場合（httpリクエストを受信し、それをhttpsページバージョンにリダイレクトします）、httpページのリクエストがあるため、sslstripを実行できます。1つだけですが、sslstripには十分です。それは「被害者」にプレーンでページを表示するつもりであり、それは実際のサイトへのssl接続を行います。

「HSTSがsslstripのソリューションである」と多くの人が言います。そして、これはNOT TRUEです。 HSTSを使用してページへのアクセスを何度もテストしてsslstripを実行しましたが、動作します。私が言ったように、キーは被害者がhttp（「s」なし）の最初のリクエストを実行する必要があることを示しています。

もう1つの決定的な要因は、一般的なブラウザーを使用する場合、すべてのページをsslstrippedできないことです...つまり、たとえば、Chrome、Firefox、またはInternet Explorerを使用する場合...これらのブラウザーには、既知のsslサイトの内部リストがあります。ユーザーがhttps：//を指定せずにfacebook.comを入力して「悪い方法のリクエスト」を行ったとしても、ブラウザは常にhttpsを使用してそれらを探す必要があることをブラウザが知っているため、そのサイト（TwitterやFacebookなど）は決してsslstrippedされません。前。私はこれらのサイトがブラウザの会社にそのリストに入るように支払うと思います。

あまり知られていないsslページを試してみることをお勧めします。そうすることで、ブラウザの内部リストにあるサイトに対してテストを行うとクラッシュする可能性が少なくなります。

デロリアン攻撃など、そのリストのページにさえsslstripを実行するためのより高度な手法がありますが、より複雑です。

1
OscarAkaElvis