筆者近況…いちおう日本にいます
近況について「ショッカーを追ってヨーロッパに行ってるんですか?」と、最近よく尋ねられる筆者である。が、実のところ子育てが予想以上に楽しいのである。編集担当Gさん、遅筆ですいません。加えて『The Shellcoder's Handbook: Discovering and Exploiting Security Holes, 2nd Edition』の邦訳版刊行を企図していたところ、技術評論社さんのもとで具現化できそうな状況にたどり着いたのであった。同書は情報セキュリティ界の第一人者である鵜飼さんが、その第1版を「稀に見る良書」であり「"ドリームチーム"によって執筆された」と評している。したがって邦訳については国内情報セキュリティ界の「オールジャパン」体制なのだと思われる。乞御期待。
Atsivのリソースセクションに含まれている2つのドライバ
閑話休題。次回の続きから。Atsivのバイナリには2つのリソースセクションが含まれている。それぞれ
- DRIVER_BIN32
- DRIVER_BIN64
である。これらは実際にVeriSignによって署名済みのカーネルドライバである。したがって、Vista x64で許容されるカーネルモードドライバとなる。しかし、これらドライバは独自のPortable Executable(PE)ローダを実装することで、さらに未署名のドライバをロードする。したがって、Atsivを使用することで最終的に未署名のドライバをカーネルモードで動作させることが可能となる。
|
|
Atsivのリソースセクションに含まれている2つのドライバ |
正規の手段でデジタル証明書を取得し、それを「一般に受け入れ難い行為につながりうるソフトウェア」のコード署名に使用することに関しては、10年前に似た事例がある。
1996年のことである。Fred McLain氏は「Exploder」と呼ばれるActiveXコントロールにVeriSignから購入したデジタル証明書を使用してコード署名を行い、それを自らのWebページで配布した。このActiveXコントロールはWindows 95が動作するPCをシャットダウンさせ、(自動電源切断機能がある場合は)電源も切るというものであった。同氏は、ExploderはActiveXコントロールが技術として危険なものに転用可能であることをデモンストレーションするために開発したと述べている。
コード署名はプログラムの出所が確かであり、その配布経路において改ざんがなされてないことを証明するための重要な手段であることには変わりない。また、悪意ある署名済みコードを作成した開発元を特定することができれば、その証明を取り消すことは可能である。事実、Atsivのコード署名に使用された証明書は破棄されており、Exploderについても同じ措置がとられている。ただし、当時Internet Explorer 3.0には証明書の有効性を確認する機能がなかったため、3.0.1がリリースされたという経緯もある。
SymantecのBlogにおける本件に関する投稿を見ると、Atsivは未署名のドライバをロードする際に、ロード済みのドライバの一覧を保持している双方向リンクリスト「PsLoadedModuleList」にエントリを追加しない。このため、一般的なドライバ一覧表示ソフトなどで未署名のドライバを表示することはできない。同エントリではこの「不可視」なドライバがロードされる点を指して「Rootkit的な動作である」とAtsivを指摘しており、また同社製のウイルス対策ソフトで検出するようパターンを配布している。また、Microsoftも証明書の破棄と同時にWindows Defenderのパターンを更新してAtsivの検知/削除を可能とした。
先に見た歴史的な「繰り返し」も含むのであろうが、このコード署名要件にかかる一連の動きは公開鍵インフラストラクチャにかかる問題の一類型と考えるのが相当であろう。Symantecの別のBlogエントリによれば、Symbian 9に感染するマルウェアにコード署名がなされていたという。このような別の事例から考えても、公開鍵インフラストラクチャにかかる問題、特に署名者の信頼性についてとその対処は、引き続き事例としての積み上げが増えていくと考えてよいのかもしれない。
