web-dev-qa-db-ja.com

SSLストリップインジェクションポイント

私はSSLストリッピングについて読んでいますが、このMITM攻撃を成功させるためのインジェクションポイントに関する基本的な質問があります。私は典型的なシナリオを理解しています-

A (victim) <-- plain --> M (MITM) <== SSL ==> B (Server)

ここで、MとAが同じ喫茶店のwifiネットワーク上にあり、MがARPポイズニングなどによってAのトラフィックのプロキシを開始するとします。AがSSL経由でBにアクセスしている場合、Mが傍受するトラフィックは暗号化されます。暗号化されたストリームだけを処理する必要がある場合、MはどのようにしてHTTPSをHTTPに置き換えたり、HSTSヘッダーを削除したりできますか? URL(プロトコル「https://」を含む)を含むペイロード全体が暗号化されていると思います。

言い換えれば、暗号化されたデータの除去/操作が可能になる注入ポイントはどこにありますか?それはネットワークスタックのさらに下で起こりますか? Mはパケットレベルでプロトコルを切り替えることができますか?

いくつかの投稿は パケットキャプチャ証明書 について話しますが、データを復号化できずにSSLを取り除くための広く受け入れられている方法があるかどうかはわかりません。

1
katrix

暗号化されたストリームだけを処理する必要がある場合、MはどのようにしてHTTPSをHTTPに置き換えたり、HSTSヘッダーを削除したりできますか?

できません。SSLストリップ攻撃を処理するには、最初は暗号化されていないストリームが必要です。それはSSLを攻撃するのではなくバイパスします。アイデアは、HTTPSページへのリダイレクトとリンクをプレーンなHTTPページに変換することにより、ブラウザがHTTPS接続を開始しないようにすることです。または、実際のHTTPSページにリダイレクトすることもできますが、ドメイン名を攻撃者が所有する同様の名前に変更します(例:https://faceboook.com)。これには、緑色のSSLインジケーターロック(ただし、偽のドメイン名)が表示されるという利点があります。

一般的なインジェクションポイントは、ユーザーが最初にアドレスバーにmybank.comを入力し、(サイトが HSTSプリロードリスト にない場合)ブラウザが最初に通常のHTTPリクエストで開始する場合です。暗号化されていない応答を受信して​​、HTTPSにリダイレクトします。この応答は通常、アプリケーション層のトラフィックを改ざんできる最後の時間です。

HSTSは trust-on-first-use です。攻撃者がHSTSヘッダーを削除できる最初のプレーンHTTP接続の試行で被害者を捕まえなかった場合、ブラウザはHSTSヘッダーの有効期限が切れるまでプレーンHTTPを阻止するため、将来的には失敗します。

1
Arminius