Analyzing Android Malware

静的解析から見る傾向と識別方法

Android Malware Research Project Ayase(@data_head)

自己紹介

Ayase ソフトウェア開発・SIをメインとする企業に勤めています

主な業務 • インフラ設計・構築(PKI・認証システム) • ISMS(当時はBS7799)コンサル • 移動機系サービス(設計・技術検証) • そのほかトラブルシュート要員(´д｀

Blog: とある技術屋の日記 (http://sememorandum.blog.fc2.com/) Ayaseのセキュリティメモ (http://securememo.blogspot.com/) Twitter: @data_head Mail: datahead0@gmail.com

Malware解析の仕事は? →業務経験ありません。素人です(Android Malware解析暦2年)

周りに有識者いたとか… →いえ、金床さんのBlogとGoogleのDalvik関連資料が私の先生です (ありがたいことに最近プロの方からご助言・ご協力頂いております)

なぜ素人がここに立って話しているのか？

趣味から講じた Android Malware 解析ですがBlogによる情報公開に飽き足らず、昨年よりAndroid Malwareの情報を収

集・公開するためのサイトを運営し始めました。

このサイトでは収集した検体の解析結果を公開し一般向けの注意喚起やセキュリティ関連組織への検体提供をしています。

今回、主催(中津留様)にこちらのサイトに興味を持って頂き、発表の場を頂きました。

Android Malware Research Project (AMR-Project)

https://sites.google.com/site/amrprjt/

さて、今回のお話は…

今回 Android をターゲットとしたMalwareのお話をさせて頂きます。

AndroidMalwareの歴史と傾向

AndroidMalwareの識別方法

Android Malwareの歴史と傾向

Android Malwareの歴史

AndroidのMalware史上(個人的に)記憶に残っているイベントをピックアップしてみると…

2010 2011 2012 2013

FakePlayer Android初のMalware

(プレミアムSMS送信)

Geinimi 多機能Trojan の出現

Droid Dreams Root権限を奪取するTrojanの出現

MobileSpy 商用スパイウェアの出現

Oneclickfraud 日本初ワンクリ詐欺アプリの出現

CounterClank 過度な機能を持つ広告モジュールの

出現

Loicdos DoSTool の出現

DougaLeak 日本をターゲットにしたアドレス情報収集Trojanの出現

Point 初期のMalwareから実用的な機能を持っている 金銭・情報搾取目的が多くみられる 2011年に出現したRootExploitを利用するMalwareは2012年以降下火。代わりに人気アプリのRepackageや模倣で騙すケースが現在は主流

Claco Windows端末で盗聴するマルチプラットフォーム スパイウェアの出現

8/10

1/1

3/2

7/7

1/11

1/27

2/28

4/4

2/4

※上記日付は Symantec Security Response の情報に基づく

Android Malwareの機能

Android Malwareが持つメジャーな機能をピックアップしてみました。

端末内情報搾取

メッセージ(SMS/MMS)不正操作

端末内設定改ざん

Remote control

攻撃Tool

端末内情報搾取

端末固有情報

GPS

アドレス(PIM)情報

SDカード内ファイル

アプリケーションInstall/Uninstall情報

Log

メッセージ(SMS/MMS)不正操作

プレミアムSMS送信

端末内情報送信

告発メッセージ送信

リモートコマンド受信

メッセージ受信拒否・削除

端末内設定改ざん

端末設定(ネットワーク設定、BookMark…)

アプリケーションInstall(Dropper)

SDカード内ファイル改ざん・削除

ショートカットアイコン自動設定

Remote Control

前述の機能を以下のI/Fを介してリモートで実行する

Webサイト(専用のCGI, Blog)

SMS, WAPPush

攻撃Tool

DoSTool

Wi-Fiルータを介したノードへの攻撃ツール

最近の傾向

プレミアムSMS

情報搾取(Banker, アドレス(PIM)情報搾取)

BoT

SpyWare

Adware

今後の予想

アドレス情報やBank情報の搾取は継続増加

BoT ネットは増加するならこれから

海外の外部モジュールは今後も注意

Malcodeの隠ぺいは今後も巧妙化する

マルチプラットフォームへの展開(悪い意味で)

Android Malware の識別方法

さて本論に入りますが…

AndroidのMalwareを識別をするにあたり、

私はそのほとんどを静的解析で行っているわけです。

まぁ、静的解析自体は…

『割と簡単です』

ただ、Windowsの実行ファイルを解析する時同様、smaliからAPIを辿って

1つ1つ追いかけるのは 超めんどうくさい。

もう少し楽な方法はないものか…

今回のアプローチ

アイデア

前回の#Malwatで @cci_forensics さんが発表していたIOC(Indicator of Compromise)の概念を利用できないか

ということで

Apk内の各ファイル毎にMalwareの特徴を見てみる

超めんどうくさいclasses.dexの解析によるMalware識別を「APIの利用頻度解析」と「ssdeepによる類似性評価」の2つの方法から簡略化できるか試してみる

Android アプリケーションの構造

/application.apk

AndroidManifest.xml

resources.arsc

classes.dex

/assets

(img.png)

/res

/drawable

/META-INF

CERT.RSA

CERT.SF

MANIFEST.MF

icon.png

/layout

main.xml

<>

01

01

01

01

01

<>

左記の構造からファイルを抽出し、

以下の順番で解析します。

1. AndroidManifest.xml

2. META-INF/CERT.RSA

3. resources.arsc

4. classes.dex

5. res/ 配下のファイル

6. asset/ 配下のファイル

7. lib/libABI.so

今回は、実際に解析するこれらのファイルを見てみようと思います。

/lib

libABI.so <>

初動解析 •メタ情報の取得 •既存検体との比較

詳細解析 •ロジック解析 •ファミリ特定

AndroidManifest.xml

Permission (何ができる？)

→ READ_CONTACT, RECEIVE_SMS…

Receiver (何をトリガに動く？)

→ ACTION_REBOOT, SMS_RECEIVED…

Activity (外部モジュールに何がある？)

→ Apperhand, Airpush, Leadbolt…

(Tool) AXMLPrinter を使って可読化

AndroidManifest.xml - Permission Malwareが持つ機能によって要求する Permissionは様々

<uses-permission

android:name="android.permission.READ_SMS"

>

</uses-permission>

<uses-permission

android:name="android.permission.READ_CONTACTS"

>

</uses-permission>

LifemonSpy

AndroidManifest.xml - Receiver

<action

android:name="android.intent.action.BOOT_COMPLETED“

>

</action>

<action

android:name="android.intent.action.CAMERA_BUTTON“

>

</action>

<action

android:name="android.intent.action.CONFIGURATION_CHANGED“

>

</action>

<action

android:name="android.intent.action.DATA_SMS_RECEIVED“

>

</action>

指定されたイベントが発生するとアプリが起動する。左記のようにあらゆるイベントをキャッチする場合、プロセスを殺してもすぐに上がってくる。

FakeLookout

AndroidManifest.xml - Activity

<service

android:name="com.apperhand.device.android.AndroidSDKProvider“

android:enabled="true“

>

</service>

<activity

android:theme="@android:0103000F“

android:name="com.apperhand.device.android.EULAActivity“

>

</activity>

画面を持っていたり、サービスが 立ち上がる外部モジュールはAndroid Manifestに設定が必要になる。 また、ここに設定されたパッケージ名 はProguardの対象外となるため、 smaliでも追跡しやすい。

Counterclank

META-INF/CERT.RSA

Signature →過去のMalwareと比較して同じならバリアントか、同一開発者による別のファミリである可能性が高い

DN(Issuer/Subject) →野良アプリはDebug証明書を用いているケースが多い。開発者の自己署名の場合も意味のない文字列のケースが多いため特徴をつかむのは難しい

(Tool) Binary Editor or OpenSSL

resources.arsc

アプリ名 →インストール時に端末で表示されるアプリケーション名を確認できる。

(Android Malware ではInstall時のアプリ名がWebサイト上で表記されるアプリ名と異なるケースが多い)

URL →C&CサーバのURLが入っていることがある。

同一ファミリの場合同じC&Cサーバを用いているケースが多いことからファミリの識別やMalwareのシステム構成をつかむ証拠になる

(Tool) Binary Editor

resouces.arsc

実際にアプリをインストールしなくてもresourcesファイルでインストール時のアプリ名を確認できる。

ただし、 resourcesファイル内のマルチバイトはUTF-8だったり、Unicodeだったりアプリによって異なるので、普段Stirlingを使っている私はUTF-8のためにBZも入れている(面倒)

Enesoluty

classes.dex

静的解析の大本命

Smali を直接読む → 超めんどうくさい

なので…

1. SmaliからAPI(invoke-virtual) を抽出してAPI毎の利用頻度を比較し類似性を評価する

2. Ssdeepでsmaliを比較し類似性を評価する

という2つの方法から既知のMalwareとの類似性を評価して識別できるか試してみました。

(Tool) baksmali

classes.dex – APIの利用頻度解析

1. SmaliからAPI Call(invoke-virtual)の行のみ抽出

2. その中からGoogle 標準APIのみさらに抽出

3. API毎にカウントを取ってAPIの利用頻度を算出

4. 同様の方法で複数の検体からAPIの利用頻度を抽出

5. 検体同士APIの利用頻度からコサイン類似度を算出

6. 算出結果が0～1で1に近いほど類似している(はず…)

classes.dex – APIの利用頻度解析(結果)

A121212003 A121114001 A121212001 A120412001 A120708001 A121020001

A121212003

(Enesoluty.A(12/12)) 100.00% 40.96% 22.13% 22.31% 2.66%

A121114001

(Enesoluty.A(11/14)) 100.00% 40.96% 22.13% 22.31% 2.66%

A121212001

(Enesoluty.B(12/12)) 40.96% 40.96% 74.22% 72.79% 6.60%

A120412001

(DougaLeak) 22.13% 22.13% 74.22% 66.66% 5.88%

A120708001

(CounterClank) 22.31% 22.31% 72.79% 66.66% 5.23%

A121020001

(FakeLookout) 2.66% 2.66% 6.60% 5.88% 5.23%

→ あまりいけてない…

誤検知

classes.dex – ssdeep

classes.dex(バリアント)のままだとうまく

評価できないようなのでsmaliに対して

ハッシュ算出してみたのですが…

Ssdeepに至っては、C&CサーバのURLが違うだけのバリアントで64Point(完全一致で100)。

Stringの数が増減するだけでString_idsのIndex値がずれてしまうために以降のデータが全部変わってしまってるのかも…

このままではダメっぽい…

そうだ！西田さんに聞いてみよう！(ごめんなさい

res/・asset/

画像ファイルやrawデータファイル等はバリアントで使いまわしてるケースもあるため、特徴情報として使えるケースもある。

また、PNGファイル内に別のファイルを埋め込んでるケースもあり、画像ファイルの中をチェックすることも必要

PNGファイル内のdex埋め込み例

Android.GameXの例

asset/logo.pngをバイナリエディタで見てみると…

apkが埋め 込まれている

lib/libABI.so

偶然にも今までネイティブライブラリをcoreにしたMalwareが表に出てくることはなかったのですが、

このアプリのおかげでネイティブライブラリも今後の解析対象に入ることとなりました。

冒頭に述べたとおり、私はネイティブコードの解析についてはさっぱりなので、今後の課題になります。

まとめ

Androidの歴史と傾向

Android Malware の識別を効率化するための基礎研究 Apk内の各ファイル毎の識別ポイントまとめ

Classes.dexの類似性評価の試み(そして失敗)

見解

今回挙げたMalwareの識別ポイントから複合的に判断してMalwareの識別が可能。

類似性評価は方法を見直し、より多くのサンプルで検証が必要。

今後の展開と希望

Malwareの特徴を抽出したメタ情報をDB化して比較できるようにしたい

類似性評価は今回全くいけてなかったので、より多くのサンプルで検証しながら精度を上げていきたい

オープンな形で運営されたメタ情報DBが欲しい

Android Malwareの分類統一を望みたい(これは難しいかも…)

→一緒に考えて頂ける方いらっしゃいましたらお声掛けて頂けると嬉しいです