只今新幹線 新大阪駅のモバイルコーナーでまったりと新幹線(こだま)待ち。
(ぷらっとこだまを利用しているので、こだまなのです。)
東京に着くのは13時前……それまではまったりと「列車の旅」を楽しみたいと思います。
(しかも少し奮発してグリーン車なので、少しゆっくりできそうです。)
(ぷらっとこだまを利用しているので、こだまなのです。)
東京に着くのは13時前……それまではまったりと「列車の旅」を楽しみたいと思います。
(しかも少し奮発してグリーン車なので、少しゆっくりできそうです。)
第23回まっちゃ139勉強会
今回は大阪電通大の寝屋川キャンパスのJ号館が会場になります。新しい建物ですよ～。
今回は人数が多い(100名程度)という事もあり、アイスブレイクである「自己紹介」がいつもとは少し違うスタイルになっています(中身は非公開なので、来た人だけのお楽しみという事で)。
-----
session1:Androidフォンのセキュリティ(KDDI研究所 竹森敬祐さん)
初っ端からオフレコですm(_ _)m
……感想だけならOKかな?、話自体は面白いけれど、非常に深い話です。色々と考えさせられますね。
Session2:アンチウイルス屋から見たAndroidセキュリティ(Kaspersky 前田さん)
前振りネタ……UFO:Blocked???→URL Forward Objectの略???
URL転送型のマルウェア???
今日のテーマ：「煽」
観測情報
残念ながら増加傾向、但しマルウェア全体(PC等も含む)からするとごく少数ではありますが
2011/10/28現在のシグネチャ数は4,706
2008年を境に急増しています(収益化の期間に突入したかと)
2011年は集計期間が半年でありながら昨年(2010年)の実績を遥かに越えています
プラットフォーム別で見ると、最も多いのはJ2ME(50%以上)ですが、Androidもじわじわ増えています(24%)。
ファミリー数で言うと300以上(亜種入れて、4,706種)
過去最多で出現したのは2010/8期で、314種類
最も多いのはSMS Trojan
スマートフォンはアンチウイルスでどこまで守れるのか?
一般的な各社セキュリティ製品で実装されている機能
・盗難対策
・暗号化
・アンチウイルス・ファイアウォール
・プライバシープロテクション など
……アンチウイルスは、あくまでセキュリティ対策製品として、一部機能であるという扱いになっている
Android製品→ユーザモードで動くモノが中心
iOSとWindows Phone→API非公開なので、まず無理
アンチウイルスは有効か?
WindowsのアンチウイルスとAndroidのアンチウイルスの違いって?
・セキュリティ特権上で動いているか否か?
→Androidの場合は、どうしてもユーザ権限で動作させざるを得ない状態である
・パターンマッチング以外(振る舞い検知など)以外の検知方法を実装しているか否か?
→Androidの場合、パターンマッチング以外の検知方法は実装していないケースが多い
ではAndroid OSは強いのか?
Android 2.2までは、DEPなどのセキュリティ対策システムが含まれていなかったので、あまり強いとはお世辞にも言えない
2.3以降は一部だけれどそのような機能が実装されている(DEPとか)……が、まだ未実装な機能があるため、その点では弱いという点は認識する必要がある
Androidアンチウイルスの課題
リアルタイム保護?
電池問題
一般ユーザ権限で動作
他ユーザに許可していない限り、インストール済みの他のアプリのデータにアクセスできない
root権限で動作するマルウェアを駆除できない
→rootを奪取する穴を突かれた後、どうするのか?
→もっと凶悪なrootkitが出てきたらどうする???
root(/system)を保護するアイデアとして……
OS側からAPI提供を受ける→本当はkernel callをフックしたい
もしくはdalvik(サンドボックス)を串してくれるようなものとか?
予めroot権限で動くアンチウイルス製品を入れておく
Session3:結構やりたい放題？Androidアプリの実際(はるぷさん)
アプリをインストールするとどこまで行く?
……普通に考えると「端末の中」ですよね
Androidでは「USBデバッグ」という便利で凶悪(?)な機能がある
(補足)
USBデバッグの凶悪さは、@ITの記事が参考になるかと思います。
USBデバッグでできること
1.SDカードの中身が見られる
写真、電話帳のバックアップ、ブラウザでダウンロードしたファイルなど
→漏洩したら大変だけど、全てのアプリでパーミッション無しで見られるので、今回は放置
2.システムのファイルを見られる
インストールしたアプリにフォーカスして見ると、次のいずれか
/data/app-private
→コピー防止オプションを指定している場合が該当、取得にはroot化が必要
/data/app
→コピー防止オプションを指定していない場合が該当、USBデバッグや他のアプリから取得可能
基本的にはAPKファイルはZIP形式のファイルで、中の設定ファイルはテキストベース(xml形式など)なので、解凍するだけで、結構な情報が見えてしまいます
実はiOSのアプリも似たような形式なので、調べようと思えば調べられたりするとか……
ならば、対リバースエンジニアリングとして難読化しよう
「ProGuard」→Eclipseから呼び出す事が可能
でも、それで本当にOKなの???
→ハードコーディングしているデータなどは難読化されていない!!
→難読化されている場所も、あまり難読化されていないのでは???
なので過信は禁物!!
まとめ
・Androidアプリのコードを守るのは難しい(リバースエンジニアリングで見られる事を前提とする必要がある)
・見られたら困る情報は端末上には置かない(サーバと通信するアプリの場合、見られてはいけない処理や情報はサーバ上に置く)
・何かが起きた時に、ユーザが判断できる情報を提供する(自社のHP上で告知など)
(筆者補足)
ちょうど一週間前に行われたまっちゃ445勉強会#18の話と被る部分が多いので、そちらも参考にされると良いかも。
Session4:iOSの審査なんてくそくらえさ！(TWORKS@楽しいアプリ製作の会 さん)
スマートフォン→アプリケーションプラットフォーム
アプリケーション審査の有無
iOS→ある、不自由なプラットフォーム(クローズド)
Android→ありません、自由なプラットフォーム
(補足)
auマーケットのように、審査を行うマーケットプレイスも中にはあります
iOSのアプリケーション審査
1年ほど前から、22のガイドラインが設けられている
今回は「機能」「インターフェース」「法律」に特化してお話します
「機能」
隠し機能の禁止
サンドボックス外のデータの読み書き禁止
実行コードを外部からダウンロードするのも禁止
明記・明示されていない、偽の機能やジョーク機能もアウト など
「インターフェース」
Appleが定めた基準(ガイドライン、PDFにして100p超)を逸脱する場合はアウト
「法律」
各地の法律を理解し準拠するのは開発者の責務である
誤り、虚偽、誤解を招く説明を含むアプリはダメ
違法なファイル共有を行うアプリはアウト など
審査の意義
バグがあるアプリや、悪意を持つアプリを事前に排除できる
類似するアプリや無意味なアプリを除外できる
→ユーザが安心できる環境を作るため
適切なアプリの増加→利用者の増加右→市場の拡大・開発者の増加→……
審査のコスト
iOS、Windows Phone→$99/年
ただしWindows Phoneの場合、101本目からは別途審査料が発生する
Android→25$、マーケット使用料は審査無し
(まとめ)
・審査には市場を健全化する効果がある
・健全な環境には、健全にアプリと開発者が流通する
・Apple頑張っている
・オープンプラットフォームにもそれなりの良さはあるけど、やはりそれ相応のリスクがある事も認識する必要がある
・タイトルはまっちゃさんが決めた事でくぁwせdrftgyふじこlp
今回は大阪電通大の寝屋川キャンパスのJ号館が会場になります。新しい建物ですよ～。
今回は人数が多い(100名程度)という事もあり、アイスブレイクである「自己紹介」がいつもとは少し違うスタイルになっています(中身は非公開なので、来た人だけのお楽しみという事で)。
-----
session1:Androidフォンのセキュリティ(KDDI研究所 竹森敬祐さん)
初っ端からオフレコですm(_ _)m
……感想だけならOKかな?、話自体は面白いけれど、非常に深い話です。色々と考えさせられますね。
Session2:アンチウイルス屋から見たAndroidセキュリティ(Kaspersky 前田さん)
前振りネタ……UFO:Blocked???→URL Forward Objectの略???
URL転送型のマルウェア???
今日のテーマ：「煽」
観測情報
残念ながら増加傾向、但しマルウェア全体(PC等も含む)からするとごく少数ではありますが
2011/10/28現在のシグネチャ数は4,706
2008年を境に急増しています(収益化の期間に突入したかと)
2011年は集計期間が半年でありながら昨年(2010年)の実績を遥かに越えています
プラットフォーム別で見ると、最も多いのはJ2ME(50%以上)ですが、Androidもじわじわ増えています(24%)。
ファミリー数で言うと300以上(亜種入れて、4,706種)
過去最多で出現したのは2010/8期で、314種類
最も多いのはSMS Trojan
スマートフォンはアンチウイルスでどこまで守れるのか?
一般的な各社セキュリティ製品で実装されている機能
・盗難対策
・暗号化
・アンチウイルス・ファイアウォール
・プライバシープロテクション など
……アンチウイルスは、あくまでセキュリティ対策製品として、一部機能であるという扱いになっている
Android製品→ユーザモードで動くモノが中心
iOSとWindows Phone→API非公開なので、まず無理
アンチウイルスは有効か?
WindowsのアンチウイルスとAndroidのアンチウイルスの違いって?
・セキュリティ特権上で動いているか否か?
→Androidの場合は、どうしてもユーザ権限で動作させざるを得ない状態である
・パターンマッチング以外(振る舞い検知など)以外の検知方法を実装しているか否か?
→Androidの場合、パターンマッチング以外の検知方法は実装していないケースが多い
ではAndroid OSは強いのか?
Android 2.2までは、DEPなどのセキュリティ対策システムが含まれていなかったので、あまり強いとはお世辞にも言えない
2.3以降は一部だけれどそのような機能が実装されている(DEPとか)……が、まだ未実装な機能があるため、その点では弱いという点は認識する必要がある
Androidアンチウイルスの課題
リアルタイム保護?
電池問題
一般ユーザ権限で動作
他ユーザに許可していない限り、インストール済みの他のアプリのデータにアクセスできない
root権限で動作するマルウェアを駆除できない
→rootを奪取する穴を突かれた後、どうするのか?
→もっと凶悪なrootkitが出てきたらどうする???
root(/system)を保護するアイデアとして……
OS側からAPI提供を受ける→本当はkernel callをフックしたい
もしくはdalvik(サンドボックス)を串してくれるようなものとか?
予めroot権限で動くアンチウイルス製品を入れておく
Session3:結構やりたい放題？Androidアプリの実際(はるぷさん)
アプリをインストールするとどこまで行く?
……普通に考えると「端末の中」ですよね
Androidでは「USBデバッグ」という便利で凶悪(?)な機能がある
(補足)
USBデバッグの凶悪さは、@ITの記事が参考になるかと思います。
USBデバッグでできること
1.SDカードの中身が見られる
写真、電話帳のバックアップ、ブラウザでダウンロードしたファイルなど
→漏洩したら大変だけど、全てのアプリでパーミッション無しで見られるので、今回は放置
2.システムのファイルを見られる
インストールしたアプリにフォーカスして見ると、次のいずれか
/data/app-private
→コピー防止オプションを指定している場合が該当、取得にはroot化が必要
/data/app
→コピー防止オプションを指定していない場合が該当、USBデバッグや他のアプリから取得可能
基本的にはAPKファイルはZIP形式のファイルで、中の設定ファイルはテキストベース(xml形式など)なので、解凍するだけで、結構な情報が見えてしまいます
実はiOSのアプリも似たような形式なので、調べようと思えば調べられたりするとか……
ならば、対リバースエンジニアリングとして難読化しよう
「ProGuard」→Eclipseから呼び出す事が可能
でも、それで本当にOKなの???
→ハードコーディングしているデータなどは難読化されていない!!
→難読化されている場所も、あまり難読化されていないのでは???
なので過信は禁物!!
まとめ
・Androidアプリのコードを守るのは難しい(リバースエンジニアリングで見られる事を前提とする必要がある)
・見られたら困る情報は端末上には置かない(サーバと通信するアプリの場合、見られてはいけない処理や情報はサーバ上に置く)
・何かが起きた時に、ユーザが判断できる情報を提供する(自社のHP上で告知など)
(筆者補足)
ちょうど一週間前に行われたまっちゃ445勉強会#18の話と被る部分が多いので、そちらも参考にされると良いかも。
Session4:iOSの審査なんてくそくらえさ！(TWORKS@楽しいアプリ製作の会 さん)
スマートフォン→アプリケーションプラットフォーム
アプリケーション審査の有無
iOS→ある、不自由なプラットフォーム(クローズド)
Android→ありません、自由なプラットフォーム
(補足)
auマーケットのように、審査を行うマーケットプレイスも中にはあります
iOSのアプリケーション審査
1年ほど前から、22のガイドラインが設けられている
今回は「機能」「インターフェース」「法律」に特化してお話します
「機能」
隠し機能の禁止
サンドボックス外のデータの読み書き禁止
実行コードを外部からダウンロードするのも禁止
明記・明示されていない、偽の機能やジョーク機能もアウト など
「インターフェース」
Appleが定めた基準(ガイドライン、PDFにして100p超)を逸脱する場合はアウト
「法律」
各地の法律を理解し準拠するのは開発者の責務である
誤り、虚偽、誤解を招く説明を含むアプリはダメ
違法なファイル共有を行うアプリはアウト など
審査の意義
バグがあるアプリや、悪意を持つアプリを事前に排除できる
類似するアプリや無意味なアプリを除外できる
→ユーザが安心できる環境を作るため
適切なアプリの増加→利用者の増加右→市場の拡大・開発者の増加→……
審査のコスト
iOS、Windows Phone→$99/年
ただしWindows Phoneの場合、101本目からは別途審査料が発生する
Android→25$、マーケット使用料は審査無し
(まとめ)
・審査には市場を健全化する効果がある
・健全な環境には、健全にアプリと開発者が流通する
・Apple頑張っている
・オープンプラットフォームにもそれなりの良さはあるけど、やはりそれ相応のリスクがある事も認識する必要がある
・タイトルはまっちゃさんが決めた事でくぁwせdrftgyふじこlp
まだ発表前ですが、資料公開しました。
第23回 まっちゃ139 午前の部 発表資料 - End of ... wiki
このページの末尾から資料(PDF)がダウンロードできます。
また当日であればUSBメモリ経由でもお渡しする事が可能です。
第23回 まっちゃ139 午前の部 発表資料 - End of ... wiki
このページの末尾から資料(PDF)がダウンロードできます。
また当日であればUSBメモリ経由でもお渡しする事が可能です。
第18回まっちゃ445勉強会 - まっちゃ445
今回は横浜にある情報セキュリティ大学院大学が会場です。
-----
Session1:「マルウェア解析王に、俺はなる！」(ラックホールディングス株式会社/サイバーセキュリティ研究所/新井悠さん)
そんなものはない(ヲ
タイトル→標的型マルウェアを高速に解析するために必要なたった一つの事
文書型マルウェアの解析法
1.OfficeやAdobe Readerを準備
2.動的解析ツールを準備
3.文書ファイルを開封
4.動的解析結果をレビュー
課題1:OSやアプリのバージョンに強く依存する
まともに動かない場合もあるし、どの環境に対して脅威なのかを特定するのには非常に時間かかる
バージョン、パッチの適用状況、言語によって動く、動かないは大きく変わる
なので様々な環境をセットしたVMを沢山用意する必要がある(コストに影響)
課題2:そもそも解析に時間がかかる
詳細に解析するばするほど時間がかかるし、中には対解析機能を有している場合は、それを回避する必要がある
でいざ解析を始めても、静的解析にかかる時間(アセンブリコードを読む時間)はとにかく時間がかかる
解析で得られる情報量、時間などのコストはこの逆です
表層解析＜動的解析＜静的解析
表層解析は「あたり」を付ける作業、なのでコードはこの時点では読まない
動的解析は、実際に動かして様子を探る作業、この時点もコードは読まない
解析時間は短くて済むが、発病要件を満たさなければ空振りに終わる可能性も……
静的解析は、いわゆるリバースエンジニアリング作業、ツールを用いて逆アセンブルしてコードを読む作業になる
効率性は……
表層解析＞動的解析＞＞＞(超えられない壁)＞＞＞静的解析
標的型マルウェアを解析する目的
対策は何か?、痕跡はどこにあるか?、通信で感染端末を特定する方法はあるか?
これらを短時間で効率的に実現できればベスト
一般的に、文書型のマルウェアは「スクリプト」「マルウェア本体」「代替文書」の3つのコンポーネントによって構成されている。
まずはトリガであるスクリプトを解析する事で、速やかに解析できるようになる(解析にはツールを用いる)
REMnux→マルウェア解析用Ubuntuイメージ、イメージさえ使えばすぐに使える便利なツール、最近ver2.0にアップデートしました
jsunpack→フリーの難読化JavaScript解析ツール、入力してPDFも受け付ける便利なものです。コマンドライン版で脆弱性の特定ができ、前述のREMnumxにも収録されています
OfficeMalscanner→MS-Office文書専用のツールで、シェルコードの有無をチェックして検体として取り出してくれるツールです
最近は検知回避するために、前述の3つのコンポーネントに対して、検知回避用のXOR、ROL/RORによる符号化がされている場合があります(いわゆる難読化)
xorsearch→これらの難読化に対するブルートフォースを行うツールです(これもREMnuxに収録)、引数として与えられた特定の文字列と一致する複合結果が得られるのであれば、結果を出力します
「Zero Wire Tryouts」という動的解析ツール(VMイメージで提供されている)がある(exeのみ対応)ので、それを活用するのもアリ
(まとめ)
・標的型攻撃には、文書型マルウェアがよく使われる
・マルウェア解析には時間がかかるが、対策・復旧目的の情報をすばやく解析する方法はある
・これらを行うためのツールがフリーで用意されているのでそれを使うと良い
-----
Session2:「モテる男子のためのアンパック」(NTT情報流通プラットフォーム研究所/岩村誠さん)
(その1)コンパイラ出力コードモデルの尤度に基づくアンパック手法
アンパッキングの自動化→書込み後に実行されたメモリ領域を検出することで、オリジナルエントリポイント(アンパッキングの完了ポイント)を検出する
動的に生成されたコードは、実はまだオリジナルのコードではない場合もある→コンパイラが出力したバイナリっぽさを検出する
よく使う命令(mov edi,edi)が出てきて、逆にコンパイラではあまり使わない命令や分岐処理がないコードが、コンパイラが出力したバイナリでは?、と仮定して、それを検出する
(どうやって検出するかは「隠れマルコフモデル」を用いる……詳しい数式などは省略)
CCCで得た検体(230検体)を基に、実証実験を実施→結果、アンパッキング中のコードとアンパック後のコードを完全に識別できた
(その2)マルウェアのエントリポイント検出後のおけるコード領域識別手法
オリジナルのエントリポイントを検出した→じゃあ、どこからどこまでがコード or データなのか?
マルウェアの場合、抽出を難しくしているケースもある→全部調べるだと、当然検出精度が低下する
通常の命令分岐の場合は、相対アドレス指定の分岐命令が使われる、これがコード領域をまたぐことは通常ない→ならばそれを上手く活用できれば特定できるのでは
特定するために、やはりここでも隠れマルコフモデルを活用して、プログラムコードの切れ目を特定する
(その3)IATエントリ格納場所の特定方法
マルウェアがどんなAPIを呼び出しているのかを調べる
パックされていない場合は、PEヘッダのImport Tableを見れば一発だけど、アンパックしたばかりのプログラムの場合は、PEヘッダが消えてしまっている場合がある→プログラムコードからIATの場所を特定する必要がある
オリジナルコードから0xFF、0x15/0x25を探し、オペランド部をIAT格納場所として認識→データ部分にあると誤検知してしまう(単純計算で32KBに1つ程度)
→ランタイムパッカーが意図的にこれらコードを混入させる事は可能か?
→可能、PEヘッダのリロケーションテーブルを参照すれば、逆アセンブルせずともベースアドレス変更が可能、これを活用して錯乱させる事も可能
とは言えパッカー、パックした結果元のコードが動かないのでは本末転倒→パックするのに自身のある箇所とそうでない箇所(あまりいじらない場所)が発生し、その特徴を上手く利用するで、通常の逆アセンブルツールよりも高い精度でIATエントリ格納場所を特定する事が可能
-----
Session3：「モバイルマルウェアやばい。まず広い。」(ラックホールディングス株式会社/サイバーセキュリティ研究所/山城重成さん )
(その1)Androidマルウェアの実例
大きく4分類に分けられます。
・端末情報取得系
・ボット系
・金銭目的系
・Root奪取
Androidマルウェアの特徴は次の3点。
・通常のアプリの裏で悪さをする
・正規のパッケージを改ざんしたものが殆ど
・感染してもアプリケーションの削除で駆除可能(なものもある...Root奪取は除く)
リパッケージによるアプリ改ざん
元のアプリパッケージは、実はZIP書庫、解凍したデータをデコンパイルし、不正コードを埋め込み、リコンパイル～リパッケージしてマーケットプレイスで公開という流れで生成、公開されている
パーミッション
アブリ毎に使える機能を制限するのだが、通常はインストール時に確認画面が表示されます(こんな機能を使うよ、というメッセージが出ます)
……が、普通の人が見ても分かりませんよね
(その2)ボットアプリによる遠隔操作デモ
メール(GMail)経由で不正コードが埋め込まれたパッケージが置かれたサイト(今回はAndroidマーケットではなく、専用に用意されたサーバ)にアクセス、アプリをインストールすると、ボットとして振舞う、というシナリオでデモが実施されました。
(その3)マルウェア解析手法
APKファイルの構造はこんな感じ。
・asset
・AndroidManifesto.xml
・classes.dex
・その他データ
・apktool→APKに内包したファイルをデコード、但し出力されるデータは見にくいかも
・dex2jar(dex→jar変換ツール) + jad(classをソースコードに変換)→結構綺麗なコードが出力されるが、変換精度があまり高くないのが難点(例外処理とかが該当)
とは言え、実際にやると面倒なので、実際に解析ツールを作ってみました(まだ非公開です)
(まとめ)
・Androidアプリの構造はシンプル
・呼び出されるインテント情報を集めれば、挙動解析は容易
・ただし一部のマルウェアについては、部分的に暗号化しているものもある
・NDKでコンパイルされてる部分はIDAで解析
・静的＋動的解析の組み合わせ
-----
今回は横浜にある情報セキュリティ大学院大学が会場です。
-----
Session1:「マルウェア解析王に、俺はなる！」(ラックホールディングス株式会社/サイバーセキュリティ研究所/新井悠さん)
そんなものはない(ヲ
タイトル→標的型マルウェアを高速に解析するために必要なたった一つの事
文書型マルウェアの解析法
1.OfficeやAdobe Readerを準備
2.動的解析ツールを準備
3.文書ファイルを開封
4.動的解析結果をレビュー
課題1:OSやアプリのバージョンに強く依存する
まともに動かない場合もあるし、どの環境に対して脅威なのかを特定するのには非常に時間かかる
バージョン、パッチの適用状況、言語によって動く、動かないは大きく変わる
なので様々な環境をセットしたVMを沢山用意する必要がある(コストに影響)
課題2:そもそも解析に時間がかかる
詳細に解析するばするほど時間がかかるし、中には対解析機能を有している場合は、それを回避する必要がある
でいざ解析を始めても、静的解析にかかる時間(アセンブリコードを読む時間)はとにかく時間がかかる
解析で得られる情報量、時間などのコストはこの逆です
表層解析＜動的解析＜静的解析
表層解析は「あたり」を付ける作業、なのでコードはこの時点では読まない
動的解析は、実際に動かして様子を探る作業、この時点もコードは読まない
解析時間は短くて済むが、発病要件を満たさなければ空振りに終わる可能性も……
静的解析は、いわゆるリバースエンジニアリング作業、ツールを用いて逆アセンブルしてコードを読む作業になる
効率性は……
表層解析＞動的解析＞＞＞(超えられない壁)＞＞＞静的解析
標的型マルウェアを解析する目的
対策は何か?、痕跡はどこにあるか?、通信で感染端末を特定する方法はあるか?
これらを短時間で効率的に実現できればベスト
一般的に、文書型のマルウェアは「スクリプト」「マルウェア本体」「代替文書」の3つのコンポーネントによって構成されている。
まずはトリガであるスクリプトを解析する事で、速やかに解析できるようになる(解析にはツールを用いる)
REMnux→マルウェア解析用Ubuntuイメージ、イメージさえ使えばすぐに使える便利なツール、最近ver2.0にアップデートしました
jsunpack→フリーの難読化JavaScript解析ツール、入力してPDFも受け付ける便利なものです。コマンドライン版で脆弱性の特定ができ、前述のREMnumxにも収録されています
OfficeMalscanner→MS-Office文書専用のツールで、シェルコードの有無をチェックして検体として取り出してくれるツールです
最近は検知回避するために、前述の3つのコンポーネントに対して、検知回避用のXOR、ROL/RORによる符号化がされている場合があります(いわゆる難読化)
xorsearch→これらの難読化に対するブルートフォースを行うツールです(これもREMnuxに収録)、引数として与えられた特定の文字列と一致する複合結果が得られるのであれば、結果を出力します
「Zero Wire Tryouts」という動的解析ツール(VMイメージで提供されている)がある(exeのみ対応)ので、それを活用するのもアリ
(まとめ)
・標的型攻撃には、文書型マルウェアがよく使われる
・マルウェア解析には時間がかかるが、対策・復旧目的の情報をすばやく解析する方法はある
・これらを行うためのツールがフリーで用意されているのでそれを使うと良い
-----
Session2:「モテる男子のためのアンパック」(NTT情報流通プラットフォーム研究所/岩村誠さん)
(その1)コンパイラ出力コードモデルの尤度に基づくアンパック手法
アンパッキングの自動化→書込み後に実行されたメモリ領域を検出することで、オリジナルエントリポイント(アンパッキングの完了ポイント)を検出する
動的に生成されたコードは、実はまだオリジナルのコードではない場合もある→コンパイラが出力したバイナリっぽさを検出する
よく使う命令(mov edi,edi)が出てきて、逆にコンパイラではあまり使わない命令や分岐処理がないコードが、コンパイラが出力したバイナリでは?、と仮定して、それを検出する
(どうやって検出するかは「隠れマルコフモデル」を用いる……詳しい数式などは省略)
CCCで得た検体(230検体)を基に、実証実験を実施→結果、アンパッキング中のコードとアンパック後のコードを完全に識別できた
(その2)マルウェアのエントリポイント検出後のおけるコード領域識別手法
オリジナルのエントリポイントを検出した→じゃあ、どこからどこまでがコード or データなのか?
マルウェアの場合、抽出を難しくしているケースもある→全部調べるだと、当然検出精度が低下する
通常の命令分岐の場合は、相対アドレス指定の分岐命令が使われる、これがコード領域をまたぐことは通常ない→ならばそれを上手く活用できれば特定できるのでは
特定するために、やはりここでも隠れマルコフモデルを活用して、プログラムコードの切れ目を特定する
(その3)IATエントリ格納場所の特定方法
マルウェアがどんなAPIを呼び出しているのかを調べる
パックされていない場合は、PEヘッダのImport Tableを見れば一発だけど、アンパックしたばかりのプログラムの場合は、PEヘッダが消えてしまっている場合がある→プログラムコードからIATの場所を特定する必要がある
オリジナルコードから0xFF、0x15/0x25を探し、オペランド部をIAT格納場所として認識→データ部分にあると誤検知してしまう(単純計算で32KBに1つ程度)
→ランタイムパッカーが意図的にこれらコードを混入させる事は可能か?
→可能、PEヘッダのリロケーションテーブルを参照すれば、逆アセンブルせずともベースアドレス変更が可能、これを活用して錯乱させる事も可能
とは言えパッカー、パックした結果元のコードが動かないのでは本末転倒→パックするのに自身のある箇所とそうでない箇所(あまりいじらない場所)が発生し、その特徴を上手く利用するで、通常の逆アセンブルツールよりも高い精度でIATエントリ格納場所を特定する事が可能
-----
Session3：「モバイルマルウェアやばい。まず広い。」(ラックホールディングス株式会社/サイバーセキュリティ研究所/山城重成さん )
(その1)Androidマルウェアの実例
大きく4分類に分けられます。
・端末情報取得系
・ボット系
・金銭目的系
・Root奪取
Androidマルウェアの特徴は次の3点。
・通常のアプリの裏で悪さをする
・正規のパッケージを改ざんしたものが殆ど
・感染してもアプリケーションの削除で駆除可能(なものもある...Root奪取は除く)
リパッケージによるアプリ改ざん
元のアプリパッケージは、実はZIP書庫、解凍したデータをデコンパイルし、不正コードを埋め込み、リコンパイル～リパッケージしてマーケットプレイスで公開という流れで生成、公開されている
パーミッション
アブリ毎に使える機能を制限するのだが、通常はインストール時に確認画面が表示されます(こんな機能を使うよ、というメッセージが出ます)
……が、普通の人が見ても分かりませんよね
(その2)ボットアプリによる遠隔操作デモ
メール(GMail)経由で不正コードが埋め込まれたパッケージが置かれたサイト(今回はAndroidマーケットではなく、専用に用意されたサーバ)にアクセス、アプリをインストールすると、ボットとして振舞う、というシナリオでデモが実施されました。
(その3)マルウェア解析手法
APKファイルの構造はこんな感じ。
・asset
・AndroidManifesto.xml
・classes.dex
・その他データ
・apktool→APKに内包したファイルをデコード、但し出力されるデータは見にくいかも
・dex2jar(dex→jar変換ツール) + jad(classをソースコードに変換)→結構綺麗なコードが出力されるが、変換精度があまり高くないのが難点(例外処理とかが該当)
とは言え、実際にやると面倒なので、実際に解析ツールを作ってみました(まだ非公開です)
(まとめ)
・Androidアプリの構造はシンプル
・呼び出されるインテント情報を集めれば、挙動解析は容易
・ただし一部のマルウェアについては、部分的に暗号化しているものもある
・NDKでコンパイルされてる部分はIDAで解析
・静的＋動的解析の組み合わせ
-----
ソニーストアの方で、とりあえず「入荷次第」という感じで予約できたのだが、これって12/17(土)出荷分なのか、それともそれ以降なのか……???
予約リストのステータスだと「入荷待ち」という状況なのだが、その辺りがよく分からない(と言うか不親切と言うか)。
と言うか、本体と周辺機器のみで、肝心のソフトは予約していないとか何とか(ヲ
まぁ、個人的には「Ys セルセタの樹海」待ちなので、それまでに手に入ればOKなんですけれどね。
予約リストのステータスだと「入荷待ち」という状況なのだが、その辺りがよく分からない(と言うか不親切と言うか)。
と言うか、本体と周辺機器のみで、肝心のソフトは予約していないとか何とか(ヲ
まぁ、個人的には「Ys セルセタの樹海」待ちなので、それまでに手に入ればOKなんですけれどね。
第23回まっちゃ139勉強会
午前の部「めざまし勉強会」のLTに立候補したら通ったので、話す事になりました。
正式なタイトルはまだ確定じゃないですが、ネタは「XenServer」に関する話を予定しています。
いやね、今話題の「標的型攻撃」に関する話をしたいんですが、色々あって(※1)ちょっとこのネタはオフレコでも話せない状態という事もあり、泣く泣くパス。
で、少し前まで扱っていたXenServerに関する話(当然セキュリティの話込み)をしようという事になりました。
只今鋭意資料作成中(ヲ
あ、そうそう、今回は「一泊三日」です(マテ
(29日の夜は宿で寝て、早朝新幹線に乗って帰るという具合です。観光しようかとも考えましたが、早めに帰ってゆっくりしたいので。)
---
(※1)本当に話したくても話せない事情があるので……つーか、リアル o... rz 状態になるので、勘弁して下さい。
午前の部「めざまし勉強会」のLTに立候補したら通ったので、話す事になりました。
正式なタイトルはまだ確定じゃないですが、ネタは「XenServer」に関する話を予定しています。
いやね、今話題の「標的型攻撃」に関する話をしたいんですが、色々あって(※1)ちょっとこのネタはオフレコでも話せない状態という事もあり、泣く泣くパス。
で、少し前まで扱っていたXenServerに関する話(当然セキュリティの話込み)をしようという事になりました。
只今鋭意資料作成中(ヲ
あ、そうそう、今回は「一泊三日」です(マテ
(29日の夜は宿で寝て、早朝新幹線に乗って帰るという具合です。観光しようかとも考えましたが、早めに帰ってゆっくりしたいので。)
---
(※1)本当に話したくても話せない事情があるので……つーか、リアル o... rz 状態になるので、勘弁して下さい。