Codenomicon 社の CEO が Heartbleed 発見の経緯やリスクの深刻さ、対処策について語る。
「最初の傷が一番深い(The First Cut Is the Deepest)」という歌をご存じだろうか? 残念ながら、今世間を賑わせている Heartbleed バグに関して言えば、この歌は全く当てはまらない。なぜなら、このバグでオンライン上のセキュリティが負った傷について知れば知るほど、その深さと危険度は増していく一方だからだ。
グーグルのエンジニア、ニール・メヒタとフィンランドのセキュリティー企業 Codenomicon 社が個別に発見した Heartbleed は、「近代のウェブを襲う最も深刻なセキュリティー問題の一つ」とされている。Heartbleed を発見、命名した Codenomicon 社のチームを率いる CEO、デビッド・シャルティエを取材して、その経緯と今後の展開について詳しく聞いてみた。
(グーグルを経由してメヒタにもインタビューも依頼したが、グーグルには断られてしまった。)
Heartbleed は皆を傷つける
Heartbleedは本来、些細なバグであった。とあるプログラマーの軽いミスによってこの世に生みだされてしまったものだ。もしも早期に発見されていれば、プログラム・コードをちょっと修正する程度でことは済んでいただろう。しかしそうはならなかった。このバグは今や広く波及し、インターネットの大半を危険にさらしている。
一番の問題は、このバグがウェブ・サーバの 2/3 が利用しているオープンソース・セキュリティー・プロトコル、OpenSSL に影響を及ぼしていることだ。さらに、誰にも気づかれないまま 2 年もの歳月が経ってしまったことも事態を深刻化している。もしこのバグに気付いた者がいれば、Web 上のあらゆるサイトやサービス、アカウントに侵入するのに十分な時間があったことだろう(NSA はこのバグを利用していたとの報道もなされているが、ホワイトハウスはこれを否定している)。
当初の報道では、ユーザーのログイン情報や金融情報、電子メール、写真、医療記録等がハッキングされる恐れがあるとされていた。しかし Heartbleed はさらに大きな問題へと発展するかもしれないのだ。このバグは OpenSSL を利用するあらゆるサーバーに影響するため、ルーターや電話、市町村のインフラ、公共交通手段、緊急医療サービス等をも巻き添えにする可能性がある。
Heartbleed 発見の経緯
Codenomicon 社が最初に Heartbleed(当初はCVE-2014-0160と呼ばれていた)を発見したのは、自社のソフトウェアの定期検査を行っていたときだった。調査員たちは自社のシステムをテストするため、外部のハッカーを装って攻撃していたのだ。
「弊社は『Safeguard』という、暗号化や認証を自動的にテストするソフトウェアを開発しました。」とシャルティエは言う。「OpenSSL を使った自社のインフラでこの製品をテストしてみたところ、Heartbleed バグを発見したのです」。
Codenomicon 社のエンジニアはセキュリティ・レイヤーを突破できてしまうことに気づき、アクセス可能な情報の多さに衝撃を受けた。メモリや暗号化証明書にアクセスし、ユーザーの個人情報やその他の記録を引き出すことができてしまうのだ。「この瞬間に我々は、非常に重要なバグを発見したことに気付いたのです」とシャルティエは語った
シャルティエは、このバグがもたらす被害はもちろんのこと、その被害が水面下で進行するという性質に驚愕したという。「何しろデータが盗まれても一切痕跡が見つからないのです」。ハッキングを追跡するのは完全に不可能なのだ。
しかし、なぜこれほど酷いバグが 2 年間も気づかれずに放置されてしまったのだろう?それは、エラーがコードに埋もれてしまっていたからだ。シャルティエの率いるチームがこのバグを発見できたのは、Codenoicon の厳しく包括的な試験プロセスによるものである。彼のチームはまるで筋金入りのハッカー達のように膨大なテストケースを作成し、脆弱性をひたすら探したのだとシャルティエは説明している。
「複数のテストを繰り返さないと発見できない脆弱性のほうが、すぐに見つかるものより興味を引きやすいものです」と彼は言った。「複雑なバグほどハッカーは喜ぶのです。なぜなら悪用しても気付かれるまでに時間が掛かるからです」。
今回のバグを発見できる可能性は決して高くはない。しかし、グーグルのメヒタも 3 月に行われた定例セキュリティー・チェック時に Heartbleed を発見している。シャルティエはこの偶然について次のように説明している。「グーグルは世界的なリーディングカンパニーで、つねに脆弱性を探し試験を繰り返しています」。グーグルはセキュリティーテストを重要視することで知られており、Chrome 等のプロジェクトではバグ発見に懸賞金をかけているほどだ。同社はこうした姿勢によって、ハッカーよりも先にバグを発見し、修復することに成功している。
しかし全ての IT 企業がこれほどセキュリティーに対して積極的というわけではない。
今回の失敗から学ぶ
Codenomicon 社はフィンランドの会社であり、Heartbleed を発見した際には CERT(フィンランドの国家サイバー・セキュリティー部門)に通報した。その後 CERT は OpenSSL プロジェクトに対し、アップデート版をリリースするよう要請した。これはメヒタが 4 月 1 日に同じバグを OpenSSL に報告した数日後の出来事であった。
最初の通報後、このニュースはすぐには報道されなかった。OpenSSL は事が公になる前に、各ベンダーにバグをパッチするための「適正なプロセスに必要な時間」を与えたかったのである。当初の予定では、世間への発表は 4 月 9 日に行われるはずであった。しかし別の調査チームから同じエラーに関する 2 件目の通報があったことから、さらなるリスクが予測されたため、発表は4 月 7 日に前倒しされた。
Heartbleed のニュースは IT メディアのみならず、一般のメディアでも大きく取り上げられた。シャルティエは、Heartbleed に関する情報の拡散性に感心している。「この一週間で状況は大幅に改善されています。何しろすごい勢いで情報が知れ渡っていますから」と彼は言った。「インターネットはより安全でセキュアになろうとしています」。
残念なことに、この問題はウェブだけのものではない。他のネットワークに関しても、サーバーとクライアント・デバイス双方のアップデートが必要となる。これには携帯電話のようなガジェットやコンピューター、その他のコミュニケーション・デバイスも含まれる。さらには「モノのインターネット」のような、膨大で幅色いテクノロジーにも関連してくるのだ。
Heartbleed は OpenSSL に関連したバグだ。OpenSSL は広く一般に普及しているため、ネットワーク化されたあらゆるデバイスが影響を受けてしまう。例えばスマートホーム、都市型公共交通手段、緊急医療サービス、送電網やその他のライフラインといった、ネットワークにつながるあらゆる大型システムが対象となる。それらをすべて修復することは決して簡単ではない。
バグの影響を受けた各組織はまず、パッチされた OpenSSL へのアップデートを行い、さらに自分たちのサイトで使用している暗号化証明書を無効にして再発行しなければならない。しかし、これまでセキュリティやシステムのテストを行ってこなかったようなサイトは、最新のプロトコルを効率的に処理するようには設定できないかもしれない。「作られてから時間のたっているシステムもたくさんありますからね」とシャンティエは言う。「そういったシステムは最新のプロトコルに対応できないかもしれません」。
重要インフラへのセキュリティー・テストは必要不可欠だ。しかし残念ながら、まだまだ改善の必要がある。「ソフトウェアの動作確認のためにちょっとしたパフォーマンステストを行う企業は多いですが、セキュリティーのテストを徹底するところは少ないのです」とシャンティエは述べている。
シャンティエは、問題を抱えた古いバージョンの OpenSSL が完全に更新されるまでに 1、2 年はかかると想定している。それまでの間、危険は消えないのだ。
現時点で大手ウェブサイトの大半は OpenSSL をパッチし、Heartbleed バグに対応している。しかし規模の小さいサイトやビジネスが対応を行うにはまだ時間がかかるかもしれない。良識的なユーザーであれば、自分のデータが被害にあった可能性を考慮し、パッチを受けたあらゆるサービスやサイトでパスワードを変更するべきだろう。シャンティエは、一件ずつプロバイダーにあたって「OpenSSLを使っているか、パッチは行ったのか」を確認することを推奨している。
企業や団体に対しては、シャンティエはより強固なセキュリティー基準を設置するよう促している。「自社のビルド・サイクルにセキュリティー・テストを最初から入れ込むことです」と彼は述べている。これこそリスクを最低限に抑え、問題が起きても深い傷を負わずにすむ最善の方法なのだ。
トップ画像用素材提供:Marjan Krebelj(Flickr より)、Heartbleed.com
トップ画像コラージュ:Adriana Lee
ハート型の鍵の写真提供:Alonis(Flickr より)
David Chartier の肖像写真提供:Codenomicon
※本記事はReadWrite Japanからの転載です。転載元はこちら。