［2］「トロイの木馬」型が台頭、短期間で機能が大幅に進化

　Androidに感染するマルウエアは、次第に洗練されている。その兆候が見えたのが、2010年12月に発見されたトロイの木馬「Geinimi」である。

　GeinimiはSMSの読み取り・送信・削除のほか、非常に多くのユーザーデータを読み取る能力があった。電話帳、GPS位置情報、IMEI/IMSIといった端末識別子などのデータを収集する機能を備えていた。

　さらに、追加でアプリを自動的にダウンロードし、ユーザーにインストールを促す機能も搭載していた。追加アプリのインストールによって、インストール済みアプリ一覧を送信する、電話をかける、特定URLにアクセスさせるためにブラウザーを起動する、といった機能が追加される仕組みだった。このマルウエアは中国に立てられたサードパーティーアプリ配布サイトで発見された。

root権限を奪う「DroidDream」

　次に大きな進化を見せたのが、2011年3月に発見されたトロイの木馬「DroidDream」である。それまでに発見されたマルウエアと同じく、データを窃取するための多くの機能が搭載されていた。特徴は、それに加えて管理者（root）権限を奪取する機能を持っていたことである。二つの分離した特権権限昇格の脆弱性が悪用され、別の新たなアプリをダウンロード、インストールする仕組みになっていた。

　さらに、ボットネットに参加して指令サーバー（Comand ＆ Controlサーバー）と通信するために必要な機能も内包していた。DroidDreamは公式Androidマーケット上で発見され、数十万のユーザーが影響を受ける危険性があった。

　すべてというわけではないが、Androidマーケット上に存在するマルウエアの多くは、正規の開発者が合法的に作成、公開しているアプリにトロイの木馬を混入させたものである。これには、root権限を奪取することでよく知られる「rage against the cage」という攻撃コードが含まれており、これを使ってroot権限を使用し特権モードを奪取するようになっている。

　カスペルスキーラボがこれまでに観測した上記の挙動を示す悪意あるアプリは、すべて「Exploit.AndroidOS.Lotoor.g」と「Exploit.AndroidOS.Lotoor.j」という名称で検知するものと同様の脆弱性攻撃コードを使用している。両者はよく知られており、Android 2.3（Gingerbread）未満のプラットフォームが影響を受ける。Android 2.3を使用しているユーザーはこの攻撃からは保護されていることを示している。

内部コードにみる情報窃取の仕組み

図1●DroidDreamのコード

暗号化された45バイトのデータブロックである。当該ブロックは単純なXORアルゴリズムにより特別なキーを使用して暗号化されており、そのキーは「KEYVALUE」と名付けられたもう一つのデータブロックに保管されていた。

　DroidDreameなどのトロイの木馬が盗む情報は何か。一見したところ、攻撃者はAndroidの端末固有の識別子であるIMEIとIMSIを取得しようとしているように思える。加えて攻撃者はOSと端末タイプの情報を窃取している。

　では、こうした情報窃盗がどのように発生するのか、DroidDreamの内部コードを例に解説しよう。脆弱性攻撃コードは、暗号化された45バイトのデータブロックにあった（図1）。当該ブロックはXORアルゴリズムにより特別なキーを使用して暗号化され、そのキーは「KEYVALUE」と名付けられたもう一つのデータブロックに保管されていた。

　暗号を解いてみると、最初のデータブロックは「hxxp://184.105.245.17:8080/GMServer/GMServlet」というURLであることが分かった。DroidDreamはIMEIとIMSIを収集するように設計されていた。窃盗されたデータは、HTTPプロトコルを使いPOSTメソッドで犯罪者のサーバーに送付されていた（図2）。図2で「0」という値が設定されている「Command」というフィールドは、デバイス情報とともに窃盗したIMEIとIMSIを送信せよという指令である。

図2●DroidDreamにより送付されていたデータブロック

　「ProductId」というフィールドには「10023」と「10039」などの値が設定される。カスペルスキーラボではこのコードが埋め込まれたAPKファイル（アプリ）を2種類観測しているが、ProductIdには、APKファイルによって異なる値が設定されていることが分かった。このことから、攻撃者がマーケットで公開した異なるトロイの木馬検体の感染成功率を計測しようとしていることがうかがえる。

　DroidDreamは、データのアップロードが成功した後に「pref_config_setting」という設定パラメーターを「done」に変更する。これは、同一のデータを繰り返し送出することを回避するためである（図3）。

図3●DroidDreamのコード

DroidDreamはデータのアップロードが成功した後に「pref_config_setting」という設定パラメーターを「done」に変更する。

　またDroidDreamは窃取したIMEI/IMSIの送出に加え、他のモジュールのインストールも行う。これは、sqlite.dbと呼ぶ内部リソースファイルをDownloadProvidersManager.apkの中にコピーする挙動を指す。

　ダウンローダーの機能を持つモジュールは、窃取したIMEIとIMSIのアップロード先と同一のサーバーに再度接続する。ただ、要求ブロックがアップロードのときとは違っている（先述の「Command」フィールドが「2」と設定されていた）。このことから、サーバーからの返信には、感染したデバイスに既にダウンロード、インストールしたアプリの一覧を含んでいると考えられる。