セキュリティの論点

「Heartbleed」問題の原因と対策--バージョンアップとSSL証明書の再発行を - (page 2)

中山貴禎(ネットエージェント)

2014-05-10 07:30

なぜ「くり返し何度でも」取得可能なのか

 なぜ「くり返し何度でも」取得可能なのか。実は、この脆弱性はSSL通信のハンドシェイクの段階でも起きるため、多くの場合ログに攻撃された記録が残らないのです。従って、攻撃されたかどうかの判別が非常に困難、というわけです。

 SSL通信に利用するメモリには、ユーザーのセッションIDや公開鍵、サーバのSSL証明書の秘密鍵など危ないデータも格納されています。脆弱性の性質上、さすがに特定のユーザーを狙って直接個人情報を取得するのは難しいですが、言ってみれば「当たりが出るまで宝くじを買い続ける」=プロセス内の全ての情報を取得することは可能なのです。

 もし悪意ある第3者がこの脆弱性を突いて攻撃を仕掛けた(=Heartbeatパケットを送信し、1回につき最大64Kバイトの追加情報をくり返し要求した)場合、クリアされずメモリ上に残っていた、httpd.confや.htaccess、htpasswdファイルの内容、そして直近の通信の「復号済=平文の通信内容」といったデータを盗み見られる可能性があります。

 またPHPなどの利用でSSL処理とアプリケーションコードのプロセスが同一、例えばApacheのモジュールとしてmod_php5やmod_perlなどを利用してウェブアプリケーションを動かすような構造のサービスでは、上記に加えてすべてのアプリケーションコード、さらにはOAuth認証のconsumer_secretやCookieベースセッションの暗号化キー(secret_token/secret_key_base)といったアプリケーション設定、データベースなどへの接続先やユーザID&パスワード、そこから取得したデータなども、盗み見られてしまう可能性があります。

 恐ろしくも万が一SSL証明書の秘密鍵が残っていて、それを持っていかれた場合、過去の通信内容を保存しているサービスの場合はその内容も自由に盗み見ることが可能ですし、SSL証明書の更新(毎年)時に都度秘密鍵を作り直していない場合はどこまでも過去に遡及できてしまいます。

 そしてもう1つ怖いのは「持っていかれた正当なSSL証明書を利用した、本物と証明された偽サーバ」公開、という可能性です。

 もし仮に、この正当なSSL証明書を利用した偽サーバへ、公衆無線LAN経由や“DNSへの毒入れ攻撃(DNSポイズニング)”併用 などでの「正しいドメインでの誘導」を実行された場合、本物のウェブサイトと全く同じ証明書でサーバを公開しているわけですから、当然ながらブラウザのアドレスバーには正しいドメインで証明書(鍵)が表示されますし、これを偽物と見抜くことは困難を極めるでしょう。

 そう簡単に能動的な侵入を許すような脆弱性ではないとはいえ、日常的に多くの人が利用しているインターネット上のサービスにおいて、秘密性を担保するために利用されているこの暗号化ライブラリに、稚拙な欠陥と言わざるを得ない、このような脆弱性が実は2年以上前から存在した。そして、実際に過去2年間どういった被害が出たのか、何らかの重要な情報が閲覧されたのかどうかの確認は現実的に不可能。これが本件の概要です。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]