heartbleed-lab

CVE-2014-0160 (Heartbleed) 向けの、小さく自己完結したラボ — OpenSSL 1.0.1〜1.0.1f における TLS ハートビートの過剰読み取り。使い捨てコンテナ内で、ピン留めされたアップストリームソースから実際に脆弱な OpenSSL をビルドして起動し、そこから生きたプロセスメモリを漏洩させる概念実証クライアントを含んでいます。

認可されたラボ利用に限ります。 ここにあるものはすべて localhost / 自分で実行するコンテナを対象としています。PoC を、自分が所有しておらず明示的なテスト許可を持たないホストに向けないでください — 稼働中のシステムに対して Heartbleed を無断で使用することは、ほとんどの法域で犯罪です。Heartbleed は OpenSSL 1.0.1g (2014年4月) で修正されました。このラボはバグを理解するために存在し、誰かを攻撃するためのものではありません。

収録内容

秘密鍵はコミットされていません — 証明書はローカルで生成されます (.gitignore を参照)。

本物を実行する

# 1. Build and start the vulnerable server (needs Docker)
docker build -t heartbleed-lab .
docker run --rm -p 8443:8443 heartbleed-lab

# 2. In another terminal, bleed it
python3 exploit/heartbleed.py 127.0.0.1 -p 8443

脆弱なサーバーは漏洩したメモリの hexdump を出力します。PoC を何度か再実行してください — 各リクエストはヒープの異なるスライスを返します。これこそが Heartbleed がこれほど危険だった理由です。セッション Cookie、フォームデータ、秘密鍵の素材がすべてそこに存在します。

シミュレーション (任意)

cd demo
./gen-cert.sh
python3 server.py

これは CVE ではありません — 常に 64 KB の A を返すだけの教育用スタブです。

バグの仕組み

TLS ハートビートリクエストは、ペイロードと長さフィールドを運びます。脆弱な OpenSSL は攻撃者が指定した長さを信頼し、リクエストバッファからそのバイト数だけをレスポンスに memcpy します — しかしリクエストにはそれだけのデータが含まれていなかったため、コピーはそれを超えて、隣接するプロセスメモリの内容まで読み取ってしまいます。1.0.1g での修正は境界チェックです: if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; — 実際に送信された量を超える量を主張するハートビートは、黙って破棄されます。

修復

• OpenSSL ≥ 1.0.1g にアップグレードするか、-DOPENSSL_NO_HEARTBEATS を付けてビルドします。
• 露出後は、秘密鍵が漏洩したと想定してください: 証明書を再発行して古いものを失効させ、その後、サーバーを通過したセッショントークンや認証情報をすべてローテーションします。