😔 🤶 🥘 SSL / TLSプロトコルに対する最初の実用的な攻撃 🤗 💣 🔣

SSL接続を介して送信されたデータは復号化できます！これを行うために、Julian RizzoとTai DuongはSSLプロトコル自体の欠陥をどうにか使用しました。また、トラフィックの完全な復号化については説明していませんが、彼らが開発したBEASTユーティリティは、暗号化されたストリームから最も重要なもの、つまりユーザーセッション識別子を持つシークレットCookieを抽出できます。

BEASTとは何ですか？

BEAST（SSL / TLSに対するブラウザエクスプロイト）ユーティリティがPayPalアカウントにログインするためにシークレットCookieを解読するのにわずか103秒かかりました。 Youtubeでビデオキャストを見ることができます。これは偽物ではありません。ブエノスアイロで行われたエコパーティ会議の一環として、ユーティリティの実演が行われました。そこでは、研究者がプレゼンテーションを行い、実用的な概念実証を示しました。使用される脆弱性により、Webサーバーとユーザーのブラウザー間で送信されるデータを静かに傍受することができます。皮肉なことに、この攻撃はプロトコルで見つかった新しい欠陥を悪用するのではなく、純粋に理論的に考えられてきた10年前のSSL / TLSの脆弱性を悪用します。しかし、彼らが言うように、1年に1回スティックが発射されるため、10年以内に脆弱性は理論的なカテゴリから非常に実用的なカテゴリに確実に移行します。

研究者はユーティリティをまだ公開していませんが、完了した作業に関するホワイトペーパーを共有しています。このプログラムは2つの要素で構成されています。HTTPSトラフィックを分析するスニファーと、被害者のブラウザーに読み込む必要があるJavaScriptとJavaで書かれた特別なエージェントです（たとえば、ユーザーに必要なコードでページを開かせる必要があります）。秘密のCookieの送信に使用されるのと同じ安全な通信チャネルにデータを具体的に埋め込むには、エージェントが必要です。これはどのようにデータを解読しますか？これは、以前から知られているSSL 3.0 / TLS 1.0の脆弱性の出番です。これについては、さらに詳しく説明します。

単純な交換モードの問題

SSL暗号化機能1.0

SSL 1.0 / TLS 3.0プロトコルでは、ブロック暗号またはストリーム暗号を使用した対称キー暗号化を使用できます。ただし、実際には、通常、ブロック暗号が使用され、ここで説明する攻撃は特にブロック暗号に適用されます。本質を理解するには、基本的な概念をよく理解する必要があります。

ブロック暗号の動作原理は、同じサイズの暗号化されたブロックでプレーンテキストブロックを表示することです。ブロック暗号を想像する最も簡単な方法は、2 ^ 128エントリを含む巨大なテーブルの形式です。各エントリには、テキストのブロックMとそれに対応する暗号化されたブロックCが含まれます。したがって、暗号化キーごとに個別のそのようなテーブルがあります。次に、関数として暗号化を示します。

C = E（キー、M）、ここでMはソースデータ、キーは暗号化キー、Cは受信した暗号化データです。

ブロックは小さい（通常は16バイト）。したがって、質問が発生します：長いメッセージを暗号化する方法？メッセージを同じ長さ（同じ16バイト）のブロックに分割し、各ブロックを個別に暗号化できます。このアプローチは、単純置換モード（ECB、電子コードブック）と呼ばれますが、めったに使用されません。これには理由があります。コンテンツ内の2つの同一のブロックを暗号化すると、結果として2つの同一の暗号化ブロックが得られます。これには、ソーステキストの統計的特徴を保持するという問題が伴います。これは、図によく示されています。この影響を回避するために、暗号ブロック連鎖ブロッキングモード（CBC、暗号ブロック連鎖）が開発されました。このモードでは、プレーンテキストXORの次の各ブロックが前の暗号化結果に関連付けられます。

Ci = E(Key, Mi xor Ci-1)

最初のブロックの暗号化中、XORソースコードは何らかの初期化ベクトル（初期化ベクトル、IV）であり、これは以前の暗号化の結果を置き換えます。ご覧のとおり、すべてが非常に簡単です。ただし、この理論では、たとえば、簡単にブロックに分割されるファイルなど、1つの大きなオブジェクトの状況を説明しています。次に、SSL / TLSは暗号化プロトコルです。単一のファイルではなく、一連のパケットを暗号化する必要があります。 SSL / TLS接続を使用して一連のHTTPSリクエストを送信できます。各リクエストは1つ以上のパケットに分割され、数秒または数分以内に送信されます。この状況では、CBCモードを使用する2つの方法があります。

各メッセージを個別のオブジェクトとして処理し、新しい初期化ベクトルを生成し、説明されているスキームに従って暗号化します。
すべてのメッセージが1つの大きなオブジェクトに結合されたかのように処理し、メッセージ間のCBCモードを維持します。これは、前のメッセージの最後の暗号化ブロック（n-1）をメッセージnの初期化ベクトルとして使用することで実現できます。

注意、重要なポイント。 SSL 3.0 / TLS 1.0プロトコルは2番目のオプションを使用し、これが攻撃の機会が存在する場所です。

CBC暗号の動作原理

予測可能な初期化ベクトル

この攻撃はいくつかの仮定に基づいていますが、BEASTの作成者の経験から、実生活でそれらを実装することは非常に現実的であることが示されています。最初の仮定：攻撃者はブラウザが送信するトラフィックを盗聴できる必要があります。 2番目の仮定：悪者は何らかの形で被害者に同じ安全な通信チャネルを介してデータを送信させる必要があります。なぜこれが必要なのですか？ボブとアリスのコンピューター間で安全な接続が確立されている場合を考えます。想定どおり、i-blockにAliceのパスワード（またはシークレットCookie-関係ありません）が含まれるメッセージを取得します。暗号化されたブロックをCi、Miとして示します-そのパスワード。 Ci = E（Key、Mixor Ci-1）であることを思い出させてください。ここで、彼女のパスワードがRであると仮定します。主なアイデアは、想定の正しさを検証できることです。

したがって、次のメッセージの最初のブロックを暗号化するために使用される初期化ベクトルを（傍受できたので）知っています。これは、それぞれ、前のメッセージの最後のブロック（暗号化された形式）です。これをIVと示します。また、Ciの前のブロックの意味をインターセプトし、知っています。Ci-1で示しています。このデータが本当に必要です。彼らの助けを借りて、特別な方法でメッセージを作成し、最初のブロックが次と等しくなるようにします。

M1 = Ci-1 xor IV xor P

メッセージが同じ安全な通信チャネルを介して送信された場合、暗号化後の新しいメッセージの最初のブロックは次のようになります。

C1 = E(Key, M1 xor IV) = 
      

        
        
        
      

     = E(Key, (Ci-1 xor IV xor P) xor IV) 
      

        
        
        
      

     = E(Key, (Ci-1 xor P)) 
      

        
        
        
      

     = i

完全なM1表記を使用するだけで、その後、（IV xor IV）が破棄されるという事実を使用して式を簡略化しました（XORの顕著な特性）。アリスのパスワードに関する想定が正しい（つまり、Mが実際にPに等しい）場合、新しいメッセージC1の最初の暗号化されたブロックは、以前にインターセプトされたCiと等しくなります。そしてその逆：仮定が正しくない場合、平等はありません。したがって、仮定をテストできます。

SSL攻撃を実装するためにサーバーにリクエストを送信する

検索機能

時間と試行回数が多いと仮定すると、Mの正しい値が見つかるまでこの手法を何度も繰り返すことができます。ただし、実際には、Mのブロックの長さは16バイトです。 2バイトを除くすべてのバイトの値がわかっている場合でも、残りのバイトを推測するには2 ^ 15（32,768）回の試行が必要です。そして、私たちがまったく何も知らない場合は？要するに、テクニックは唯一の場合にしか機能しません-Mの値について限られた数の仮定がある場合です。より正確には：このブロックの内容のほとんどを知っている必要があります-これは、説明された脆弱性を悪用する唯一の方法です。 1つのトリックがあります。

攻撃者が、暗号化されたブロック内でのデータの配置方法を制御できるとします。たとえば、アリスに戻りましょう。彼女のパスワードの長さが8文字であることを知っているとします。攻撃者がパスワードを調整して、最初のブロックに1文字のみが入り、残りの7文字が次のブロックに入るようにできる場合。アイデアは、最初のブロックの最初の15バイトで既知のデータを送信することです。パスワードの最初の文字である最後のバイトのみを選択できます。たとえば、「user：alice password：********」という形式の行を送信するとします。ここで、「********」はパスワード自体です。攻撃者が文字列を渡して次のブロック「[lice password：*] [******* .........]」に分割した場合、パスワードの最初の文字を選択することはもはや不可能に思えますタスク。最悪のシナリオでは、悲惨な256回の試行が必要になります。そして、特別な運の場合、それは完全に1つです:)！最初のバイトを取得した後、パーティションの境界を1文字シフトすることができます。つまり、最初のメッセージで14の既知のバイトを送信します。これで、ブロックはパスワードの最初の2バイトで終了します。最初の2バイトはすでに選択されています。繰り返しますが、2番目のバイトを推測するために必要な試行回数は256回です。パスワードが一致するまで、プロセスを繰り返すことができます。また、BEASTはこの原則を使用してシークレットCookieを選択し、変更されたリクエストヘッダーを既知のデータとして使用します。選択は、可能性のある文字を絞り込むことで加速されます（リクエストですべてを使用できるわけではありません）。また、Cookieの名前を想定します。

秘密のPayPal Cookieを解読するのにわずか103秒かかりました。

攻撃の実装

ただし、脆弱性自体と復号化を実行する最適化された方法は長い間説明されてきました。 BEAST開発者が実際に成功したのは、攻撃に必要なすべての条件を実装することでした。

攻撃者は、被害者のブラウザによって開始されたネットワーク接続を聞くことができるはずです。
攻撃者は被害者のブラウザにエージェントを注入できるはずです。
エージェントは、任意の（多かれ少なかれ）HTTPSリクエストを送信できなければなりません。

冒頭で、BEASTの重要な部分はいわゆるエージェントであり、攻撃者へのリクエストを（セキュアなプロトコルを使用して）サーバーに転送できると既に述べました。研究者は、この条件を満たすことができるさまざまな技術とブラウザプラグインのリストをまとめました。判明したように、Javascript XMLHttpRequest API、HTML5 WebSocket API、Flash URLRequest API、Java Applet URLConnection API、Silverlight WebClient APIなどがあります。ただし、最初の近似では、攻撃の実装を妨げる制限が存在するため、それらの一部は不適切でした。結果は、HTML5 WebSocket API、Java URLConnection API、およびSilverlight WebClient APIのみです。研究者がバグをベンダーに報告した時点で、彼らはHTML5 WebSocketに基づいた作業エージェントを手に持っていました。しかし、この技術は常に進化しており、プロトコル自体は常に変化しています。その結果、作動中のエージェントは動作を停止しました。人々が公開したBEASTの現在のバージョンは、Javascript / Javaで記述されたエージェントとネットワークスニファーで構成されています。

ユーザーにアプレットまたはJavaScriptをサイレントにデプロイすることは、実際にはそれほど難しいタスクではありません。ただし、わずかなニュアンスが残っています。スクリプトまたはアプレットが被害者によって確立された接続でデータを送信できるようにするには、SOPの制限（同じオリジンポリシー、ドメイン制限ルール）をバイパスする必要があります。これは、JavaScriptなどの一部のクライアント側プログラミング言語にとって重要なセキュリティ概念です。このポリシーは、1つのサイトのページにあるスクリプトが制限なしに互いのメソッドとプロパティにアクセスすることを許可しますが、異なるサイトのページのほとんどのメソッドとプロパティへのアクセスを禁止します。簡単に言えば、1つのページで実行されているクライアントは、目的のサイト（Paypal.comなど）にリクエストを送信できません。 SOPポリシーを回避するために、著者はJava仮想マシンに0dayの脆弱性を発見し、そのためのスプーフィングを作成しました。既存のCookieを読み取れるとは思わないでください。もしそうなら、なぜ暗号化されたトラフィックとの大騒ぎが必要なのですか？分割を使用してSOPをバイパスすることで、リクエストを送信し、サーバーの応答（新しいCookieを含む応答を含む）を読み取ることができますが、ブラウザーに保存されている既存のCookieを読み取ることはできません。開発者は、ブログでエージェントを作成するというストーリー全体を共有しています。

尊敬する

結論として、10年前に誰もが忘れていた脆弱性を利用できただけでなく、ユーティリティを機能させるために多くの作業を行った研究者の膨大な作業に注目したいと思います。この資料の一部として、使用する手法の説明を大幅に簡略化し、主なアイデアを伝えました。しかし、私たちは実際に研究者から詳細な文書を読み、実装された攻撃について詳細に話しています。お疲れ様でした！

問題の大きさ

では、災害の規模はどのくらいですか？または言い換えれば-誰が脆弱ですか？最も一般的なセキュリティプロトコルであるTLS1.0を使用するほとんどすべてのWebサイト。面白いのは、BEASTでのこの誇大広告の後、多くの人が新しいバージョンのプロトコル（TLS 1.1以降）に関心を示し始めたことです。しかし、現在これらのプロトコルをサポートしているサイトはいくつありますか？はい、ほとんど誰もいません！イラストを見てください。 TLS 1.1はすでに5年前ですが、ユニットはそれを使用しています！

別の質問：自分を守る方法は？実際、パニックしても意味がありません。この脆弱性はほとんどのブラウザですでに修正されています。しかし、妄想がpre延している場合は、ブラウザで安全でないプロトコル（TLS 1.0およびSSL 3.0）を無効にし、同時にJavaを無効にすることができます。ただし、この場合、多くのサイトが機能しなくなることは驚くに値しません。

ハッカーマガジン、 11月（11）154

集合的な心 。

ハッカーを購読する

SSL / TLSプロトコルに対する最初の実用的な攻撃