セキュリティウィーク34:パッチ未作成の3つの脆弱性

2015年9月10日

情報セキュリティ業界にとっては何とも恐ろしい1週間でした。バグやゼロデイなど、リサーチャーにとって興味津々の発表があった愉快な週を終えたと思ったら、今度は脆弱なソフトウェアに対する侵入という悩ましいニュースばかりで頭が痛くなりそうです。重要なトピックですが、どうにも退屈な内容になりがちです。いつも当社のニュースブログThreatpostから最新の情報セキュリティニュースのダイジェストが送られてくるのですが、今回は3つともパッチ関連の重要な記事なので、このダイジェストをさらに要約するのは本当に大変です。

security-week-34-featured

まあ、とにかく、これは大事な話です!脆弱性はそう簡単に見つかりませんが、もっと難しいのは被害が出る前にパッチを作成すること。ある重大なバグのパッチがなぜ今すぐ、または今四半期中に、何なら永遠に作成されないのか、その理由はいくらでも見つかります。それでも問題は解決しなければなりません。

今回の「セキュリティウィーク」では、お粗末にもまだパッチが当たっていないバグを3つ紹介します。さて、このシリーズがどんな連載なのか、もう一度説明しておきましょう。毎週、Threatpostチームが重要なニュースを3つ選び、私が歯に衣着せぬコメントを加えます。前回までの記事はこちらでご覧ください。

Androidにまたバグ、今度はGoogle Admin

Threatpostの記事。MWRのリサーチ

何が見つかったのか?

このところ、バグからのラブレターが続々と届いていることにお気づきでしょうか。自動車がハッキングされたって?いや、車のセキュリティホールはまだまだ他にも!このパターンは、Android関連の最新ニュースでもありました。まずStagefrightの件があり、その後ももう少し小さなバグがいくつか発見されましたが、今回明らかになったのはGoogle Adminと『ショーシャンクの空に』サンドボックスからの脱出です。

security-week-34-kid

Google AdminはAndroidのシステムレベルのアプリで、他のアプリからURLを受け取ることがありますが、URL形式を問わないことがわかりました。「file://」で始まるURLさえ受け入れてしまうのです。その結果、Webページをダウンロードしただけで、Google Admin管理下のファイルが他のアプリから丸見えになってしまいます。Androidアプリはどれも互いに隔離されていたはずでは?いやいや。Google Adminは他よりも強い権限を持っているので、不正なURLを読み込ませれば、アプリがサンドボックスから抜け出し、個人情報にアクセスできるようになるのです。

どうやってパッチを作成したのか?

先に、この脆弱性が独立系調査機関から公表されるまでの経過を説明させてください。発見されたのはかなり前で、3月。そのときにGoogleへ報告がなされました。5か月後、発見者のリサーチャーがもう一度状況を確認したところ、バグは未修正のまま。8月13日、このバグの情報が一般公開され、Googleはようやくパッチをリリースすることになりました。

ちなみに、Googleは社内リサーチチームを設けていて、自社製ソフトウェアに限らずあらゆるソフトウェアのバグの発見に時間と労力を費やしています。GoogleのProject Zeroは通常、バグの公表までに90日の猶予期間を持たせています。そこで気になるのが、そもそもGoogleは自社ソフトウェアのパッチを90日以内に作成できるのか、ということです。

Google Adminに関しては、何かがとんでもなくおかしなことになりました。第1に、何かが、確かに、間違いなく悪い方向に進みました。第2に、誰もが知っているように、脆弱なAndroidデバイスの問題をパッチで解決できるとは限りません。月例セキュリティアップデートで何とかなる?では、半年かけてパッチ1つを作るのは?はいはい、いいんじゃないですかね。

security-week-34-kitten

Schneider ElectricのSCADAに未対応の脆弱性

Threatpostの記事ICS-CERTのアドバイザリ

ようこそ、魅惑の重要インフラの世界へ!どうぞ、お座りになっておくつろぎください。そこの恐ろしげな赤いスイッチや、怪しげに突き出ているワイヤには、お手を触れないように。そう、突き出ているのはわざとです。それでいいじゃないですか。何十年もこんな感じです。触ったら大変なことになりますよ。

SCADAシステムは重要インフラの一部で、マンションのボイラーから原発まで、大事なものを処理しています。こういうシステムでは、改ざん、電源オフ、リセットが想定されていません。パラメーターをふざけていじらないでください。というか、一切手を触れないで!

気になることがあっても、自分で試してみるわけにはいきません。このトピックに関する当社の記事を読むのがいいでしょう。ところで、素直に認めるしかないのですが、このようなシステムはとんでもなく重要だというのに、かなりの確率で古き良きWindowsが稼働する一般的なPC上に展開されているのです。普通の企業なら、少なくとも5年に1回くらいはハードウェアとソフトウェアのアップデートか交換を行うでしょう。ところが、一部の産業用ロボットや、大変危険な化学物質の遠心分離機は、同じハードウェア上で24時間365日、何十年にもわたって稼働することもあります。

何が見つかったのか?

SCADAシステムの一種、Schneider ElectricのModicon M340(なんてロマンチックな!)PLC Station P34 CPUに、バグが山ほど見つかりました。一連の脆弱性について簡単に説明すると、このシステムで管理されるほぼすべてのものが、外部の人間にコントロールされてしまう可能性があります。今回発見されたのは非常によくある欠陥で、私たちが言うところの「ハードコードされた認証情報」というやつです(ちなみに、多くのルーターやIoTデバイスでもよく見つかっています)。

産業用SCADAシステムで何がハードコードされていたのかは、(当然の理由で)秘密にされていますが、ここで大胆な仮説を立ててみました。保守が楽なように、既定のログイン情報がハードコードされていたのでは?または、単純にテストパスワードがコードから削除されていなかったのかも?言い訳は他にいくらでも考えられます。

どうやってパッチを作成したのか?

されていません。リサーチャーのアディティヤ・スード(Aditya Sood)氏がDEF CONでこの脆弱性を発表してから丸2週間が過ぎましたが、パッチがリリースされる気配は一向にありません。無理もないでしょう。ベンダーが対応を迫られている作業は、一筋縄ではいきません。脆弱なソフトウェアへのパッチ適用は、ただでさえ大変な作業だというのに、ダウンタイムによって顧客に莫大な損害が発生するとなれば、さらに困難を極めます。場合によっては、そもそも停止すること自体不可能です。

では、パッチの適用にどれくらい時間がかかるのでしょうか?運転を停止する期間は?パッチを適すれば正常に稼働するのか?エンドポイントデバイスの特性は漏れなく考慮されているのか?どれも厄介な問題ではありますが、バグにパッチを当てないための言い訳にはなりません。重要インフラに関しては、インターネットから切断しようとファイアウォールで保護しようと問題は解決されないことが、何度も証明されています。

security-week-34-keynote

情報開示の場に臨む開発者

Mac OS Xの未修正のバグ

Threatpostの記事

こちらも責任ある開示がテーマです。Googleのバグを発見したリサーチャーは、公表まで5か月待ちました。Google自身は猶予期間を90日としていますが。では、どれくらい待つのが妥当なのでしょうか?涙が出そうなセキュリティホールを開発元が塞ぐまでに、どれくらいの時間をみておけばいいのでしょう?

十分な時間を与えれば、開発元の危機感が弱まり、パッチの作成がいつまでも先延ばしされるのでは?脆弱性をすぐに公表すれば、開発者は急いでパッチを作成する気になるのか?何にせよ、標準的なリードタイムというものはありませんが、開発元に事前に知らせずバグを公表するのが良くないということは、誰もが同意するところです。

何が見つかったのか?

開発元に前もって連絡したかどうか、したとしても猶予期間が短すぎて対応する時間がなかったのではないか、というケースの好例を紹介しましょう。18歳のリサーチャー、ルカ・トデスコ(Luca Todesco)氏は、Mac OS X YosemiteとMavericks(10.9.5 — 10.10.5)の深刻なバグを発見し、その詳細を公表しました。無防備なマシンのルート権限を掌握されてしまうという脆弱性です。

このバグをリモートで悪用することはできません。エクスプロイトをダウンロードするように仕向けて、実行させる必要がありますが、犯罪者にとって難しいことではないでしょう。概念実証プログラムが公開されているので、それを手に入れて使えばいいのです。

どうやってパッチを作成したのか?

まだです。トデスコ氏によれば、懸命に何度もAppleに問い合わせたにもかかわらず、反応はなかったとのこと。同氏はこのような脆弱性を公表するのをためらいませんでした。本人が言うには、ジェイルブレイクの新しい方法を研究しただけ、以上。大したことではない。

何ともお粗末な話です。ジェイルブレイクは、自分のしていることがわかっている利用者が自らの意思ですることであって、望みもしない利用者のiPhoneをジェイルブレイクさせることはできません。トデスコ氏のバグの件に話を戻すと、これはよくある展開とは言い難い。同氏が他のリサーチャーから厳しい批判にさらされたのも当然です。

この新たに発見されたバグが、新しいMac OS X El Capitanに影響するかどうかは、まだわかりません。パッチのリリースを心待ちにしています。

その他のニュース

MicrosoftがInternet Explorerのバグを修正しました(パッチを作成している企業も、一応あるようですね)。定例外の緊急パッチがリリースされたのは、8月に入って2度目です。

個人情報をハッカーに盗まれた既婚者向け出会い系サイト、Ashley Madison。不正アクセスの犯行声明を出したグループが、通告どおり個人情報をオンラインに公開しました。

Kaspersky Labは、大規模なサイバースパイ活動Blue Termite(ブルーターマイト)を発見しました。すでに日本で大きな被害が出ています。2年以上にわたり活動していたサイバースパイが、この夏に突然活動を活発化させたとあっては、見つからないはずがありません。ブルーターマイトの活動が顕著になったのは、Flashエクスプロイトを手に入れてからでした。このエクスプロイトは、Hacking Teamから盗まれたダンプデータの一部として流出したものです。

懐かしのあれこれ

「Justice」

infosec-digest-32-book

非常に危険なマルウェアで、DOS 43h、4Bh、3Dh、56h関数で呼び出されたときに.COMファイルに影響します。ファイルの末尾に書き込まれ、先頭の5バイトを変更します(NOP; NOP; JMP Loc_Virus)。COMMAND.COMへの不正アクセスのプロセスには、Lehighウイルスと同じ手法が使われます。ドライブに書き込まれるデータを定期的に盗み取り、別のセクターに書き込みます。「AND JUSTICE FOR ALL」というテキストが含まれています。int 13hとint 21hを乗っ取ります。

1992年、ユージン・カスペルスキー著『Computer viruses in MS-DOS』(MS-DOSのコンピュータウイルス)72ページより引用。

注意:この記事は著者の個人的見解を反映したものです。これはKaspersky Labの見解と一致していることも、一致していないこともあります。運次第です。