ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.27
  6. 1.インフラストラクチャセキュリティ

Internet Infrastructure Review(IIR)Vol.27
2015年5月27日
RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策に繋げています。ここでは、これまでに実施した調査のうち、悪質化するPUA、ID管理技術、HDDのファームウェアを再プログラミングするマルウェアのIOCの検討の3つのテーマについて紹介します。

1.4.1 悪質化するPUA

PUAはPotentially Unwanted Applicationの略で、ユーザにとってそもそも不必要であったり、全体としては有益であっても一部不適切な機能を有するソフトウェア群の総称です。PUP(Potentially Unwanted Program)とも呼ばれています。ソフトウェアの利用中に広告を強制挿入するアドウェアもPUAの一種として扱われる場合もあります。PUAには、一見正当な機能を提供するだけで無害に見えるものも存在しますが、一部には利用者が気付かないうちに広告などに活用するために行動情報を取得、外部に送信する悪質なものも存在します。また近年、一部にはユーザを騙してPUAをインストールさせ、それを使って情報を盗み出したり、更に追加でPUAを次々とインストールさせたり、Webコンテンツの改ざんやUACを回避して特権昇格するなど、マルウェアと同様の手法を使う悪質なものが増加しています。本稿では、IIJが最近解析した複数のPUAの解析結果から、それらが用いていた手法について解説します。

PUAの定義

PUAの厳密な定義は専門家の間でも分かれます。直訳からも分かるとおり、悪性であるかどうかに関わらずユーザにとって不必要な機能を持つプログラムはすべてPUAとなり得るからです。ユーザにとってどのプログラムが不要であるかは個々の考え方や立場、状況、環境などによって異なります。そこで、ここではユーザがインストールを望んだソフトウェアとは関係がないにも関わらず、追加でインストールされてしまう不要なプログラムをすべてPUAと定義し、その中でもマルウェアと同様の手法を使うものを悪質なPUAと呼ぶことにします。

悪質なPUAの例

侵入経路

図-13 ダウンロードサイトに混入した偽ダウンロードボタン(広告)の例

攻撃者はあらかじめWeb検索エンジンの検索結果をSEO Poisoning(※44)などの手法を使って操作し、ユーザを偽サイトに誘導する手口が多く見られます。例えば、あるソフトウェアをダウンロードしようと検索を行う際、検索キーワードにソフトウェアの名称と共にバージョンや"ダウンロード"などといったキーワードを指定して検索すると、オリジナルの配布サイトよりも上位に偽サイトが表示されてしまうケースが確認されています。また、検索結果と一緒に表示される広告にも偽の配布サイトが混入していることがあります。誘導先の偽サイトは、著名なダウンロードサイトにドメイン名やデザインを似せて作られている場合もあり、偽サイトであると容易には判別できないようになっています。また、いくつかの著名なダウンロードサイトのWebページ内に存在する広告にも、悪質なPUAをダウンロードさせるための偽のダウンロードボタンが混入していました。図-13はダウンロードサイトのデザインの一例です。複数の広告による偽のダウンロードボタンが混入しており、普段からこのWebサイトを使い慣れているユーザ以外、どれが本当のダウンロードボタンであるか気付くことが困難になっていました。更に、著名なダウンロードサイトのいくつかでは、そのサイト専用のダウンロードツールを利用しており、そのツール経由でユーザがインストールを望むソフトウェアをダウンロードさせます。しかし、一部にはそのツールにPUAが同梱されているケースが存在します。それ以外にも、ダウンロードサイトがソフトウェア作者に個別に同意を取った上でPUAを同梱したインストーラを提供している場合も存在します。

PUA導入のフレームワーク

ダウンロードさせられたPUAは単一のアドウェアである場合もありますが、一部のケースではダウンローダ型のプログラムになっており、更に複数のPUAをインストールするものが存在しました。ある事例では、追加でダウンロードされるPUAは多岐にわたり、数や種類は時々刻々と変化していたことから、PUAフレームワークの構築者が、依頼元からの要望に応じて利用者のシステムにPUAをインストールして金銭を得るPay-per-install(※45)が行われていると考えられます。

ダウンローダ型のPUAはインストールされると定期的にC&Cサーバと通信をし、自己アップデートや新たなPUAをダウンロードします。また多くの場合、PUAはユーザが本来インストールしようとしていたソフトウェアもインストールするため、ユーザが騙されていることに気付きにくくなっています。

インストーラ形式のPUAの場合、利用者に分かりにくいデザインを悪用して、インストール時にPUAのインストールに関するユーザ同意を取り付けている事例も見受けられます。図-14はあるアドウェアのインストーラデザインの一例です。ユーザがインストールを望んでいるソフトウェアのインストーラに見せかけていますが、利用規約の文章はそれとは別のアドウェアに関するものであり、「CONTINUE」をユーザがクリックすると、裏ではそのアドウェアがインストールされます。ユーザは注意深く見てインストールしない限り、アドウェアのインストールに同意したとみなされてしまいます。

一部のPUAは自分自身のインストールに対する同意を取らずにインストールしていました。このようなPUAを実行してしまった場合では、利用者が提示されるソフトウェアの導入を拒否したとしても、本体はPC上に存在しつづけ、新たなPUAのダウンロードや、自身をアップデートしようとする試みが継続して行われます。また、追加ダウンロードされるPUAも、その一部はユーザに同意を取らずにインストールされていました。

Webコンテンツの改ざん

図-14 PUAのインストーラのデザイン例

PUAの一部にはWebブラウザのプラグインやWebブラウザ拡張として動作、もしくはWebブラウザにPUA自身のコードをインジェクションして送受信用のAPIをフックし、乗っ取ることによってユーザがアクセスしたURLをすべて盗みだし、それに基づいた広告を閲覧中のWebコンテンツ内に挿入して改ざんする手法が採られているものがありました。挿入されるコンテンツの内容は異なるものの、これはZeuS、SpyEyeやvawtrak(※46)のようなBanking TrojanによるWebInject(※47)と同様の手法です。このようなタイプの攻撃手法を使うものをWebブラウザハイジャッカーとも呼びます。

この手法以外として、自己署名されたルート証明書をインストールしておき、PUA自身はHTTP(S)のローカルプロキシとして動作してWebブラウザからの通信をすべて自分宛てにねじ曲げ、Webサーバからの証明書を横取りして改ざんし、自身がインストールしたルート証明書で署名を行う手法があります。これにより、MITM(※48)を行って通信を傍受することで、コンテンツに広告などを挿入して改ざんするタイプも発見されています。

どちらの手法とも暗号化されたHTTP通信のコンテンツであってもユーザに気付かれることなく改ざんすることが可能であり、非常に危険な手法です。また、Webブラウザのツールバーとして動作し、アドウェア業者によって提供される検索エンジンを使用することを強制したり、検索キーワードを盗み出すものも存在します。

Windowsの仕様を悪用

例えばPlugX(※49)やDridex(※50)などのマルウェアはそれぞれ異なる手法を用いてUAC(※51)のポップアップを回避し、自動的に管理者権限を奪取する機能を備えています。今回解析したいくつかのPUAにも、このような特権昇格を行う機能(多くはDridexと同様の方式で特権昇格する)が含まれていました。PUAが管理者権限を奪取するのは、後に複数のPUAを追加ダウンロードした際、ユーザに気付かれずにシステムフォルダにインストールするために必要だからです。

難読化

いくつかのPUAは、追加でダウンロードされるPUAが独自の形式で圧縮、もしくは難読化されており、通信路上では実行ファイル形式になっていないため、IDSやIPSなどで検出しにくくなっていました。また、PUA自体にもコードの難読化や重要な文字列の難読化が施されており、特徴として検出することや解析することが困難になっていました。

Sandbox対策

いくつかのPUAはインストールされた際、スタートアップに登録するだけで終了してしまい、次回PCを再起動するまで実行されないようになっていました。これは動的解析を行って短時間で判定を行うSandbox製品の検出を回避するための行為として、一部のマルウェアが使用していた手法と同様です。インストール直後に手動で実行したりPCの再起動を試みた場合でも、C&Cサーバへの通信は発生するものの、すぐには新たなPUAがサーバからダウンロードされないようになっており、数日から長い場合で数ヵ月経ってから新たなPUAがダウンロードされるようになっていました。これもSandboxによる検出を回避するための手法の1つだと考えられます。

VM検知

多くのマルウェアにも仮想環境やSandboxでの実行を妨害する機能がついていますが、今回解析したPUAにもこのような機能が含まれていました。特に、執筆者がこれまでマルウェア解析を行った際には見ることのなかったHyper-VやXen、KVMなどの仮想環境も検知されるようになっていました。これは、WMI、WBEM(※52)の機能を使い、BIOSの情報などを取得することで判定を行っています。それ以外の手法も組み合わせ、現存するほぼすべての仮想環境を検知できるようになっており、検出すると実行を停止するなど、その挙動を変更するような仕組みが入っています。これも解析妨害の1つです。

組織がPUAに感染することのリスク

今回紹介したWebブラウザハイジャッカー型のPUAは、ユーザがアクセスしたWebサイトのURLなどをすべて外部に送信します。組織内でこのようなPUAに感染した場合、イントラネットのサーバ名やURLのパス情報、GETパラメータなどが一緒に漏えいします。これは企業などの組織の内部情報を守る観点では好ましくありません。

更に、PUAフレームワークによって追加でインストールされるプログラムにマルウェアが混入する可能性も考えられます。加えて、近年、広告サイト自体が改ざん(※53)され、ドライブバイダウンロード(※54)によってマルウェアがインストールされるケースもあります。アドウェアが表示した広告を閲覧した際に、悪意のあるWebサイトに誘導されて感染するような可能性がないとも言い切れません。このような事態にならないよう、PUAと言えど組織やユーザにとって不必要なソフトウェアがインストールされないように監視を行い、感染を発見した場合は速やかに対処できるような体制を構築しておくべきでしょう。

対策

悪質なPUAに感染しないようにするためには、まずユーザ自身が利用するソフトウェアの公式サイトを普段から把握しておくことでしょう。常に公式サイト、もしくはそこからたどることの可能な正規のミラーサイトのみを利用することで、偽のWebサイトから悪質なPUAをダウンロードすることを防ぐことができます。ダウンロードボタンに模した悪質な広告をクリックしてダウンロードをさせられてしまう可能性もあるため、公式サイトに記載されているハッシュ値と照合することなども、このような手法に騙されることを防ぐ手段の1つとなります(※55)。また、安易に無名な、もしくは出所の分からないソフトウェアをインストールしないように日頃から気をつけるべきです。もしあなたが管理者であれば、ユーザが勝手に任意のソフトウェアをインストールできないように一般ユーザ権限のみを与えることを検討するとよいでしょう。また、ユーザディレクトリ内にインストールするタイプのソフトウェアも存在するため、ソフトウェアの制限ポリシーやAppLockerなどのWindowsの機能を使って、システムディレクトリ内とプログラム置き場以外からのプログラムの実行を禁止することで、勝手にユーザがソフトウェアをダウンロードして使用することを防ぐことができます。

有名なソフトウェアの一部やプレインストールされているソフトウェアであってもインストール、もしくはアップデートの際にPUAをインストールさせようとするものも存在します。説明を読まず、安易に「次へ」ボタンをクリックしないようにしましょう。

また、PCにプリインストールされているソフトウェアにアドウェアが含まれているという事件も発生していることから、PCを調達する際にも注意が必要です。いくつかのメーカーはプリインストールされているソフトウェアの一覧が明示されているため、PCを選択する際の参考になります。また、一部メーカーの法人向けPCではプリインストールされるソフトウェアを出荷時に外せるようにカスタマイズできるものもあります。このようなPCの調達を検討するのも1つの手段になります。

それ以外にも脆弱性を突かれて強制インストールされる可能性もあることから、マルウェアへの対策と同等のことを行っておくことも必要です(※56)。今回紹介したように、UACを回避しようとWindowsの仕様を悪用する悪質なPUAも存在します。そのため、管理者アカウントでPCを管理している方はUACを最高レベルに引き上げておくことも検討してください。

1.4.2 ID管理技術~利便性と安全性の観点から~

本稿では前号に引き続き、ID管理(Identity Management)技術について取り上げます。IDを識別子(Identifier)という狭義の意味と捉え、秘密情報であるトークンと公開情報であるクレデンシャルの関係、認証と認可の違い、トークンを用いた認証から各種クレデンシャルの流通、アクセス権限付与までの一連の流れについて解説を行いました。今回はこれらの技術が実際にどのように利用されているかについて、具体的事例を含めて報告します。

IDとトークンのバリエーション

前号の報告では、IDを持つエンティティが認証されることで、当該IDに属性情報や認可情報が紐付きされ、IDと紐付けされた情報であるクレデンシャルが発行されるという一連の流れを説明しました。このとき認証時には、そのIDを持つエンティティの確からしさを保証するためにトークンが用いられます。認証はレルム(認証や認可が有効な領域)ごとに行われるため、レルムごとにIDとトークンの組を持つことが一般的です。ここで、IDやトークンとして実際に使われている事例を紹介していきます。

認証に関する業務を行うIdP(Identity Provider)がレルムごとに存在し、ユニークなIDがレルムごとに割り振られます。これはインターネット上のサービスを最初に利用する際に、必要事項を入力する利用登録画面を考えると理解できます。登録時には「ユーザID」などの項目でIDを入力する欄があることに加え、他のユーザとIDが被っていないかチェックを行っています。一方でサービス側がランダムにIDを割り振るケースも存在します。いずれの場合も、利用登録時にはメールアドレスや電話番号などのパーソナルデータも入力することが一般的です。これは、この段階では仮登録に過ぎず、入力されたメールアドレスにメールを、もしくは電話番号にショートメッセージを「チャレンジ」と共に通知し、ユーザに当該チャレンジを入力させることで本人確認を行うためです。仮登録時もしくはチャレンジ入力時には、トークンの一種であるパスワードを入力することが一般的です。このようにしてIDとパスワードの組が登録完了した時点でサービスが利用可能になります。

IDをレルム独自に割り振るのではなくメールアドレスで代用するケースも見られるようになりました。レルム独自にIDを管理するためのコストを削減できるため、またユーザが決めたIDや特にIdPが割り振ったランダムなIDを忘れてしまう事態が発生しなくて済むというメリットがあるためです。レルム独自IDを割り振る場合は、本人確認に利用したメールアドレスや電話番号を再度入力させてIDリマインダやパスワードリセットなどを行うWebページを運用する必要が生じ、サービス側の負担が増えることになります。一方でIDとしてメールアドレスを利用した場合には、リスト型攻撃の対象になりうることに留意する必要があります。これはレルムごとに同じIDを使い回している場合にも同じリスクがあると言えます。もちろんパスワードの使い回しをしないことが根本的な対策になりますが、同じIDで漏えいデータの紐付け・名寄せをされてしまうというリスクも存在します(※57)。また、メールアドレスをIDに利用したためにSNSやショッピングサイトにおいてIDを入力させるリマインダページに知人などのメールアドレスを入力することで、プライベートな情報が漏えいしてしまう事例が過去にありました。これらの状況を受けて、レルム独自IDの発行も行うが、メールアドレスもログイン時のIDとしても利用できるかどうか、ユーザに選択権を与えるといったシステムも見受けられるようになりました。

このようにIDはこれまで公開情報と考えられていましたが、秘匿しておくべき状況もありうると認識される事例も存在します。この問題に対する対策として、基本IDと派生IDという考え方について紹介します。各種ポータルサイトやSNSなどをIdPとして利用する場合には、同じIDとトークンの組で多種多用なサービスを利用するケースが存在します。このとき、サービスに応じて立場を変えたい、同じエンティティによる発言や操作であることを知られたくないというシチュエーションが出てきました。そこではじめに割り振られたIDを基本IDとして、実際にIDを利用する場面ではそれぞれのシチュエーションに応じて異なるIDを派生させるというアイデアが登場しています。これは、前述したようにIDが漏えいすること自体が脅威であるという状況を防ぐ単純な解法にあたります。派生IDによるログインを行う場合、基本IDに紐付けされたトークンを利用しますので、派生IDごとに別々のトークンを管理する煩雑さはなくなります。また、再ログイン時にトークンの再入力は必要なく、派生IDの切り替えのみでサービスに応じて異なる派生IDで立ち振る舞いを行うことができるようになります。注意すべき点は、どの派生IDでログインしているかを確認し忘れて、第三者から見て異なるユーザによる2つのアクティビティが紐付けされるケースが発生する可能性があることです。例えばログイン時に表示されているニックネームなどの情報に留意する必要があるでしょう。

IDを派生させるアイデアと同様に派生トークンという概念を考えることもできます。基本トークンとは別に、派生トークンを基本IDと結びつけることで、基本IDと派生トークンの組を認証に用いる手法になります。この派生トークンを1回使いきりのトークンと考えると、ワンタイムパスワードの亜種と考えることもできます。実際の用途としては、例えばスマートフォンのアプリケーションごとに派生トークンを保存(実際にはトークンそのものではなく、マスターパスワードなどを使って暗号化して格納しているケースも考えられます)させておくケースが考えられます。これはスマートフォンなどのパスワード入力が煩雑な環境においては有用な機能と考えられます。また、もし仮に特定のアプリケーションからのパスワード漏えいが発覚した場合でも、被害を限定させると共に、基本パスワードの変更ではなく派生パスワードの無効化のみで済むというメリットもあります。この観点では、権限委譲を行っていると考えることもでき、派生トークンを使った場合の認可範囲を、基本トークンの認可範囲よりも限定しておくことで、トークン漏えい時の影響を最小限に抑えることができます。

このように、ユーザの利便性(ID忘却)と安全性(ID使い回しやトークン漏えい)とのバランスを考慮した運用が望まれています。更に、この派生ID・派生トークンの概念を拡張させることで、図-15のように、基本IDと基本トークンの両方を使わない認証・認可の仕組みも可能となります。このような方式を利用している実際のシステムは現在見受けられませんが、プライバシー保護に留意しているユーザの将来的なニーズに応じて、こうした新しい使い方が今後実装されるかもしれません。

ワンタイムパスワードのバリエーション

図-15 派生トークンと派生IDの考え方

ここまでIDとトークンの使い方に関するバリエーションを紹介してきました。次にトークンの一種であり、1回ごとに使い捨てるワンタイムパスワードについて解説します。ワンタイムパスワードはこれまで主にインターネットバンキングシステムにおいて利用されており、安全な認証方式と認識されてきました。しかし2015年2月、警視庁により2014年のインターネットバンキングにおいて不正送金の事例が公開され(※58)、被害金融機関数は100を超えるなど被害額も増加傾向にあることが分かりました。特に、送金額が比較的大きな法人口座における攻撃が注目されており、注意喚起がなされています(※59)。法人向けインターネットバンキングの認証において、パスワード単独で利用する方式に加え、X.509証明書によるクライアント認証(Strong Authentication)を使う方式も導入されており、より強固な手段として知られていました。しかし、この電子証明書を利用する場合でもマルウェアに感染したPC・ブラウザなどから自動的に振込が行われるケースが露呈しました(※60)。このようにSSL/TLSクライアント証明書を用いた認証方式でも対策が不十分な状況になっています。

このような背景のもと、インターネットバンキングシステムにおいて認証方式の強化が進められています。従来、用紙やカードに記載された乱数表やワンタイムパスワードを表示するハードウェアデバイスが利用されてきました。後者は、ATMなどでも認証に用いられるパスワードに該当する第一暗証番号(数字4桁の番号)と併用して一時的なパスワードも同時に入力することで認証する方式です。第一暗証番号が漏えいしていたとしても、1回ごとに使い捨てるワンタイムパスワードを利用することで、住所変更や多額の送金など特に重要な処理に関して本人確認を強化することができます。

しかし、Man-in-the-Browser攻撃(※61)や中間者攻撃に代表されるように、バンキングシステムにおけるトランザクションのうち、例えば送信先口座番号や送金額の書き換えが行われてしまうと、使い捨てのワンタイムパスワードを利用していたとしても、不正送金が可能となってしまいます。これは認証方式を強化したとしても、ブラウザなどで表示されている情報だけでは、正しいトランザクションかどうかをユーザ自身が明示的に確認することができず、攻撃者によって実際にはトランザクションを書き換えられている可能性を否定できない問題を示しています。この問題に対して、入力デバイスを備えたハードウェアデバイス利用の移行が進められています。

これまでも複数のバンキングシステムにおいて、認証時にハードウェアデバイスを併用する対策が採られていました。しかし、このハードウェアデバイスは入力インタフェースがなく単なるワンタイムパスワード生成器であったため、取引内容とは関係なく、正しいトークンを保持しているユーザかどうかのみを判定するためにしか利用できませんでした。また企業向けのバンキングシステムでは前述したX.509証明書の利用だけでなく、特定のIPアドレスや特定のPCからのトランザクションしか受け付けないなどの副次的な対策もなされていましたが、ユーザが目にするトランザクション自体を書き換えられている場合も考えられるため、根本的なMan-in-the-Browser攻撃対策を行うことはできません。つまり本人確認を強化しても無駄な対策になっていたわけです。

それに対して2015年に入り、金融機関によりワンタイムパスワードカード利用開始のアナウンスがありました。この新しいハードウェアデバイスは従来のデバイスと異なりテンキーなどの入力インタフェースを持つものであり、本人認証と共に書き換えられているかもしれないトランザクションの正しさも確認できる手法が採用されています。このデバイスは、従来のようにハードウェアデバイスからただ単に出力されるワンタイムパスワードのみを認証時に入力するのではありません。どの口座に入金しようとしているのかをユーザ自らが口座番号を入力することで、口座番号の正しさも保証するワンタイムパスワードをデバイスで生成・表示する機能を持ちます。これにより、攻撃者の意図する口座への入金を防ぐことができますが、他にもこのときはじかれたトランザクションのログを蓄積することで、攻撃者の持つ口座のブラックリストを自動的に形成することができるメリットがあります。また、ユーザ利便性を考慮して、入力デバイスを持たない単なるワンタイムパスワード生成器としても利用できます。これはユーザがあらかじめ登録している口座は安全であるという前提のもと、これらの登録済み口座に対する送金においては口座番号の入力を省くという手法です。

現状のこの対策に関して分析してみます。まず1点目は口座番号のみを入力しているため、入金額に関してのトランザクションの正当性を保証することはできません。大多数のユーザが登録している、例えば学校法人の授業料入金口座などの場合、ある特定の短期間にトランザクションの入金額を変更するなどの業務妨害になりかねない攻撃が考えられます。2点目は送金する銀行を指定していない点です。この場合、攻撃対象となる口座に対して、他の銀行の同じ口座番号が攻撃者の管理下にある場合、不正に送金されてしまうリスクがあります。いずれも、口座番号だけをユーザが明示的に確認しているという点が問題になります。トランザクションのうち、例えば入金額や銀行コードなどもユーザが明示的に確認するなど、対策を講じれば講じるほど、ユーザがデバイスに入力するデータが増えることになります。この点については、ユーザがどのくらいトランザクションを書き換えられる可能性を感じているかに応じて、様々な選択肢を与えることが1つの解決策になると考えられます。これはIDとしてメールアドレスを許可するかどうかの選択と同じような考え方に基づきます。この点においても、ユーザの利便性と安全性のバランスを取った運用が望まれています。

更に、FIDO AllianceによるSecond Factor UX(※62)を実装したブラウザも現れました。パスワード入力の代わりに、USBなどのインタフェースを介して小さなハードウェアデバイスを持っていることでパスワード入力を省いて本人認証を行うことができる規格であり、昨年より利用が拡大しています。しかし、実際に利用が広まると以下のような懸念も生まれます。USBフラッシュメモリの持ち運びを禁止する組織があるように、FIDO規格のUSBデバイスの利用が制限される可能性です。そこで、社員証のように居室に入室する際に必ず携帯し、かつ安全に管理することが求められているICカード型のデバイスを併用するなどの製品が今後登場する可能性もあるでしょう。現在、これらの本人認証方式の移行は過渡期にあります。今後、パスワードに代表されるような"Something you know"だけの単体利用ではなく"Something you have"もしくは"Something you are"にカテゴライズされるトークンとの併用が必須となる時期が近づいており、ユーザは重要な通信に対し、多少利便性を損なってでも、強固な本人認証方式を選択できる時代が始まりつつあります。

1.4.3 HDDのファームウェアを再プログラミングするマルウェアのIOCの検討

2015 年2 月16 日にKaspersky 社はEquation Group と呼ばれる攻撃グループに関する情報を公開しました(※63)。Equation Group は「EquationLaser」「EquationDrug」「DoubleFantasy」「TripleFantasy」「Fanny」「GrayFish」といった様々なマルウェアのセットを用いますが、中でもEquationDrugやGrayFishに組み込まれるプラグインの1つである、ハードディスクドライブ(HDD)のファームウェアを再プログラミングするモジュールを利用している点がユニークであると言えます。同社によると、このモジュールの機能により、ファイルシステムの再フォーマットやOSの再インストール後もマルウェアを持続可能にしたり、HDDの中に不可視なデータ領域を生成することができ、マルウェアの検出も削除も困難な状況になると述べています。IIJでは同モジュールの初期動作を解析(※64)して、メモリ上からその存在を検出するためのIndicator of Compromise(IOC)(※65)を検討しました。

初期動作の概要

HDDのファームウェアを再プログラミングするモジュール(以下、nls_933w.dll)は、Platform Orchestratorと呼ばれるDLL(mscfg32.dll)によってロードされます。ロード後、mscfg32.dllはnls_933w.dllがエクスポートする関数アドレスを複数呼び出し、文字列の難読化解除、mscfg32.dll側の関数アドレスのコピーなどの初期化処理後に、メインの処理を行う関数を実行します。

nls_933w.dllのメインの処理を行う関数では、まずリソースからドライバ(以下、win32m.sys)がロードされます。その後、DeviceIoControl APIを介してwin32m.sysを制御し、モジュールのバージョンの確認、IOリクエストハンドラのクリア・セットなどの初期化処理が行われ、問題がなければATAコマンドを発行するためのIOリクエストのキューイング処理に移ります。

同キューイング処理では、最初にHDDの情報を取得するためのコマンド(IDENTIFY DEVICE)をwin32m.sysに送信します。取得した情報の中から、シリアル番号、ファームウェアリビジョン、モデル番号などを中心にチェックした後、モデル番号に応じて更なるコマンド(INITIALIZE DEVICE PARAMETERS)を送信することもあります。その後、HDDの情報からファームウェアの再プログラミングが可能なターゲットであることが判明した場合、ファームウェアの更新に関するコマンド(DOWNLOAD MICROCODE)を送信します。

IOCの検討

図-16 nls_933w.dllによって用いられるIoControlCode

冒頭に述べたとおり、nls_933w.dllはHDD内からマルウェアの検出も削除も困難な状況を作り出します。しかし、隠されたデータ領域にアクセスするには同DLLのAPIを必要とすることから、少なくともメモリ上には同DLLが存在している必要があります。そこで、上記に述べた初期動作から、同DLL(とそれがロードするドライバ)をメモリイメージ内から検出するためのIOCを検討してみます。

最初にnls_933w.dllの検出に特化したIOCを検討します。DLLとドライバ双方で検出可能なIOCとしては、DeviceIoControlAPIで指定するIoControlCodeがあります。今回のマルウェアでは図-16のように6つのIoControlCodeが使われており、これらすべてをAND条件でIOCとして定義できます。

図-17 HDDの情報を取得するためのコマンド

(IDENTIFY DEVICE)のための構造体

また、nls_933w.dll内に存在する、ATAデバイスのレジスタの読み書きに用いる6バイトの構造体から成るバイナリシーケンスを定義することも、nls_933w.dllに特化した検出であれば有効です。この構造体は、レジスタオフセットや書き込むデータなどで構成され、例えばHDDの情報を取得するためのコマンド(IDENTIFY DEVICE)の場合、図-17のように2つの構造体(合計で12バイト)のバイナリシーケンスとしてメモリ上に存在しています。その他にもATAコマンドを含む構造体がモジュールに数多く含まれているので、それらをANDで組み合わせて定義します。一方ドライバの側にはこのような構造体は含まれていませんが、その構造体をパースするコードシーケンスを定義するのも1つの手でしょう。

次に、nls_933w.dllに限らず、同様の動作を行うマルウェアを検出するための汎用的なIOCを検討します。まず思い浮かぶのが、HDDのファームウェアを識別する過程で用いられる、「Maxtor STM」「WDC WD」などのモデル番号ですが、nls_933w.dllの場合それらは難読化されており、難読化解除後の文字列もスタックに積まれるため、事後に有効なメモリ空間内でそれらを見つけることは困難だと言えます。

図-18 利用するAPIに基づく検出

別の汎用的なIOCとして考えられるのは、ドライバ側で用いられるハードウェアポートもしくはレジスタデータ入出力のためのAPIです。例えば、先程説明したATAデバイスレジスタへの書き込みにはWRITE_PORT_UCHARというAPIが利用されます。これ以外にも読み書きのサイズに応じて同様のAPIをインポートしており、それらをANDで定義することで、nls_933w.dllのみならず同じような機能を持つドライバを検出できる可能性があります。ただし、このような汎用的な定義には誤検出が生じる可能性が大きくなります。32bitのWindows XPとWindows 7の複数のメモリイメージでこの定義での検出を検証したところ、Windows 7の場合、複数のドライバで誤検出が発生します(※66)。よって、前述のAPI群だけでなく、その他の処理に関係するAPI群も定義します。具体的には、図-18のようにIOリクエストのキューイングに関わる処理(スレッドの生成、DPCのキューイング)を追加で定義することで、誤検出を排除できます。

その他、追加で定義できる汎用的なIOCには、前述のキューイング処理に関連した、カーネルタイマ関数の有無があります。この定義だけでは誤検出の可能性が高いので、前述した利用されるAPI群とANDで定義することを推奨します。

まとめ

本稿では、HDDのファームウェアを再プログラミングしてデータを隠蔽するマルウェアに対しては、まったく打つ手がないわけではなく、メモリからの検出が有効であることを示しました。今回、このマルウェアに特化して検出するためのIOCと、同様の機能を持つマルウェアを検出するための汎用的なIOCについて検討しましたが(※67)、後者に関して誤検出の少ないものを作るには、十分な解析と検証に基づいた、マルウェアの機能に即した定義が必要になります。よって、対応の緊急度合いに応じて臨機応変にどちらの観点で作るか判断していくと良いと思われます。

  1. (※44)SEO(Search Engine Optimization)Poisoningとは、検索エンジンの最適化アルゴリズムを悪用して検索結果を意図的に操作し、自身の用意したページを本来の順番よりも上位に表示させる手法。本来はマーケティング用の手法だが、マルウェア感染などのように利用者に害を与える目的で悪用されることもある。
  2. (※45)クリック報酬型アフィリエイトはPay-per-accessとも呼ばれ、クリックさせた広告の量によって報酬が決定する。それと同様に、Pay-per-installはインストールさせたソフトウェアの量で支払われる報酬が決定する。依頼者側は、例えばアフィリエイトサイトに連続してアクセスさせることで金銭を稼ぐアドウェアの作者の場合、より多くのPCにインストールされればそれだけ金銭を稼ぎやすくなるので、このようなフレームワークを持つ組織に依頼を行う。受託側はより多くインストールさせれば、依頼者からより多くの金銭を得られるために、このようなフレームワークが構築されていると考えられる。近年ではマルウェアでもこのモデルが使われているとも言われている。
  3. (※46)ZeuSは、本レポートのVol.16(http://www.iij.ad.jp/dev/report/iir/016.htmlblank)の「1.4.3 ZeuSとその亜種について」、SpyEyeは、本レポートのVol.13(http://www.iij.ad.jp/dev/report/iir/013.htmlblank)の「1.4.2 SpyEye」、vawtrakは、本レポートのVol.24(http://www.iij.ad.jp/dev/report/iir/024/01_04.htmlblank)の「1.4.2 国内金融機関の認証情報などを窃取するマルウェア「vawtrak」」でそれぞれ詳しく解説している。また、同様にWebInjectの機能を持つZeuS亜種のCitadelも、本レポートのVol.18(http://www.iij.ad.jp/dev/report/iir/018.htmlblank)の「1.4.2 ZeuSの亜種Citadel」で詳しく解説している。
  4. (※47)Webinjectとは、Webブラウザの通信系APIをフックすることによってブラウザのメモリ上のWebコンテンツを改ざんする機能。ZeuSやSpyEyeなど、Banking Trojan系のマルウェアのほとんどはこのような機能を持ち、感染者が金融機関などにログインする際、二要素認証などの情報を追加で入力させて奪うことで、金銭を窃取しようと試みる。Webinjectは、本レポートのVol.18(http://www.iij.ad.jp/dev/report/iir/018.htmlblank)の「1.4.2 ZeuSの亜種Citadel」や、本レポートのVol.13(http://www.iij.ad.jp/dev/report/iir/013.htmlblank)の「1.4.2 SpyEye」で詳しく解説をしている。
  5. (※48)MITM(Man-In-The-Middle)攻撃とは、攻撃者が通信を行う両端の間に割り込んで通信を横取りし、暗号化の解読を行って利用者に気付かれることなく盗聴や改ざんを行う手法。中間者攻撃。
  6. (※49)PlugXについては、本レポートのVol.21(http://www.iij.ad.jp/dev/report/iir/021.htmlblank)の「1.4.1 標的型攻撃で利用されるRAT「PlugX」」及び、Black Hat Asia 2014での発表「I Know You Want Me - Unplugging PlugX」(https://www.blackhat.com/docs/asia-14/materials/Haruyama/Asia-14-Haruyama-I-Know-You-Want-Me-Unplugging-PlugX.pdf)で詳しく解説している。その中で、UACの回避による特権昇格についても解説している。
  7. (※50)Dridexが用いているUACの回避手法については、JPCERT/CC 分析センターだより「Dridexが用いる新たなUAC回避手法(2015-02-09)」(https://www.jpcert.or.jp/magazine/acreport-uac-bypass.htmlblank)で詳しく解説されている。
  8. (※51)Windows Vista以降にはUAC(User Account Control、ユーザアカウント制御)と呼ばれる機能がついており、管理者権限を持つアカウントでログインしていても、通常時は重要な権限が無効になっている。プログラムがシステムを変更するような重要な操作を行った場合にユーザに対して許可を求めるポップアップが表示され、許可された場合のみ、権限が付与される。UACには4段階の設定が存在するが、Windows 7以降、マイクロソフト社はユーザの要望により、4段階中、上から2番目のレベルを初期設定にしている(Vistaは最高レベルが初期設定)。このレベルではユーザが操作したものであるとWindowsが判断した場合はUACのポップアップを表示せず、自動昇格が行われる。近年では、マルウェアがこの仕様を悪用し、ユーザが操作したように見せかけた振る舞いをすることで、UACのポップアップを表示させずに管理者権限に自動昇格する攻撃手法が複数確認されている。
  9. (※52)WBEM(Web-Based Enterprise Management)は分散コンピューティングを管理するための技術仕様で、標準化を行う業界団体DMTF(Desktop Management Task Force)によって策定された。WMIはWindows Management Instrumentationの略で、WindowsをWBEMで管理するための実装。WMIによりローカル、もしくはリモートのWindows上の様々な情報(ハードウェア、ソフトウェア、OS、ユーザ、プロセスなどあらゆる情報)を取得したり、状態変更をすることができる。
  10. (※53)攻撃者が広告プラットフォームを改ざんし、そこにExploitを仕掛けて待ち伏せをする攻撃手法をMalvertisingという。MalvertisingはMaliciousとAdvertisingを掛け合わせた造語。広告プラットフォームは複数のWebサイトに対して広告を配信している場合が多く、改ざんさせた場合、Exploitを一斉配信させることが可能であり、攻撃者にとって効率的であるため、近年は度々狙われている。また、攻撃者自身がマルウェアに誘導するために広告を直接配信するケースも存在する。
  11. (※54)ドライブバイダウンロードとは、Webコンテンツを閲覧した際に何らかの脆弱性を悪用され、マルウェアに強制感染させられること。閲覧者の使用する端末に脆弱性がある場合は、そのWebコンテンツを閲覧しただけでマルウェア感染してしまう。
  12. (※55)ハッシュ値を用いた確認の重要性は、本レポートのVol.10(http://www.iij.ad.jp/dev/report/iir/010.htmlblank)の「1.4.3 ソフトウェア配布パッケージの改ざん」で詳しく解説している。
  13. (※56)クライアント環境におけるマルウェア感染対策については、本レポートのVol.21(http://www.iij.ad.jp/dev/report/iir/021.htmlblank)の「1.4.1 標的型攻撃で利用されるRAT「PlugX」」末尾で詳しく紹介している。
  14. (※57)もちろん、IDによる名寄せに限らず、登録時に入力した氏名や電話番号などの情報から名寄せされる脅威も残る。
  15. (※58)警視庁、「平成26年中のインターネットバンキングに係る不正送金事犯の発生状況等について(平成27年2月)」(https://www.npa.go.jp/cyber/pdf/H270212_banking.pdfPDF)。
  16. (※59)IPA、「法人向けインターネットバンキングの不正送金対策、しっかりできていますか?(2014年8月)」(https://www.ipa.go.jp/files/000040703.pdfPDF)。
  17. (※60)トレンドマイクロセキュリティブログ、「法人ネットバンキングを狙う電子証明書窃取攻撃を解析」(http://blog.trendmicro.co.jp/archives/9417blank)。
  18. (※61)第2回セキュアシステムシンポジウム 高木浩光、渡辺創、「Man-in-the-Browserの脅威と根本的な解決策」(https://www.risec.aist.go.jp/files/events/2014/0313-ja/risec-sympo2014-takagi.pdfPDF)。
  19. (※62)The FIDO Alliance(https://fidoalliance.org/specifications/overview/blank)。
  20. (※63)Kaspersky社の調査分析チーム(GReAT)からEquation Groupに関するレポートが公開されている。"EQUATION GROUP: QUESTIONS AND ANSWERS" (https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdfPDF)。
  21. (※64)検体のMD5ハッシュ値は11fb08b9126cdb4668b3f5135cf7a6c5。
  22. (※65)IOCとはネットワーク上や端末内に残る、マルウェア感染や不正侵入の脅威を示す痕跡のこと。メモリ上のIOCに関しては、本レポートのVol.26(http://www.iij.ad.jp/dev/report/iir/pdf/iir_vol26.pdfPDF)の「1.4.2 端末のメモリ内に潜む脅威をスキャンするopenioc_scan」を参照のこと。
  23. (※66)実際には、今回入手した検体はVista以降でUACを有効にしている環境でドライバをロードできるように設計されていない。
  24. (※67)今回検討したIOCは以下で公開されている(https://github.com/TakahiroHaruyama/openioc_scanblank)。
1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る