Video Screencast Help
Security Response

Android における埋め込みマルウェアの不明瞭化

Created: 28 Jun 2012 06:25:56 GMT • Translations available: English
Costin Ionescu's picture
0 0 Votes
Login to vote

Android マルウェアはこの数年間、確実に急速な進化を遂げています。多くの点で PC ベースのマルウェアと同様の足跡をたどっていますが、加速するペースはその比ではありません。

多くの場合、悪質なアプリは何種類かのモジュールを使って複数のステップでシステムの制御権を奪います。初期モジュールは 1 つしかないのが一般的で、それが実行されると埋め込みモジュールを投下するか、他のモジュールをダウンロードしてインストールし、その時点で一連の悪質な行為を最初から最後まで実行するようになります。

Android プラットフォームでは、パッケージをインストールするとき、特にサイドローディング(たとえば、パッケージを手動でインストールする場合や、非公式のアプリマーケットからインストールする場合)するときの可視性が限られています。他のマルウェアを含む Android マルウェアの多くは、そこを狙って、未加工のリソースとして、または独自パッケージの資産としてペイロードを追加するだけという最も単純な形で埋め込みを行っています。

かつて PC ベースのマルウェアでも、これは同様でした。単純なトロイの木馬プログラム(「ドロッパー」とも言います)が他の悪質な実行可能ファイルをリソースとして添付するか、メインの実行可能ファイルに付加するだけだったのです。ただし、このプロセスはすぐに変わり、マルウェア作成者は暗号化によって埋め込みモジュールを不明瞭化するようになりました。その目的は、セキュリティ製品による検出や発見を遅らせることです。

Android マルウェアにも今、同じことが起きつつあるようです。

たとえば Android.Gamex は、assets/logos.png にパッケージを隠すために、ごく簡単な暗号化(0x12 によるバイト XOR)を使っています。

このファイルの暗号化されたブロックを以下に示します。
 


 

このブロックを復号すると、以下のようになります。
 


 

データを復号する実際のコードは、ごく簡単なものです。
 


 

標準の Android API では強力な暗号化機能を使えるので、これは同じくらい実装の簡単なオプションとして不明瞭化に利用できます。たとえば Android.Pris は、DES 暗号化を使ってそのペイロードを assets/config1 に隠します。

復号コードがどうなっているかは、次の画像からわかります。
 


 

先に挙げた XOR 復号より複雑なのは間違いありませんが、それでも非常に簡単なコーディングではるかに強力な暗号化が実現されています。上の例では、19821208 という秘密鍵で DES 復号が使われていることがわかります。特に強力な鍵というわけではありませんが、必要な機能は果たしています。実際にはなんらかの日付のようですが、作成者の生年月日でも、可愛がっていたペットの死んだ日でも、鍵は何でもかまいません。

このマルウェアは、ダウンロードされるパッケージにも、コマンド & コントロール(C&C)サーバーのトラフィックにも、同じ復号方式を使っています。このマルウェアのコードは Android.Jsmshider の一部のドロッパーに再利用されていますが、奇妙なことに、埋め込まれるパッケージが DES で暗号化されている一方、Android.Jsmshider のパッケージは暗号化されていない未加工のリソースとして格納されています。まるで、作成者が締め切りを守るために工程をはしょったかのようです。

現在のモバイル向けプロセッサは、業界標準の暗号化に対応できる十分な処理能力を持っており、その強力な暗号化方式がオペレーティング環境の標準コンポーネントになっています。モバイルマルウェアが暗号化コンポーネントと連携する傾向が予測されるのも当然かもしれません。ノートン モバイルセキュリティはこのような手口に欺かれることなく、脅威を検出します。

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。