Hearbleed脆弱性はSSL接続を処理するサーバーのメモリ内容を盗める脆弱性です。メモリ内には様々な機密情報が含まれています。Webサーバープロセスのメモリ内に保存されている内容は全て盗まれる可能性があります。セッションIDやユーザーのパスワードが盗める場合もあります。Heartbleed脆弱性は任意アドレスのメモリ内容をリモートから自由に読み出す脆弱性なので、サーバーのメモリ内に保存された秘密情報は、SSL秘密鍵に限らず、メモリ内容から盗めます。
影響範囲はシステム構成により異なるので、どのような条件で盗まれるのかまとめました。
大前提は
- 脆弱性があるOpenSSLライブラリを利用している
ことが条件になります。前のブログにも書きましたがシステム構成により影響範囲が変わります。
SSL接続がリバースプロキシで処理されている構成の場合：
- SSL接続をリバースプロキシが処理しているのでSSL秘密鍵が盗める。
- リバースプロキシがマルチスレッドサーバー（nginxなど）の場合、全ての接続のメモリが読み取り可能であるため、メモリに保存された送受信中の他のユーザーの通信情報も盗める。
- リバースプロキシがマルチプロセスサーバー（Apache preforkなど）の場合、前の接続のメモリ内容が残っている可能性があり、その内容を盗まれる。
メモリ内容からSSL秘密鍵以外の重要な情報を取得するには、HTTP認証など、認証をリバースプロキシプロキシで行っていない限り、通信で次々に書き換わるメモリをタイミング良く読み出す必要があります。実際にはリバースプロキシのメモリから別ユーザーの機密情報を盗むことは容易ではないでしょう。（注：認証の事を書くと量が多くなりすぎるので省略しました）
通常、リバースプロキシではWebアプリのプログラムは実行されないので、Webアプリに含まれる秘密情報（利用するWebサービス、データベース、メッセージ認証用などの秘密情報）は盗まれません。プログラムも実行している場合はWebサーバーと同じ条件で影響を受けます。
SSL接続がリバースプロキシで処理されず単純なポートフォワードで処理されている場合：
リバースプロキシのメモリ内容は盗まれません。SSL接続を処理しているWebサーバーのメモリ内の情報が盗めます。Webサーバーが直接SSL通信を処理している場合と同じになります。以下のように場合分けされます。
Webサーバーがマルチスレッドサーバーの場合：
- SSL接続を処理するWebサーバーの秘密鍵が盗める。
- Webアプリに含まれる秘密情報（利用するWebサービス、データベース、メッセージ認証用などの秘密情報）は盗まれる。
- 接続中のユーザー（他のユーザー含む）のメモリ内容を盗める。ユーザーのセッションIDやパスワードなどが盗まれる可能性がある。
JavaのWebサーバー、ApacheのWorker/Event MPM＋mod_*などがこのケースになります。
Webサーバーがマルチプロセスサーバーでプロセスを再利用している場合：
- SSL接続を処理するWebサーバーの秘密鍵が盗める。
- Webアプリに含まれる秘密情報（利用するWebサービス、データベース、メッセージ認証用などの秘密情報）は盗まれる。
- 前に接続したユーザーのメモリ内容が残っている可能性があり、残っていた場合は盗める。ユーザーのセッションIDやパスワードなどが盗まれる可能性がある。
ApacheのPrefork MPM+mod_*やFCGI／FPM、nginx+FPMを利用している場合がこのケースになります。
Webサーバーがマルチプロセスサーバーでプロセスを再利用していない場合：
- SSL接続を処理するWebサーバーの秘密鍵が盗める。
- Webアプリに含まれる秘密情報（利用するWebサービス、データベース、メッセージ認証用などの秘密情報）は盗まれる。
ApacheのCGIやApacheのPreforkのMPM+mod_*を使っていてもMaxRequestsが1の場合（普通は万単位の設定を利用する）がこのケースになります。
SSL秘密鍵が盗まれてしまった場合：
- MITM攻撃などでSSL通信の内容を解読される。
解読される可能性がある情報には過去の通信内容も含まれます。攻撃者はSSL秘密鍵が盗めた場合に解読する為、パケットを記録している可能性があります。ツールが揃っているのでMITM攻撃は「非常に簡単」です。
まとめ
Heartbleed脆弱性の影響はシステム構成によって変わります。サービスの利用者も、念の為にパスワードなど、重要な秘密情報は新しい物に更新すると良いでしょう。
CGIなどを使っているケースは稀でしょう。サービスを提供している方は、SSL接続を処理するWebサーバーが実行するプログラム中に利用された秘密情報は全て更新しなければなりません。
エンドユーザーがセキュリティについて興味を持つことは良いことなのですが、Heartbleed脆弱性にだけ焦点を当てるのではあまり良くありません。ARP spoofingで偽ルーターを設定し、パケット盗むことは簡単です。SSLを使っていても偽ルーターを透過プロキシに設定し、HTTPS通信をHTTPに変換することも簡単です。Heatbleed脆弱性はサイト運営者にとっては致命的な問題ですが、エンドユーザーユーザーにとっては普通の問題と評価しているのは、こういった事が簡単に行えるからです。HTTPSを使ったサイトでも注意していないユーザーから情報を盗む事は簡単であり、ほとんどのユーザーは注意を払っていません。Heartbleedはサイトの問題であり問題の本質が異なりますが、エンドユーザーの不注意によって機密情報が漏れる可能性は普通にあります。
Heartbleed脆弱性を機会により強いパスワードに更新し、HTTPSサイトなのにHTTPであったりするような状態では絶対にサイトを利用しない、信頼性の低いネットワーク（公衆無線LANなど）は極力利用しない、などに注意が向けば良いと思います。
Leave a Comment