Comodo事件はどのようにして起こったのか？

security

先月、大手 CAの Comodoが外部からの攻撃によって、偽証明書を発行してしまうという事件が起こった。本記事では、この事件の問題点の整理、攻撃手法の詳細、改善策の状況などについてまとめたいと思う。

何が起こったのか？

Comodoは認証局(CA)を運用し、SSLで利用される公開鍵証明書の発行などを行っている大手プロバイダの一つ。security spaceの 2010年3月のマーケットシェア調査によると、9%程でシェア5位につけている。(ちなみに GeoTrust, GoDaddy, Verisignの上位3社で50%以上を占める、寡占業界である。)
その Comodoが 3/23付けの自社ブログにおいて、登録局(RA)の一つが外部から侵入されて、不正なSSL証明書が発行されてしまったことを明らかにした。(侵入が起きたのは 3/15のこと。)

SSL認証局が偽の証明書を発行、大手サイトに影響の恐れ (ITmediaエンタープライズ)
http://www.itmedia.co.jp/enterprise/articles/1103/24/news020.html


Comodoから公開されたインシデントレポートによると、発行された証明書は 7つのドメインで合計 9つ。この中には "mail.google.com" "login.yahoo.com" "login.live.com" などの大手サイトが含まれていた。また同レポートでは、イランのテヘランにある ISPに割り当てられている IPアドレスから攻撃が行われたことも明らかにされた。そのため事件発覚当初から、イラン政府や Iranian Cyber Armyの関与などが疑われていた。(Iranian Cyber Armyは 2009年末の Twitterへのハッキングで一躍有名になったグループ*1。イラン政府が組織したと言われている。*2 )

何が問題なのか？

Comodo CAのルート証明書はブラウザ(IE, Firefoxなど)にあらかじめ組み込まれている。だからこそ CAから発行された証明書をブラウザで検証することができる。しかし今回のように正規の CAから偽証明書が発行されてしまうと、原理上は本物と区別がつかない。したがってなんらかの方法(例えば DNSキャッシュポイゾニングなど)で、フィッシングサイトにクライアントを誘導するか、MITM攻撃が行われた場合、見かけ上は本物のサイトにアクセスしているのとなんら変わらないことになる。証明書は正しいものだし、ブラウザはなにも警告を出さない。これでは攻撃を受けていても気がつかないだろう。

不正なSSL証明書（「Comodoケース」） (エフセキュアブログ)
http://blog.f-secure.jp/archives/50581423.html

各社はどういう対応をしたのか？

Comodoは偽証明書が発行されたことがわかると直ちに、対象ドメインの所有者および大手ブラウザ各社に連絡をとった。また発行された偽証明書については失効の手続きをとった。(Comodoのレポートによると、イランのサイトでこの偽証明書が使用されたようだが、その際 OCSPによって「失効」の応答がされた。)
しかし残念ながら、証明書失効リスト(CRL)および OCSPによる証明書の有効性を確認する仕組みは、必ずしも確実というわけではない。(たとえば 2009年に BlackHatで発表された sslstripは MITMによって OCSPを無効にできることを示した。)*3


そこでブラウザ各社は、それぞれ独自の対応をとった。Google (Chrome)および Mozilla (Firefox)はこれらの偽証明書をブラックリストにいれてブロックするための修正を行った。また Microsoft (IE)は更新プログラムを配布し、これらの証明書をローカルの信頼されていない証明書ストアに置くという対応を行った。 *4

このような対応が速やかに行われたため、現在のところ、この偽証明書による被害は報告されていない。

各社の対応
http://www.microsoft.com/japan/technet/security/advisory/2524375.mspx
http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates/
http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html
http://my.opera.com/rootstore/blog/2011/03/31/new-cnnic-ev-root-pubsuffix-update-and-some-blacklisted-certificates
http://support.apple.com/kb/HT4608

そもそもどうしてこんなことに？

このような対応が 3/17から 3/24にかけて行われ、事態は収束に向かった。ところが 3/26に思わぬ方向へと展開。Comodo Hackerと自ら名乗る人物が、Comodoへの攻撃の詳細をネット上に公開したのだ。その後、3/31にかけて合計 6通のメッセージを公開。自分が Comodoに侵入して偽証明書を発行した本人である証拠を示し、攻撃方法の詳細を説明するとともに、様々な主張を行った。

不正SSL証明書の発行事件で「犯人」が手口公表 (ITmediaニュース)
http://www.itmedia.co.jp/news/articles/1103/29/news017.html


Comodo Hackerからのメッセージ
http://pastebin.com/u/ComodoHacker


Comodo Hackerへのインタビュー
http://erratasec.blogspot.com/2011/03/interview-with-comodohacker.html


証拠はすぐさま検証され、本人に間違いないことが確認された。メッセージの内容を信じるならば、Comodo Hackerは 21才のイラン人ハッカーで暗号の研究をしている学生。今回の事件は彼の単独犯行であり、Iranian Cyber Armyとは何のつながりもないとのこと。また Comodoへの攻撃手口は次のようなものだったらしい。

  1. SQL Injectionにより、Instantssl.it (GlobalTrust.it) ほか2つのComodoリセラー(RA)に侵入
  2. Instantssl.itのサーバ(IIS)に侵入後、脆弱性を利用して SYSTEM権限を取得
  3. RDP (Remote Desktop)でサーバにアクセス
  4. サーバを調べる中で、TrustDll.dllという DLLを発見
  5. TrustDll.dll をデコンパイルすると、Comodoのリセラーアカウントのユーザー名とパスワードが埋め込まれていた
  6. このアカウント情報を利用して、API経由で証明書署名要求(CSR)を Comodo CAに送り、偽証明書に署名させることができた


また Comodo Hackerはこれらの他に、なぜ今回の攻撃に至ったのか、その動機を解明する手がかりとなる主張や批判をいくつか行っている。*5

  • Stuxnetは USとイスラエルによるイランに対する謀略である
  • USとイスラエルは Echelonを使って、自分達のメールを盗聴している
  • Microsoftは Stuxnetが利用する脆弱性(のうちの1つ)を 2年間も放置していた
  • Green Movementはイランでは全くの少数派であり、自分も含めてイランの若者は誰も支持していない
  • イスラエルのモサドは MI6と CIAと共同で、イランの原子力科学者を暗殺しようとした
  • 原子力開発はイランという国家に認められた当然の権利である
  • HBGaryは rootkitを US政府に売りつけ、中東にバラまいている
  • USは HAARPや Echelonなどを開発して世界を支配しようとしている

そして、「このような暴挙が行われているのに、世界中の人達はどうしてアメリカを批判しないのか、イランばかりを責めるのか」と憤慨している。(なお上記にあげられた指摘のいくつかは、欧米のメディアでも取り上げられた事件で、どうやら大体は事実らしい。)


これらの主張を額面通りに受け取るのであれば、彼はイランの現体制を支持する熱烈な愛国主義者であり、国際社会に対して断固として戦う姿勢を示している。一人のハッカーが愛国心から行動を起こしたのかもしれないし、イラン政府の手先なのかもしれないし、あるいはそう見せかける謀略なのかもしれない。

SSLの問題があらためて浮き彫りになった？

さて今回の事件をきっかけに、あらためて現在の SSL、というか CAモデルの問題が露となり、改善策についての議論が行われている。今回の件に限らず、過去にも不適切な証明書の発行が問題になったことがある。また最近の EFFの報告によると、localhostなど FQDNでない名前で発行されている不適切な証明書が多数あることがわかったという。要するに、CAに依存した現在のモデルがまずいというわけだ。(過去の問題については、この記事が参考になる。)


改善提案についてまとめると、以下の3つの方法が有力視されているようだ。(3番目はおまけ)

(1) DNS-based Authentication of Named Entities (DANE)
(2) Certification Authority Authorization (CAA)
(3) Google Certificate Catalog


(1) DANEは IETFの WGで検討されている方法。ドメインオーナーが SSL証明書に関する情報を DANE用の DNSレコードで公開し、クライアントが検証できるようにするというものだ。現在のドラフトでは TLSAレコードを利用して、証明書そのものまたはハッシュ値を応答することになっている。DNSSECの利用が前提である。

Using Secure DNS to Associate Certificates with Domain Names For TLS
http://tools.ietf.org/html/draft-ietf-dane-protocol-06


(2) CAAは Comodoと Googleが共同で IETFに提案している方法。DANEと少し似ているが、こちらはドメインオーナーが CAに関する情報を CAAレコードとして DNSで公開する。CAAレコードは、そのドメインの証明書がどの CAから発行されるべきかを決める。DNSSECの利用が強く推奨されている(が必須ではない)。

DNS Certification Authority Authorization (CAA) Resource Record
http://tools.ietf.org/html/draft-hallambaker-donotissue-03


(3) Google Certificate Catalogは Googleが公式ブログで提案した方法。Googleは検索サービスなどを提供するために、クローラーを常時動かして世界中の Webサイトをクロールしている。この時、SSL証明書も全て記録しているらしい。そこでこの証明書のハッシュ値をカタログとして DNSに登録し、誰でも参照できるようにしようというもの。というかもう実際にテストサーバが動いているので、certs.googlednstest.comの TXTレコードを参照することでハッシュ値を確認できる。

Improving SSL certificate security
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html


3番目はおまけとして、DANEと CAAはいずれもドメインオーナー側で証明書のコントロールができるようになっており、仮に CAが自ドメインに関する不適切な証明書を発行してしまったとしても、影響を受けないような仕組みになっている。


一方で、DNSSECの導入による現状の SSLへの改善提案について、反対する意見もある。例えば、著名なセキュリティ研究者である Moxie Marlinspike氏は自身のブログで次のような批判をしている。(彼はさきほど紹介した sslstripの開発者でもある。)

  • DNSSECも CAと同じような階層的な信用の構造をもっており、何も変わらない。
  • DNSSECを使うとなると、次の3つを同時に信用しなくてはならない。すなわち、レジストラ、TLD (.comなら Verisign)、ICANNである。これらを将来にわたって信用することがはたして正しいことか。
  • 何か問題が起きた場合、速やかに修正できることが大事。(彼は Trust Agilityと呼んでいる。) 現行のCAモデルなら、信用できない CAのルート証明書を自分で取り除くことができる。しかしDNSSECになってしまったら、そのようなことは簡単にはできない。Trust Agilityのない解決策に未来はない。


確かにもっともな批判と思われる。彼は代替策の提案を近々するとも書いている。どんな内容がでてくるのか注目したい。いずれにせよ、DNSSECを導入すれば全て解決！というような単純な問題でないことは確かだ。

*1:http://techcrunch.com/2009/12/17/twitter-reportedly-hacked-by-iranian-cyber-army/

*2:http://en.irangreenvoice.com/article/2010/feb/19/1236

*3:https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

*4:ちなみに Operaは 3/31、Appleは 4/14に対応した。遅すぎる。

*5:http://arstechnica.com/security/news/2011/03/independent-iranian-hacker-claims-responsibility-for-comodo-hack.ars