脆弱性と攻撃をめぐる事件と話題：Beyond Zero-day Attacks（1）（1/2 ページ）

話題となったHeartbleedをきちんと理解できていますか？ 本連載では、ゼロデイ攻撃を議論するための基盤となる「基本的な技術情報」をまとめます。

[高橋 正和（日本マイクロソフトチーフセキュリティアドバイザー），＠IT]

連載目次

セキュリティ、“ちょっとだけ技術寄り”の基礎固め

　「セキュリティ」という言葉が普及したことで、より「分かりやすいセキュリティ」が求められるようになりました。そして、その反動なのか、セキュリティに関する具体的な技術詳細について取り上げられる機会が少なくなったように思います。私自身、広く理解される内容を求められることが多く、少々フラストレーションが溜まっているような気がしています。

　そこで、機会が少ないのであれば自分で取り上げてみようと、「誰もが理解できる」ことは忘れて、「Beyond Zero-day Attacks 〜ゼロデイ攻撃をめぐる攻防〜」と題したセミナーを、INTEROP Tokyo 2014においてトレンドマイクロの新井さんと企画し、少し深い技術領域に踏み込んでみました。このセミナーを通じて、「基本的な技術情報」を流通させていくことの重要性を改めて実感した次第です。

　技術は詳細になるほど多岐にわたり、しかも私もよりも詳しい方が大勢いらっしゃることは承知していますが、ゼロデイ攻撃を議論するための基盤となるような、OSやアプリケーションの「基本的な技術情報」をまとめてみたいと考えています。

啓発のためのセキュリティと、専門家としてのセキュリティ

　自分でも何がそんなに気になるのだろう？ とも思うのですが、2014年3月から5月にかけて報告された脆弱性や事件、そしてその対応について、何かスッキリしない気持ちを抱え続けています。私が気になる、つまり不安に思っているのは、一連の問題が個別の問題としてとらえられている点と、単に脆弱性と対策プログラムの有無として議論されている点にあるようです。

　例えば、OpenSSLのHeartbeatの脆弱性（CVE-2014-0160）は、単にパッチを当てるだけではなく、サーバー証明書の再発行、サーバー利用者に対してパスワードの変更を促すといった対策が必要とされます。加えて、サーバー証明書の再発行については秘密鍵の変更も必要です。しかし、この一連の対策は、脆弱性、想定される被害の仕組み、証明書とPKIのメカニズムが頭に入っていないと、理解することができない内容だと思います。

図1 OpenSSL Heartbeatの脆弱性を使ったサーバー証明書の詐取

　そして、DNSキャッシュポイズニングの一件、秘密鍵の解読は限定的な情報で十分であるという報告、サポートが終了したInternet Explorer 6のデフォルトでの証明書の有効性確認などを合わせて考えると、インターネットの信頼の起点（Trusted Anchor）が揺らいでいるように思われます。

【関連リンク】

JPCERT/CC OpenSSL の脆弱性に関する注意喚起

　https://www.jpcert.or.jp/at/2014/at140013.html

キャッシュポイズニングの開いたパンドラの箱 -1-


　http://www.e-ontap.com/dns/endofdns.html

Heartbleed bug による秘密鍵漏洩の現実性について

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

Internet Explorer 7 における HTTPS セキュリティの強化点（Windows IETechCol）

　http://msdn.microsoft.com/ja-jp/library/bb250503(v=vs.85).aspx

　ところが、専門家からも「Heartbeatの問題はから騒ぎではないか」とのコメントをいただくなど、この問題の脆弱性と攻撃手法の問題（図1）だけが着目され、インターネットの信頼の起点に関わる問題という視点（図2）でとらえている方は少ないように思います。

図2　Heartbeatの脆弱性を悪用した偽サイトへの誘導とMan in the Middle

　また、2014年のゴールデンウィークは、Internet Explorerに対するゼロデイ攻撃に悪用されたMS14-021（セキュリティアドバイザリ2963983）が話題となりました。

　MS14-021は、日本では攻撃が確認されていませんでしたが、TVや新聞で数多く報道され、多くの企業や組織が対策に追われました。ゼロデイ攻撃は、すべての更新プログラムが適用されていても、対策できない脆弱性に対する攻撃です。つまり、該当する脆弱性の対策だけを実施しても、他に悪用可能な脆弱性が残っていては対策にはなりません。この点は、明確に認識する必要がある点だと考えています。

　MS14-021が公開されるまでの回避策として、Internet Explorer以外のブラウザーの利用も推奨されましたが、ブラウザーを変えれば安全になるわけではありません。別のブラウザーを利用する際に必要な安全策についても、併せて言及する必要があったのではないかと考えています。

　一方で、マイクロソフトが公式に発表している「効果が確認された緩和策」については、Vector Markup Language（VML）を無効にする対策以外は、あまり取り上げられることがなかったように思います。

　マイクロソフトが公表した「効果が確認された緩和策」

1. VMLを無効にする
2. 拡張保護モードを有効にする
3. EMETを導入する

　拡張保護モードやEMETによる緩和策を理解するためには、脆弱性とは何か、攻撃コードはどのように脆弱性を悪用するのか、システム（OSやアプリケーション）が実装している対策とは何かについて、十分な知識が必要となります。このため、エンドユーザーの緩和策としては少々難しいかもしれませんが、IT部門やセキュリティ部門を持つ企業では、必ずしも難しい対策ではないように思います。

　これらの事案を振り返ると、適切なリスク評価と対応・対処を進めるに当たっては、技術的な詳細を十分に理解することが必要になっています。そして、セキュリティに関する情報の収集、適切な対策の実施、インシデントの対応などを行うCSIRTと呼ばれる組織の重要性が高まっているのだと思います。