Heartbleed についての議論は、そのほとんどが脆弱な公開 Web サイトに集中していますが、このバグの影響はそれ以上の範囲に及んでいます。利用者の多いサイトのほとんどはすでに対応済みですが、だからといってエンドユーザーが警戒を緩めていいわけではありません。
Heartbleed の影響は、クライアントソフトウェアにも等しく及びます。いくつか例を挙げるだけでも、Web クライアントや電子メールクライアント、チャットクライアント、FTP クライアント、モバイルアプリ、VPN クライアント、そしてソフトウェアアップデータなどが該当します。要するに、脆弱なバージョンの OpenSSL を使って SSL/TLS 通信を行うクライアントであれば、どれも攻撃を受ける恐れがあるのです。
しかも、Heartbleed は Web サーバー以外のさまざまなサーバーにも影響します。プロキシ、メディアサーバー、ゲームサーバー、データベースサーバー、チャットサーバー、FTP サーバーなどです。それどころか、ハードウェアデバイスでさえ Heartbleed 脆弱性の影響は免れず、ルーター、PBX（ビジネス電話システム）、そしておそらくは IoT（モノのインターネット）に分類される無数のデバイスにも影響は及びます。
Heartbleed 脆弱性を悪用してこうしたソフトウェアやハードウェアサーバーに攻撃を仕掛ける手口は、脆弱な Web サイトに対する攻撃に似ています。ただし、クライアントに対する攻撃は実質上、逆の方向でも起きることもあります。
Heartbleed の悪用については、攻撃側のクライアントが脆弱なサーバーに悪質な Heartbleed メッセージを送り付けることで、サーバーが個人データを漏えいしてしまうと説明されています。しかし、その逆方向でも攻撃は成り立ちます。脆弱なクライアントがサーバーに接続し、サーバー自身が悪質な Heartbleed メッセージをクライアントに送信すれば、クライアントはそのメモリ上にある別のデータを伴って応答するため、資格情報や個人データが公開される可能性があるからです。
図 1. 脆弱なクライアントに対する攻撃方法は、基本的にサーバーに対する攻撃方法の逆
幸い、クライアントに脆弱性があるとしても、現実的にはそれを悪用することは難しいと考えられます。この攻撃の主な経路は、悪質な SSL/TLS サーバーにアクセスするようクライアントに指示するか、別の脆弱性を悪用して接続を乗っ取るかの 2 つですが、攻撃者にとって複雑さが増すという点では同じです。
クライアントから悪質なサーバーへの誘導
クライアントを悪用できる最も単純な例は、脆弱な Web ブラウザを介した攻撃です。被害者を欺いて悪質な URL にアクセスさせるだけで、攻撃側のサーバーはクライアント Web ブラウザのメモリにアクセスできるようになります。そうなると、以前のセッションの cookie、アクセスしたことのある Web サイト、フォームデータ、認証資格情報といったコンテンツもリスクにさらされることになります。
広く利用されているブラウザのほとんどは OpenSSL ではなく NSS（Network Security Services）のライブラリを使っています。NSS は Heartbleed に対して脆弱ではありませんが、Web クライアントも多くのコマンドラインでは OpenSSL を使っており（wget、curl など）、やはり脆弱です。
攻撃者にとってはユーザーを欺いて悪質なサイトにアクセスさせるという手間が掛かるので、いくぶんリスクは軽減されますが、その手間が掛からない場合もあります。たとえば、フランス語で書かれたページの URL を入力すると、そのコンテンツが英語に自動的に翻訳されるオンライン翻訳サービスを例に考えてみましょう。この翻訳サービスは、独自のバックエンドクライアントを使ってフランス語ページのコンテンツを取得します。このとき悪質なサーバーの URL を入力すればバックエンドクライアントを悪用して、この翻訳サービスからコードや資格情報といった重要な情報を盗み出せることになります。
接続の乗っ取り
前述のように、クライアントを悪質なサーバーに誘導するには、任意のサーバーにアクセスするようクライアントに指示する必要があります。確かに、多くのクライアントが接続するのは、ハードコード化された、あらかじめ定義されたドメインだけかもしれませんが、そうした場合でも、やはりクライアントの悪用は可能です。一部の公共 Wi-Fi ネットワークのような共有のオープンネットワークでは、他人がトラフィックを傍受して変更できる可能性があるため、攻撃者は脆弱なクライアントをリダイレクトできます。通常であれば、この問題のひとつの解決策となるのが SSL/TLS（たとえば、暗号化された Web ブラウジングである HTTPS）です。暗号化すれば、傍受もリダイレクトも防げるからです。ところが、SSL/TLS セッションが完全に確立する前であれば、悪質な Heartbeat メッセージを送信することが可能です。
攻撃者は、公共のネットワークに参加して、無防備なユーザーの通信を傍受することができます。無防備なユーザーが、正規のサーバーへの SSL/TLS 接続を確立する際に脆弱なクライアントを使っている場合、攻撃者はその接続を悪質なサーバーにリダイレクトします。SSL/TLS 接続が完全に確立される前で、リダイレクトを遮断するチャンスがある段階であれば、攻撃者は悪質な Heartbeat メッセージを送信して被害者のコンピュータのメモリから内容を抜き取ることができます。これには、認証資格情報などの個人データが含まれているかもしれません。
図 2. 共有のオープンネットワーク上で攻撃者が脆弱なクライアントを乗っ取ってリダイレクトする仕組み
以前のブログに示した注意事項に加えて、以下の推奨事項にも従うようにしてください。
- どのようなクライアントソフトウェアを使っている場合でも、不明なドメインにはアクセスしないでください。脆弱な OpenSSL ライブラリを使って Heartbeat メッセージを受信してしまうかもしれません。
- パッチが適用されていないプロキシサービスは使用しないようにしてください。
- ソフトウェアもハードウェアも、ベンダーからパッチが公開されたら速やかに更新してください。
- 公共のネットワークでは、Heartbleed に対して脆弱でないことが確認されている VPN クライアントやサービスを使用してください。
* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。