キャプティブポータルでFacebook HTTPS Cookieを盗む

Question

セキュリティ上の懸念があります。ご存知のように、多くのパブリックホットスポットは、最初のWebサイトを閲覧しようとすると、ログイン画面にリダイレクトします。

たとえば、そのようなホットスポットに接続して https://www.facebook.com にアクセスすると（そのサイトにすでにログインしているコンピューターから）、ホットスポットログインにリダイレクトされます画面で、ブラウザに証明書の警告は表示されません。

明らかに、私のブラウザーから行われた最初のHTTPS要求には、セッションCookie（ "Cookie：" HTTPヘッダー）が含まれています。

ログイン画面へのリダイレクト（ICMPまたはDNSベースのリダイレクト）を実行している間、ホットスポットはHTTPSリクエストのコンテンツを認識しますか。したがって、セッションCookieを認識しますか？

悪意のあるホットスポットが最初のHTTPSリクエストを読み取ることができると思います。

ブラウザがfacebook.com:443に接続しようとすると、証明書のハンドシェイクが行われます。
ホットスポットは有効なIPベースの証明書を送信して返信するので、ホットスポットは「facebook.com」になりすまして、元のHTTPSリクエストのコンテンツを読み取ります。
その後、ブラウザクライアントで警告なしに、ホットスポットHTTPSログイン画面に301/302リダイレクトで応答する場合があります。

このようにして、ホットスポットは最初のHTTPSリクエストの内容を知ることができますか？

Andr&#233; Borie · Accepted Answer

HTTPSサイトにアクセスし、警告なしでリダイレクトされる場合、問題はブラウザーが証明書を正しく検証していないことです-キャプティブポータルの証明書に一般的な名前でアクセスしたいドメインが含まれていないため、適切なブラウザーは警告を表示しますフィールド。

HTTPを介してサイトにアクセスした場合の脆弱性の可能性がありますが、これを緩和するソリューションとして、ブラウザにこのCookieをHTTP経由で送信しないように指示するCookieの Secure Flag などがあります-および [〜＃〜] hsts [〜＃〜] これにより、ブラウザーはサイトへのHTTP要求を自動的にHTTPS要求に変換し、HTTPS接続が確立できない場合に証明書エラーをバイパスすることを防ぎます。

kasperd · Answer

動作はブラウザに依存します。ブラウザがFacebook向けのHTTPSリクエストを実際にキャプティブポータルに送信する場合、それは明らかにブラウザの脆弱性です。しかし、状況を処理する他の方法があります。

最近、キャプティブポータルのあるネットワークを数回使用する必要がありました。そして、それらの場合、私は前のセッションからいくつかのFacebookタブを偶然開いていたChromiumを開始しました。

何が起こったかというと、適切なエラーメッセージが表示されたということです。しかし同時に、Chromiumは新しいタブを開きました。このタブは、キャプティブポータルに乗っ取られることを意図して、特定のHTTP URLにアクセスしました。キャプティブポータルを通過するとすぐに、Facebookのタブが自動的に再読み込みされ、今回はエラーが発生しませんでした。

したがって、Chromiumはキャプティブポータルの存在を検出し、安全に開き、キャプティブポータルを通過すると最後に検出するようです。

同様のキャプティブポータルの検出がAndroidおよびiOSに存在しますが、ブラウザーに関連付けられているのではなく、アクセスポイントとの関連付けの一部として行われます。

キャプティブポータルがどのように機能しているかについての理解にいくつかの誤解があります。私が出会ったキャプティブポータルは確かに別の方法で機能しました。

DNSトラフィックの傍受は行われませんでした。 DHCPを通じて提供されるDNSサーバーを使用している限り、コンピューターはキャプティブポータルにアクセスしなくても制限なしにDNSルックアップを実行できます。

ICMPトリックも引き出されません。むしろ、コンピュータとサーバーの間の正当なパス上のルーターの1つがTCPポート80への接続をハイジャックします。TCP接続がハイジャックされると、キャプティブポータルへのリダイレクトはブラウザに送信されます。適切な実装では、HTTPS URLにリダイレクトし、元のURLに関する情報を含めて、後でそこに送り返すことができます。キャプティブポータルとの通信全体は、実際にキャプティブポータルに属しているドメイン名の正当な証明書。

このアプローチはHTTPでは機能しますが、HTTPSでは機能しません。ハイジャックを実行しているルーターには、アクセスしているサイトの有効な証明書がないため、安全なブラウザーでは、HTTPSに対して同じハイジャックが行われた場合、証明書の警告が表示されます。

これをHTTPSで機能しないようにするには、3つの方法があります。

セキュリティーに関する警告を無視し、リスクに関する非常に詳細な警告が表示された後でも個人情報が傍受されることをユーザーが受け入れることに依存します。
すべてがどのように機能するかを理解し、自分でHTTP URLを開いてハイジャックされ、キャプティブポータルを通過した後に元のHTTPS URLにアクセスすることをユーザーに依存します。
クライアントソフトウェアにキャプティブポータルの存在を検出させ、適切に処理させます。これは依然として、キャプティブポータルがフィッシング攻撃を実行しようとしているかどうかをユーザーが特定できることに依存していますが、少なくともCookieはリークされません。