web-dev-qa-db-ja.com

BREACH-HTTPに対する新しい攻撃。何ができますか？

CRIMEに続き、木曜日（今日）にラスベガスのブラックハットで [〜＃〜] breach [〜＃〜] を発表します。リンクされた記事から、この圧縮に対する攻撃は、CRIMEを阻止するために行われたのと同じくらい簡単にオフにすることができないことが示唆されています。このHTTPに対する最新の攻撃を緩和するために何ができますか？

編集：BREACHのプレゼンターは、詳細について website を提示しました。リストされている緩和策は次のとおりです。

  • HTTP圧縮を無効にする
  • シークレットをユーザー入力から分離する
  • リクエストごとにシークレットをランダム化する
  • 秘密を隠す
  • CSRFによる脆弱なページの保護
  • 長さ非表示
  • レート制限リクエスト

（注-この攻撃を明確にするために編集されたタイトルと元の質問も、特にHTTPSではなく、暗号化されている可能性があるHTTPに対するものです）

tlsexploithttpcompression
39
JoltColaOfEvil

記事は詳細でいっぱいではありませんが、いくつかのことを推測できます。

  • 攻撃は [〜＃〜] crime [〜＃〜] と同じ一般的な原則で圧縮を使用します：攻撃者は両方の秘密の値（攻撃者が推測しようとします）、攻撃者が選択できる一部の文字。 選択された平文攻撃 です。 compressedの長さは、攻撃者の文字列がシークレットに「似ている」かどうかによって異なります。暗号化ではlengthではなくcontentsが非表示になるため、SSL暗号化により圧縮された長さがリークします。

  • この記事では特に、「bodyにある[...]の秘密について」と述べています。つまり、SSLレベルの圧縮ではなく、HTTPレベルの圧縮について話しています。 HTTP圧縮は、ヘッダーではなく、リクエスト本文にのみ適用されます。したがって、シークレットヘッダー内、特にCookieの値は、その値から安全です。

  • 「プローブ要求」があるため、攻撃にはクライアントブラウザに悪意のあるコードが必要です。攻撃者はまた、ネットワーク上の暗号化されたバイトを監視し、両方の要素を調整する必要があります。これは、CRIMEおよびBEASTと同じ設定です。

  • 圧縮された本体がclientからのものかserverからのものかは不明です（この記事だけで、これは私が今話し合っているすべてです）。 「プローブ要求」は確かにクライアントによって（攻撃者に代わって）送信されますが、サーバーからの応答には要求で送信されたものの一部が含まれる可能性があるため、「選択された平文攻撃」は両方の方法で機能します。

いずれの場合でも、「BREACH」は攻撃のように見えます方法論ターゲットサイトの特定のケースに適応させる必要があります。その意味で、それはまったく新しいものではありません。圧縮によって情報が漏洩することはすでに「よく知られている」ことであり、HTTPレベルの圧縮が魔法の影響を受けないと信じる理由はありませんでした。ヘック、それは議論されました ここで右 昨年。ただし、一部の人々は作業デモを表示するために余計に努力することは、他の点では欠陥が修正されないためです。たとえば、CBCに対するOracle攻撃のパディングは2002年に説明され、プロトタイプ化さえされていましたが、危険が本物であるとMicrosoftを説得するためにASPに対して実際のデモを行いました。2011年のBEASTも同様です。 （CBCモードの予測不可能なIVの必要性は2002年以降も知られていました）および2012年のCRIME、BREACHはより「CRIME II」です：不信者を打ち倒すための教育学のもう1つの層。

残念ながら、多くの人はそれを誤解し、SSLに対する攻撃であると信じていますが、SSLではありません。 SSLとはまったく関係ありません。これは、低帯域幅のデータチャネルdata lengthを介して情報漏えいを強制する攻撃であり、SSLはこれまでカバーしたことがなく、カバーしたこともありませんでした。

1行のエグゼクティブサマリーは 圧縮しないでください です。

41
Thomas Pornin

BREACHは、CRIMEと同様に、圧縮関連の攻撃です。圧縮をオフにすると、攻撃が不可能になります。

[〜＃〜]追加[〜＃〜]
この場合、異なる圧縮構成をオフにしたように見えることに注意してください。 CRIMEはTLSレイヤー圧縮を利用するのに対し、BREACHはHTTPレイヤー圧縮を利用します。

9
tylerl

CSRF緩和策に「リクエストごとのシークレットのランダム化」、「長さの隠蔽」、「レート制限リクエスト」を追加する方法を考えました。

  1. POSTユーザーに代わって攻撃者に望まないフォームを検討してください。これらは、CSRFから保護するフォームです。
  2. ページビューごとに、ランダムな長さのランダムなソルトを生成します。このソルトを非表示の入力として送信します。ランダムな長さは、フロントエンドのロードバランサーがコメントを削除したり、HTMLを縮小したりした場合でも、長さにノイズを追加するのに役立ちます。
  3. ソルトのハッシュ、セッションID、サーバーサイドシークレットを計算し、このCSRFキーを別の非表示入力として送信します。
  4. オプションで、saltまたはCSRFキーをテーブルに記録します。これにより、特定のユーザーアカウントまたはIPアドレスを1時間あたりのハッシュ数に制限したり、特定のソルトの再生を制限したりできます。
  5. フォームを処理するときは、前の手順と同じ方法でハッシュを計算し、フォームでソルトを使用して、CSRFキーと一致することを確認します。
2
Damian Yerrick

攻撃は、ペイロードサイズから情報を推測することで機能します。提供されたHTTPSページ（ランダムなサイズのコメント文字列など）を人工的にパディングすると、その効果が低下する可能性があります。

1
Max David