この脆弱性は15年間修正されています。
4年前のテキスト翻訳habra-translation 「パディングOracle攻撃、または暗号化が怖い理由」では、CBC暗号化モードへの攻撃が詳細に説明されました。 このモードでは、連続するプレーンテキストの各ブロックは、暗号文の前のブロックとxor-itします。その結果、暗号文の各ブロックは、その時点で処理されたプレーンテキストの各ブロックに依存します。
（任意の長さの）元のメッセージをCBC暗号に渡すには、 MACを追加し（整合性チェックハッシュ、通常20バイトのSHA-1）、その後、プレーンテキストを整数ブロック（通常は16バイト）に補完するパディングを行います。
パディング（「スタッフィング」）は、同じバイトで構成され、その長さよりも1つ少ない：
(0)
または
(1,1)
または
(2,2,2)
など。
したがって、暗号文の受信者は
- すべてのブロックを解読します。
- 最後のブロックの最後のバイトを読み取って、パッドの長さを判断し、それに応じてクリアテキストのMAC位置を判断します。
- スタッフィングとMACの正確さを確認してください。
2002年、フランスの暗号作成者Serge Wodenayは、CBCでのパディングオラクル攻撃に対する脆弱性を発見しました。 （MitM攻撃を介して）暗号文を傍受し、最後から2番目のブロックの最後のバイトを変更し、変更した暗号文をサーバーに送信し、その応答を監視する場合-「不正なスタッフィング」と「不正なMAC」の回答の違いにより、256リクエストの最後のバイトを決定できますソースプレーンテキスト。 次に、MitMは最後から2番目のブロックの最後から2番目のバイトの変更を開始し、256個の要求に対してプレーンテキストの最後から2番目のバイトなどを決定します。 -各バイトを復号化するための256リクエスト。
実際、この脆弱性は、HTTPS Cookieを盗むために使用される可能性があります。攻撃者はユーザーを自分のページに送信し、そこでスクリプトは攻撃者が関心のあるサーバーにHTTPS要求を1つずつ送信します。 ユーザーのブラウザーは各サーバーにこのサーバーのCookieを挿入します。攻撃者が制御するMitMサーバーは、ユーザーとHTTPSサーバー間のメッセージをインターセプトし、最後から2番目のブロックの1バイトを変更し、サーバーの反応を監視します。 この方法ですべてのCookieを復号化するのに1分もかかりません。
Woden攻撃から保護するには、サーバーが不正なスタッフィングと不正なMACで同じエラーコードを返すだけで十分と思われます。 ただし、これら2つのケースは、サーバーが応答するまでの時間で区別できます。MACの計算とチェックには、最後のブロックのスタッフィングのチェックよりもかなり時間がかかります。
違いがあってはならないため、スタッフィングまたはMACはテストに合格しなかったため、スタッフィングの内容をまったく確認する必要はないように思われるかもしれません。 しかし、攻撃者がそのような暗号文サイズを選択して、最後のブロックがスタッフィングによって完全に占有され、MitMサーバー上の同じ暗号文からの前のブロックで置き換える場合、サーバーは、置換ブロックの最後のバイトが復号化されていない場合にのみエラーを報告しますin（block_length – 1）。 プロファイルでのみ、同じ「パディングオラクル」が判明します。 この攻撃はPOODLEと呼ばれます。 最新のSSL / TLS実装は、スタッフィングの内容を必ずチェックし、それが正しくない場合、スタッフィングがないと見なし、MACチェックのCBC復号化の結果全体を送信します。 原則として、プレーンテキスト（MACを含む）が最初に整数個のブロックで構成され、同じバイトのシーケンスで終わらない場合、クライアントは完全にスタッフィングで構成される余分なブロックを送信できません。
これらの修正後、パディングオラクルの脆弱性は、2013年に英国の研究者数人がLucky 13攻撃を発明するまで修正されたと考えられました。これは、MAC計算時間がハッシュされた文字列の長さに依存するという事実に基づいています。 SHA-1は64バイトブロックの文字列を処理するため、攻撃者は最後から2番目のCBCブロックの最後の2バイトとしてすべての可能な2バイトの組み合わせを試すことができ、サーバーの応答時間のジャンプは55バイトのハッシュ文字列（1つのSHA-1ブロック;ハッシュされた文字列の最後に、9バイトの「トレーラー」と56バイト（2ブロック）が追加されます。 ダブルバイトスタッフィングとシングルバイトスタッフィングの間：
HTTPSリクエストを65536回インターセプトおよび変更し、毎回サーバーの応答時間を測定することにより、「無菌」ラボ条件で、プレーンテキストの最後の2バイトを復元できます。 実際には、2バイトを回復するのに十分な統計を蓄積するには、この一連の65,536リクエストを100回以上繰り返す必要があります。 したがって、Lucky 13攻撃は理論上の危険にさらされていました。
この攻撃は、「ペイロード」の前にハッシュされたヘッダーのサイズにより、スタッフィングオプションの列挙が2バイトシーケンスに制限されていたため、その名前が付けられました。 このヘッダーが14バイト以上であったかどうかにかかわらず、サーバーの応答時間のジャンプはより短いプレーンテキストで行われ、数百倍の入力オプションを並べ替える必要がありました。 一方、このヘッダーが11バイトであれば、プレーンテキストの8〜9ブロック間の移行でジャンプが発生し、攻撃は完全に不可能になります。 もちろん、最も幸福な数は12です。このような攻撃のヘッダー長では、Woden攻撃のように、最後のバイトの値自体を反復処理するだけで十分です。
「ラッキー13」から保護するために、OpenSSL開発者は驚くべき工夫をしました 。実際、MACとスタッフィングコード全体で分岐を使用することはできません。そうしないと、異なる入力データの検証時間が異なります。 処理するブロックの数に応じて分岐せずにSHA-1の実装の詳細を省略し、テストの最後のステップである、計算されたMAC値をプレーンテキストに記録されたものと比較します。 分岐を回避するために、コードはすべてのプレーンテキストをバイト単位でチェックし、期待値と実際の値の差をANDの「MACマスク」および「スタッフマスク」と組み合わせ、ORのすべてのバイトのチェック結果を組み合わせます。
描かれている32バイトのプレーンテキストは、6バイトのメッセージ、20個のMACバイト、および6個のパディングバイトで構成されています。 スタッキングは12バイト（空のメッセージを含む）より長くすることはできませんが、いずれの場合も、コードはMACを計算し、エラーコードを返す前にメッセージのすべてのバイトをチェックする必要があります。
さて、平文の最後のバイトが「12」-明らかに不可能なパッドの長さである場合、このコードは何をしますか？
MACはメッセージ長-1で計算されます！
結果が何であるかは関係ありません-それは明らかに無意味です。 さらに重要なことは、メッセージ検証ごとに1バイトずつ「シフト」されたMAC検証マスクです。つまり、 結果のガベージ値から19バイトのみがチェックされます。
しかし、MACマスク全体をメッセージの先頭にシフトするとどうなりますか？
これで、MACチェックを無視できます。すべて同じで、差のすべてのバイトはゼロマスクで賛否両論です！ 残っている唯一の障壁は、梱包の内容を確認することです。 そのすべてのバイトは、最後のバイトと等しくなければなりません。 31：
したがって、攻撃者はプレーンテキストが完全に値（暗号文の長さ– 1）のバイトで構成されているかどうかを確認できます。この場合、OpenSSLは暗号文を正しいと見なし、サーバーはより高いレベルのエラー（HTTPエラーなど）を返します。
そのような「オラクル」の使用方法は？ これで、MitMサーバーはWoden攻撃よりもはるかに高度に動作するはずです。 攻撃者のスクリプトが31バイトで終わるPOST要求を31の値でHTTPSサーバーに送信した場合、MitMサーバーは暗号文をインターセプトし、最後の2ブロックのみを取得し、最後から3番目の暗号テキストブロックを初期化ベクトルとして取得し、要求ごとに、最初のバイトを変更します。
最初のバイトIVの値が異なる256回の試行のうち、255回は「無効なMACまたはスタッフィング」エラーになり、1回の試行で別のエラーが発生します。この方法で、POST要求のバイトの最後から32番目を復元できます！
POSTリクエストでパスの長さを1バイト増やし、リクエストの本文をバイト単位で短縮します。これにより、リクエストの31バイト目が最後からわかります。 次に、プレーンテキストの2番目のバイトが再び31になるように2番目のバイトIVを変更し、最初のバイトIVを変更し、再びリクエストバイトの最後から32番目を復元します。
この方法で「強調表示されたバイト」をシフトすることにより、MitMはPOSTヘッダーの最後の16バイトを解読できます。運が良ければ、HTTPS Cookieはこれらの16バイトに含まれます。 復号化の速度は、元のWoden攻撃の場合と同じです：復元されたバイトごとに最大256リクエスト。 Lucky 13に対する保護とともに、OpenSSLはLucky 13自体よりもはるかに深刻な脆弱性を導入しました。
技術面での注意：POST要求が31バイトのシーケンスで終了した場合でも、CBC暗号化の前にMACとスタッフィングによって補完されるため、説明された形式では攻撃は機能しません。 攻撃の準備段階-要求されたパスを変更することにより、MACと実際のスタッフィングが最後の2つのCBCブロック全体を占めるように、POST要求の長さを選択します。 その後、攻撃中、これらの最後の2つのブロックは破棄され、最後から5番目から3番目のブロックが使用されます。 HTTPS要求を生成するスクリプトとMitMサーバーの間にこのような調整を確立すると、攻撃者はCBC復号化の結果が31バイトで31バイトで終了することを確認できます。
要約すると、最初の「パディングオラクル」が発見されてから15年間、そのような「オラクル」を排除しようとするたびに、新しいものの発見（または偶然の創造さえ）が続きました。 CBC暗号を使用したTLSで次のパディングオラクルが検出されるまでにどれくらい時間がかかるのだろうか？