mpgn/poodle-poc🐩 Poodle (Padding Oracle On Downgraded Legacy Encryption) 攻撃 CVE-2014-3566 🐩
Poodle攻撃（Padding Oracle On Downgraded Legacy Encryption）の概念実装:
SSL 3.0へのフォールバックを利用する、インターネットおよびセキュリティソフトウェアのクライアントに対する中間者攻撃
Poodle攻撃は、使用されているTransport Layer SecurityがSSLv3の場合に、クライアントからサーバーに送信された暗号化データを取得することを可能にします。リクエストの暗号化に使用された秘密鍵を取得することはできません。
SSLv3はデータを暗号化・復号化し、保護するためのプロトコルです。この場合、CBC暗号モード連鎖 を使用します。平文は暗号アルゴリズム（AES、DES、3DES）に応じてブロックに分割され、長さは8または16の倍数になります。平文が長さを満たさない場合、欠けたスペースを補うために最後にパディングが追加されます。このREADMEを読む際には、暗号化と復号化の画像を開くことを強くお勧めします。
| 暗号化 | 復号化 |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
基本的にこれは単純なXORにすぎません。このビデオ（私のものではありません）も見ることができます: https://www.youtube.com/watch?v=0D7OwYp6ZEc
SSLv3を使用してHTTPSで送信されるリクエストは、AES/DESとCBCモードで暗号化されます。TLS1.xに対するSSLv3の特徴はパディングです。SSLv3のパディングは、最後のバイトを除いてランダムなバイトで埋められ、最後のバイトはパディングの長さに等しくなります。
例:
T|E|X|T|0xab|0x10|0x02 ここで 0xab|0x10|0x02 はパディングです。
T|E|X|T|E|0x5c|0x01 ここで 0x5c|0x01 はパディングです。
また、最後のブロックはパディングの完全なブロックで埋められることがあり、つまり最後のブロックは最後のバイトを除いてランダムなバイトで埋められる可能性があります。
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 ここで |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 はパディングであり、攻撃者が知ることができるのは 0x07 だけです。したがって、攻撃者がパディングブロックに影響を与えることができれば、最後のブロックの最後のバイトがブロックの長さに等しいことを知ることができます。
攻撃者は、被害者にリクエストを送信させることができなければなりません（たとえばXSSを悪用したJavaScriptを使用して）。そうすれば、各リクエストのパスとデータを制御できます。
例: リクエストのパスに「A」バイトを追加する
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
この手法により、攻撃者はパディングに影響を与えることができます。
SSLv3は、平文の完全性をチェックし認証するために HMAC も使用します。
鍵付きハッシュメッセージ認証コード（HMAC）は、暗号学的ハッシュ関数（そのため「H」）と秘密の暗号鍵を組み合わせた、特定のタイプのメッセージ認証コード（MAC）です。
このため、攻撃者はリクエストを傍受して改変し、再度送信することはできません。サーバーが問題に遭遇した場合、HMACエラーを送信します。
SSLv3プロトコルは次のルーチンを使用します。クライアントからデータを受信し、データを復号化し、HMACで完全性をチェックします。
MAC-then-Encrypt: 暗号文に対して完全性を提供しません。メッセージを復号化するまで、それが本当に正規のものか偽造されたものかを知る方法がないためです。 平文の完全性。 暗号スキームが可鍛的（malleable）である場合、メッセージを改変して有効に見せ、有効なMACを持たせることが可能かもしれません。もちろん、これは理論上の話であり、実際にはMAC秘密 > が保護を提供するはずです。 ここでは、MACは暗号化されているため、平文に関する情報も提供できません。
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
つまり、サーバーに知られずに暗号文を改変できるということです。これは本当に素晴らしいことです :)
まず、最後のブロックがパディングで完全に埋められている必要があります。前述のように、攻撃者はリクエストのパスを使用して、リクエストの長さをチェックします。
最後のブロックは最後のバイトを除いてランダムなバイトで埋められているため、攻撃者はこの最後のブロック Cn を、復号化したいブロック Ci に置き換えることができます。改変されたリクエストはサーバーに送信されます。
サーバーは:
最後のブロックを置き換えることで、攻撃者は最後のブロックの最後のバイト（パディングの長さ）も変更します。パディングブロックで置き換えられた最後のバイトが元のバイトと同じである確率は1/256であり、この場合パディングエラーは発生しません。攻撃者はこのXOR演算を使用して、ブロック Ci の最後のバイトを次の演算で取得できます:
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
（xxxxxxx7 または xxxxxxx15 であり、xはランダムなバイト）
ブロックの最後のバイトは次のように取得できます: Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] パディングの場合、攻撃者はSSLセッションを閉じて別のハンドシェイク（新しいAES鍵）を行い、新しい暗号を取得してから最後のブロックを置き換えるなどする必要があります（通常+300回のハンドシェイクが必要）。
1バイトが取得できたら、パスに1バイトを追加し、データから1バイトを削除することで、ブロックの他のすべてのバイトを取得できます:
| バイトE,I,K,Oを取得するためのリクエスト |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
TLS仕様ではサーバーにパディングのチェックが義務付けられているにもかかわらず、一部の実装はそれを適切に検証できないため、SSL 3.0を無効にしてもPOODLEに対して脆弱なサーバーが存在します。
TLSは通常Poodleに対して安全ですが、一部の実装はパディングをチェックしないため、SSLv3を使用しているのと同じことになります。これが一部のTLSバージョンが脆弱な理由です。
このリポジトリには3つのファイルがあります:
poodle-poc.py -> 前提条件を必要としない概念実証（PoC）parallelization-poodle.py -> 並列化を使用した別の概念実証（非常に高速）poodle-exploit.py -> 実際のシナリオのためのエクスプロイトこのPoCは攻撃の背後にある暗号技術を探求します。このファイルにより、攻撃がどのように機能するかを簡単な方法で理解できます。
python3 poodle-poc.py
parallelization-poodle.py ファイルはプロジェクトであり、アイデアです :) 確認: https://github.com/mpgn/poodle-PoC/issues/1
python3 parallelization-poodle.py
これは実際のエクスプロイトです。ペンテスト中に、古いサーバーとブラウザを使用しているクライアントに対してPoodle攻撃の概念実証を行いたい場合に非常に便利です。悪意のあるプロキシのIPを正しいポートとともにブラウザの設定に設定するだけで、プロキシが残りを処理します。
前提条件:
security.tls.version.min: 0 を使用してSSLv3のみを強制します。あるいは、クライアントがTLSも使用している場合は、ダウングレードを強制できます
💀 これらの前提条件を満たしていれば、攻撃を開始できます 💀:
このエクスプロイトには2つのオプションがあります:
$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
arpspoof、ettercap、または bettercap を使用してARPスプーフィング攻撃を実行します$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on
⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h 13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
[--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
proxy port server rport
Poodle Exploit by @mpgn_x64
positional arguments:
proxy ip of the proxy
port port of the proxy
server ip of the remote server
rport port of the remote server
optional arguments:
-h, --help show this help message and exit
--start-block START_BLOCK
start the attack at this block
--stop-block STOP_BLOCK
stop the attack at this block
--simpleProxy SIMPLEPROXY
Direct proxy, no ARP spoofing attack
$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50
ブロックの選択: ブロックオプションを指定しない場合、すべてのブロックが復号化されますが、これには長い時間がかかる可能性があります。リクエストがどのようにフォーマットされるかを「把握」し、スクリプト request-splitter.py を使用して復号化したいブロックを特定することを強くお勧めします（理想的にはCookieブロック！ :)）
次に、悪意のあるJavaScriptコード（poodle.js）を、たとえばXSSを使用して脆弱なWebサイトに挿入します。Pythonスクリプトを起動し、help と入力してから search、最後に active と入力します。その間、JavaScriptとのやり取りは2回だけ必要です（searchコマンドとactiveコマンド）。
更新: 2018年1月4日: エクスプロイトにダウングレードオプションが追加されました。エクスプロイトがTLSプロトコルを検出したら、コマンド downgrade を入力してSSLv3.0にダウングレードします。
仕組み: ハンドシェイク中（hello clientの後）、エクスプロイトは handshake_failure 15030000020228 を送信し、ブラウザはデフォルトプロトコルとしてSSLv3.0を使用するhello clientを再送信するはずです。Chromeバージョン15でテストされましたが、Firefoxでは動作しません（Firefoxはプロトコル再ネゴシエーションをサポートしていないと思います）。#4 を確認してください。
エクスプロイトの全ビデオ:
Asciinema:
