How to Bypass HTTPS

今すぐ これまで､ 私たちは「中の人」になる方法を学びました｡ そして､ 私たちが中の人になってからは､ 送られてくるデータをすべて読み取る方法を学びました｡ そのため､ ユーザー名やパスワード､ URL､ 画像など､ 閲覧者が閲覧するあらゆるものを読み取ることができました｡ また､ このデータを改変することで､ ターゲットがWebサイトを閲覧する際に､ JavaScriptのコードや任意のタイプのコードをターゲットのブラウザに注入することができました｡ これによって､ ダウンロードを置き換えて､ たくさんのクールな攻撃ができるようにもなりました｡ これで､ これまでやったことはすべて､ HTTPページに対してのみ機能するようになりました｡ なぜHTTPに対して動作するかというと､ データで見る限り､ HTTPはプレーンテキストで送信されるからです｡ つまり､ 私たちのような人間が読んで理解できるテキストなんですね｡ だからこそ､ 私たちが中の人になったとき､ この文章を読むことができるのです｡ さらに､ このテキストを自由に修正することも可能です｡ さて､ これは明らかに問題であり､ この問題はhttpsで修正されました｡ ですから､ ご存知のように､ 最近のほとんどのウェブサイトはHTTPSを使用しており､ 良いウェブサイトはすべてHTTPSを使用しています｡ 有名なウェブサイトはHTTPSを使用しています｡ なぜかというと､ 先ほども言ったように､ HTTPの中でもより安全なバージョンだからです｡ そして､ 基本的には､ HTTPの実装をまったく同じに保つという仕組みになっています｡ つまり､ すべてのヘッダー､ すべてのデータ送信方法は同じままです｡ つまり､ HTTPは変更されないが､ httpの上にさらにレイヤーが追加され､ それがTSSの由来となっている｡ つまり､ 安全なHTTPプロトコルで､ この追加レイヤーはHTTPが送信する平文データを暗号化することになるのです｡ だから､ 中の人になることに成功した人は､ このデータを読み取ることができるようになる｡ しかし､ そのデータはちんぷんかんぷんでしょう｡ 接続を傍受する者が読み取ることはできない｡ ユーザーとサーバーの両方が鍵を持っていて､ 暗号化されたデータを復号することができるからこそ､ 意味があるのでしょう｡ では､ どのようなものなのか､ 例を挙げてみましょう｡ さて､ 一般的にARPスプーフィングなどの手法で中間者になると､ ご存知の通り､ リクエストがハッカーを経由して流れてきます｡ ハッカーはこれをインターネットに転送するか､ アクセスポイントに転送し､ インターネットに転送し､ その応答がハッカーのコンピュータを経由して被害者に流れます｡ さて､ 通常､ 人やユーザーがあるウェブサイトにアクセスしようとしたとき､ 例えばBBCにアクセスしようとしたとします｡ comにアクセスすると､ リクエストを送信してくれます｡ さて､ このリクエスト､ 最初のリクエストは､ ユーザーがウェブサイトの前にhttpsをタイプしない限り､ httpsで送られることはありません｡ そして､ 私を含め､ ほとんどのユーザーはhttpsを入力せず､ ウェブサイトの名前を入力するだけだと思います｡ だから､ もし彼らがBBCに行きたがったら｡ comの場合､ BBCと入力されるだけです｡ comを使用しています｡ つまり､ 最初のリクエストはHTTPで送られることになる｡ 中間の人間であるハッカーは､ これを受信してインターネットに転送することになる｡ BBC comは､ 一方では､ Hey, why don't you talk to me over https?と言って応えようとしている｡ BBCがhttpsで通信できることをターゲットに知られたことで､ より安全性が高まりました｡ それなら､ これからはHTTPSを使ってBBCと通信してくれるはずだ｡ そのため､ 最初のリクエストの後に続くすべてのリクエストは､ httpsで送信されます｡ ハッカーは､ これをHTTPSとして再びインターネットに転送して受け取ります｡ サーバーはhttpsで応答します｡ これでお分かりのように､ すべての通信､ すべてのリクエストとレスポンスはhttpsで送信されます｡ HTTPSは､ HTTPプロトコルに暗号化レイヤーを追加するものです｡ これは､ 私たちが普段HTTPで読んでいる平文のデータが暗号化され､ 私たちにとって有用でなくなることを意味します｡ だから今､ 私たちは真ん中にいて､ このすべてのデータを見ることができ､ 読むことができるのです｡ しかし､ このデータはちんぷんかんぷんでしょう｡ そのため､ ユーザー名､ パスワード､ URL､ HTMLコードを見ることができず､ そもそもパケットを読むことができないので､ コードを注入したり､ パケットを変更したりすることはできません｡ ハッカーとしては､ 中間管理職になるために大変な努力をしたわけですから､ これは本当に残念なことです｡ そして､ 一旦､ 真ん中の人間になってしまうと､ この非常に良いポジションを生かすことができなくなってしまうのです｡ 幸いなことに､ Moxyという賢い男がいて､ 彼は非常に長い間SSLを破ってきました｡ この男が考え出した方法の1つは､ HTTPSを迂回してHTTPにダウングレードすることを可能にします｡ さて､ この攻撃を発見したのは､ モクシーだけではありません｡ また､ これを実現する素晴らしいツールも書いてくれました｡ そこで､ 最初のリクエストをもう一度見てみることにします｡ そして､ 先ほども言ったように､ 通常､ 人々はウェブページを要求するときにhttpsと入力しませんので､ 例えば､ BBCと入力します｡ COM. これはハッカーのコンピュータを経由して行われます｡ ハッカーはすでに中間者であり､ Marksの攻撃を実行するSQL Stripというツールも実行しています｡ さて､ ツールはこれがHTTPリクエストであることを見抜きますので､ それを弄ることはありません｡ これはハッカーとしては好都合で､ インターネットに転送するだけでいいのです｡ 次は､ BBCです｡ comは､ 「おい､ なんでhttpsで通信しないんだ」と反論してきそうです｡ さて､ SSLストリップはこれを検知する｡ ちなみに､ BBCがというと､ おい､ httpsで通信したらどうだ？ 本当はもう少し複雑な工程があるのですが､ なるべくシンプルにまとめています｡ SSLストリップは､ サーバーがターゲットにhttpsで通信するよう伝えようとしていることを検知し､ すべてのフィールドとデータを削除または除去するのです｡ これは基本的に､ この接続をHTTPS接続にアップグレードしようということです｡ つまり､ レスポンスはHTTPSレスポンスとしてやってくるが､ Sstl stripはそれを取り除き､ 通常のHTTPレスポンスのように見える部分のみを被害者に転送するのである｡ さて､ ここまでのところ､ 被害者はサーバーが https で通信できることを知らないので､ 次のリクエストは通常の HTTP リクエストとして送信されます｡ ここで､ SSLストリップが賢いのは､ HTTPレスポンスを送信したすべてのウェブサイトを追跡するところです｡ つまり､ 被害者がBBCと通信するときにHTTPリクエストを送ろうと思っても com の場合､ SSL スクリプトはその BBC を知っています｡ com は https での通信を好んでいます｡ つまり､ 犠牲者やターゲットからHTTPリクエストを受け取ると､ その接続をHTTPS接続にアップグレードするのです｡ だから､ BBCに関しては comが懸念しているのは､ ターゲットに「HTTPSで通信してください」と伝え､ ターゲットがそれに応えてhttpsで通信を開始したことです｡ だから､ これはBBCにぴったりなんです｡ comと被害者のために｡ 彼らに関する限り｡ 彼らはBBCを考えていない｡ com は､ HTTP リクエストを送信するたびに HTTP 応答を取得しているため､ https で通信することができます｡ BBC が https で通信できると考えていないわけです｡ もしできるなら､ https で通信してくださいと被害者に応答することになります｡ 今､ この構成は私たちのために完璧になりました｡ ハッカーはリクエストとレスポンスを平文で読むことができ､ 誰も私たちが接続で遊んでいることを知らない｡ ターゲットは､ アクセスしようとしているウェブサイトがHTTPしかサポートしていないと思い､ ウェブサーバーもhttpsで通信しているため､ クライアントだと思っていたのに､ 実は私たちだったということになります｡ インターネットからHTTPレスポンスを受け取ると､ 私たちはそれを読むことができます｡ HTTPSサイクルは､ 実際には当社とインターネットまたはWebサーバーとの間のみであり､ 被害者とWebサーバーとの間にはないことがおわかりいただけると思います｡ さて､ Sstlストリップが行うもう一つのことは､ ウェブページを読み込むときに､ ページ内のすべてのリンクをHTTPSから通常のHTTPに実際に変換することです｡ また､ この方法では､ SSLストリップが機能している場合､ すべてのHTTPS接続はHTTPにダウングレードされます｡ さて､ 接続がHTTPにダウングレードされるということは､ データがプレーンテキストで送信されるということです｡ 現在､ Facebook､ PayPal､ GmailなどでHTTPSが使用されているように､ この全体のルールには1つの例外があり､ それはHSTを使用するウェブサイトです｡ 基本的に､ この仕組みは､ 被害者のブラウザが､ https としてのみ読み込むべき Web サイトのリストをハードコードすることで実現しています｡ そのため､ できる限りのことを試し､ この接続をHTTPにダウングレードしたとしても､ ブラウザはこのページの読み込みを拒否するだけです｡ なぜなら､ このページはhttpsで読み込む必要があるとわかっているからです｡ さて､ 今のところ､ ホストを回避する実用的な方法はありません｡ ありましたが､ それは修正されました｡ でも､ 新しい迂回方法があれば､ すぐに更新しますよ｡