Diary

│2014年04月16日 Yuji Suga│

Heartbleed bug によるサーバ設定の状況変化

本稿では日本時間 2014 年 4 月 8 日未明に公開された HeartBleed bug について取り上げます。

本脆弱性は OpenSSL 1.0.1 から 1.0.1f および 1.0.2beta1 において Heartbeat メッセージの処理において境界チェックの問題があり、OpenSSL が動作しているマシンのメモリ情報を取得可能な状態にあったことが公表されました ^[1]。

RFC6520 で策定されている Heartbeat プロトコルは、リクエスト-レスポンス型の 2-way で完結する簡易なプロトコルで、SSL/TLS の Record レイヤ、つまりハンドシェイクと同じレイヤで送受信されます。 SSL/TLS のハンドシェイク中にいきなり Heartbeat リクエストが送られてしまうと、それを受け取った OpenSSL ライブラリは境界チェックのバグを誘発し、メモリ領域のデータをレスポンスしてしまいます。 このとき OpenSSL では受け取った Heartbeat リクエストと同じ長さのレスポンスを返すように実装されています。 Heartbeat プロトコルでは Length 情報として 2 バイトが割り当てられているため、最大で 0xFFFF バイト分のメモリ情報が漏洩することが確認されています。

既に OpenSSL 1.0.1g でパッチが公開されており、1.0.1g にアップデートする、もしくは Heartbeat を無効にするコンパイルフラグをつけて再インストールを行うことで問題が解消されます。 本脆弱性により他ユーザの ID/Password や Cookie が見られてしまう、サーバ証明書の秘密鍵が抜き取られてしまうなどの被害が実験で指摘されています。 1.0.1 が公開されてから 2 年が経過していること、メモリ情報を搾取された際にログが残らないことから、早急な対応が必要であると認識されています。

特に、サーバの秘密鍵が漏れた場合には、その情報を悪用して本物と判断される偽サーバを構築される可能性があります。 同様のケースで Forward Secrecy を持つ CipherSuites を使っていない場合には、過去に記録された暗号通信が復号されてしまいます。 そのため、複数の認証機関では秘密鍵を作り直し、サーバ証明書を再発行することが推奨されています。

サーバ証明書再発行の状況

証明書再発行の状況について調査した結果を報告します。 まず調査対象のサイトを選定するために Alexa top 1 million sites ^[2] を用いました。 そのうち 2014 年 3 月 28 日から 30 日に収集された .jp ドメインの 17988 サイト、4 月 2 日から 6 日にかけて収集された Alexa top sites の上位 20000 サイトの SSL/TLS 接続情報を用いて証明書再発行の状況を調査しました。 ここで SSL/TLS 接続が確立したとしても共用サーバの利用など意図せず SSL を有効にしているケースが見受けられるため、サーバ証明書の FQDN マッチングが OK なもののみを取り上げています。 これは通常のブラウザにおいてエラーを起こさないように設定されており、実際に SSL/TLS が利用されていると考えられるサーバのみを調査対象とするためです。

その結果、以下のサーバ (重複あり) について調査を行っています。

OpenSSL Security Advisory が公開された 4 日 8 日朝 4 時半頃の 36 時間後から 24 時間ごとに上記サーバの証明書を取得して、HeartBleed bug の公開前の証明書との比較を行ないました。 4 日 8 日朝 4 時半よりも後に発行されたと考えられる証明書の数を列挙していきます。 括弧内の数字は、そのうち有効期限に変化が無いが異なる証明書に差し替えられた数を示しています。これも、今回の問題への対応として証明書を差し換えた場合に相当すると考えられるためカウントしました。

脆弱性公開の 36 時間後にはすでに多くのサイトで秘密鍵漏洩のリスクが理解され、証明書の再発行が行われていることが分かります。 特に Alexa top sites の上位に位置するサーバ群ではその対処の迅速さが目立ち、36 時間後には 7.3%、60 時間後には 10.1%、84 時間後には 12.3% のサーバで安全な状態に改善されていました。 なお、証明書の差し替えが行われたサイトに本脆弱性の問題があったかどうかについては不正アクセス禁止法などに抵触すると考えられるため調査を行っていません。

Heartbeat対応状況の変化

また、同じ調査対象サーバにおいて Heartbeat 対応かどうかについて調査を行ないました。 Heartbeat 対応・非対応を同定できたサーバのうち、Heartbeat 対応サーバの割合を以下に示します。

本脆弱性の対策のひとつは Heartbeat を無効にすることです。 しかし実際にはHeartbeat を無効にせずに OpenSSL を最新版にする対処が行われていることが分かります。 なお、84 時間以降についてはほぼ変化が見られないため記載を行っておりません。

OpenSSL を用いて実装された SSL サーバ以外の問題

現在は Web サーバにおける問題が注目されていますが、OpenSSL のライブラリをリンクしたクライアントや、ライブラリを組込んで利用している製品についても影響範囲が広がっています。 Heartbeat プロトコルは SSL クライアント・SSL サーバのどちらがトリガーになってリクエストを送信可能なため、SSL サーバだけでなく当該バージョンの OpenSSL を用いた実装、例えば SSL クライアントや組み込み機器も悪意のあるサーバに接続することで被害を受けることになります。現時点で利用されている場合には脆弱性対応関連情報に注意することをお勧めします。

-

 

カテゴリー :

脆弱性   技術解説  

タグ :

Cryptography   SSL   TLS   Vulnerability  

この記事のURL :

https://sect.iij.ad.jp/d/2014/04/157355.html