Androidのパペット

Androidプラットフォーム用の悪意のあるアプリケーションに関するニュースは、Googleがすべてのデバイスから不要なソフトウェアを一度にリモートで削除するメカニズムに言及しています。 このシステムはどのように機能し、malvariの最大の流通チャネルにならないのでしょうか？


統計から始めます。 最初のAndroidベースのデバイスであるHTC Dream / G1は、2008年10月に米国と英国で発売されました。 プラットフォームの急速な普及の始まりは、2009年11月のMotorola Droidスマートフォンの出現に関連しています。 それ以来、毎日アクティブ化されるデバイスの数は驚異的に増加しています。 前回のGoogle I / Oカンファレンスでは、毎日40万回のアクティベーションというすばらしい数字が発表されました。 考えてみてください。これはキプロスの人口の半分、例えばブルネイ全体です。 現在、合計で1億台以上のAndroidデバイスがアクティブ化されています。 悪くない。 ここで、それぞれがGoogleで少なくとも少しはできるが、管理できると想像してください。 おそらく私は少し誇張していて、ここでは「管理」という言葉は最も適切ではありません。 GoogleがGTalkServiceメカニズムを介して任意のアプリケーションをインストールおよび削除できることは確実に知られています。 これを新しいデバイスのアクティベーションに関する印象的な統計と組み合わせることで、数十万人のユーザーが自発的にログインする世界最大のボットネットを思いっきり考えます。 アイデアは空想科学小説のように見えますが、GTalkServiceメカニズムの内部を理解することに興味がありました。 どのように配置されていますか？ サーバーからのメッセージはどのような形でデバイスに届きますか？ 伝送チャネルはどのくらい安全ですか？ 他の誰かが私のデバイスに制御コマンドを含むメッセージを送信できる危険はありますか？

Googleによって削除されたアプリ

GTalkServiceがすべてです

すべてのAndroidデバイスは、GTalkサーバーとの一定のTCP / SSL / XMPP接続をサポートしています。 彼は常にネットワークにアクセスできます。 接続は、特別なGTalkSeriveサービスによって制御されます。 接続がアクティブかどうかを確認するために、常にping（いわゆる「ハートビートメッセージ」）をGoogleのサーバーに送信し、接続が失われた場合、自動的に再接続します。 この通信チャネルにより、Googleはデバイスをリモートで制御できます。 GTalkServiceを介して送信されたメッセージは、確実にすべてのスマートフォンに届きます。 このメカニズムにより、C2DMサービス（デバイスメッセージングフレームワークへのクラウド）の一部が機能し、開発者はユーザーのスマートフォンにインストールされたアプリケーションに特別なコマンドを送信できます（更新のダウンロードなど）。 ただし、C2DMは特別なリクエストを残した一部の開発者のみが利用できます。 Androidは少なくとも2つのコマンドをサポートすることが知られています：REMOVE_ASSETおよびINSTALL_ASSET。これにより、Googleは任意のアプリケーションを削除およびインストールできます。 したがって、Androidマーケットでマルウェアを発見すると、同社のエンジニアはGTalkServiceを介してREMOVE_ASSETメッセージを送信でき、悪意のあるプログラムはインターネットに接続されているすべてのデバイスからすぐに削除されます。 これは、ニュースからわかるように、会社はそれを複数回使用しています。 そして逆の状況。 GoogleがINSTALL_ASSETコマンドを発行するとすぐに、メッセージを受信した各AndroidスマートフォンがプログラムとともにAPK配布キットをダウンロードし、インストールします。 この可能性は良い一方で、Googleはすべての新興マルウェアを迅速に削除できます。 しかし、一方で、それは怖いです。 しかし、誰かが特定の電話のGTalkServiceへのSSL接続にMITM攻撃を実装し、INSTALL_ASSETメッセージを偽装して電話のある種の感染を埋めることができたらどうでしょうか？ システムは安全ですか？

データチャネルの信頼性

Googleインフラストラクチャをキャプチャするオプションについては考慮しません。理論的には、任意のアプリケーションをすべてのAndroidデバイスにすぐにダウンロードできます。 この段階では、これをファンタジーと見なします。 しかし、より現実的に思われるのは、特定のデバイスに偽のコマンドを送信することです。 はい、上で述べたように、GTalkService接続は安全です。すべてのデータはSSLを介して送信されます。 したがって、メッセージの基本的なセキュリティと整合性はプロトコル自体によって保証されます。 ただし、これらの保証の価格は知っています（ 「Uncover SSL 」の資料をお読みください）。 必要に応じて、デバイスとGoogleサーバー間で送信されるパケットのSSL接続が危険にさらされたり、傍受されたり、逆にされたりする可能性があります。 それらの構造を理解し、INSTALL_ASSETメッセージを正しく偽造した場合、デバイスに任意のアプリケーションを強制的にインストールできます。 理論的に。 問題は、たとえばデジタル署名など、他の保護レベルはありますか？ Googleからのメッセージを調査するには、受信する必要があります。 スニファーをオンにし、会社のエンジニアがGTalkServiceを介してINSTALL_ASSETコマンドを再度送信するのを待つ必要があると思うかもしれません。 しかし、いつになるのでしょうか？ 実際、すべてがよりシンプルです。 今後、ユーザーがAndroidマーケットからメッセージをインストールするたびに、この同じサービスが使用されると言います。 [インストール]ボタンを押すと、GTalkServiceを介してINSTALL_ASSETが送信され、プログラムの目的のAPKパッケージをダウンロードしてデバイスにインストールするプロセスが開始されます。 これについては詳しく説明しますが、重要なことは、調査のためにINSTALL_ASSETメッセージを受信することは問題ではないということです。 一般に、トラフィックを表示するには（SSL接続を介して送信されるという事実にもかかわらず）、ほとんど必要ありません。

1. Androidエミュレーターのイメージを取得します。これには、Androidマーケットと連携する機能が含まれています。
2. keytoolまたはportecleを使用して、CA証明書を/system/etc/security/cacerts.bkリポジトリに追加します。
3. CA証明書でsslsnifを使用してMITM攻撃を実装します。

GTalkServiceが接続を確立したいので、デバイスが作成したCA証明書を信頼するため、トラフィックを傍受できます。 エミュレータにAndroidマーケットからアプリケーションをインストールしようとすると、それに応じてINSTALL_ASSETメッセージがアンインストールされます。 次のようになります。

tickle_id: 1277687266074
assetid: -155863831473120556
asset_name: Replica Island
asset_type: GAME
asset_package: com.replica.replicaisland
asset_blob_url: android.clients.google.com/market/download/Download?assetId=-155863831473120556&userId=986032118775&deviceId=1094117203906638597
asset_signature: Ayn2bWDqckQkKsBY4JurvCFpYN0
asset_size: 5144485

ほとんどのパラメーターは、ユーザーがAndroidマーケットに要求したアプリケーションを記述しています。 興味深いのはasset_signature属性です。 これはINSTALL_ASSETメッセージの暗号署名であり、その整合性がさらに保証されていると想定できます。 悲しいかな、これはそうではありません。 これは、ユーザーがAndroidマーケットからリクエストしたAPKファイル（つまり、プログラム配布キット）のbase64エンコードハッシュにすぎないことは、愛好家によって長い間確立されてきました。 今回は、APKパッケージをダウンロードし、チェックサムを使用して適切な変換を実行することによってのみ確認できます。 INSTALL_ASSETメッセージ（およびその他のメッセージ）に対する追加の保護がないことが明らかになります。 攻撃者がGTalkService間のSSL接続を傍受できる場合、理論的には、アプリケーションのインストールを含む、任意のメッセージを電話に送信できます。 もちろん、多くの「しかし」があり、そのような攻撃を想像するのはかなり困難です。 これを行うには、少なくとも、MITM攻撃を実装できるようにするために、被害者と同じネットワーク上にいる必要があります。 ユーザーの大量感染については疑いようがありません。 これは、通信チャネルのセキュリティの欠如を損なうものではありませんが、ここでの欠陥を悪用する見込みは、率直に言って弱いです。 したがって、これについてはもう説明しませんが、AndroidプラットフォームとGTalkServiceメカニズムには他にどんな驚きがあるのか​​見てみましょう。

GTalk Service Monitorインターフェイス

Androidマーケットとの相互作用

GTalkServiceは、Androidマーケットからアプリケーションをインストールするプロセスに関与していると上記で述べました。 これは一般的に興味深い話です。 ここには興味深いニュアンスもあります。 まず、ユーザーが市場からプログラムをインストールする手順を検討します。

1. Androidマーケットを起動します。
2. インストールする目的のアプリケーションを検索します。
3. 「インストール」ボタンをクリックします。
4. アプリケーションに必要な特権の確認。
5. アプリケーションをダウンロードしてインストールします。

その後、通知パネルのユーザーは、アプリケーションのダウンロードとインストールに関するメッセージを表示します。 すべてがシンプルで透明ですが、...プロセスを内側から見ると、すべてが少し複雑になります。 最初の4つのステップがAndroidマーケットアプリケーションによって実行される場合、5番目の（最も重要な）ステージでは、システムの完全に異なるコンポーネント、つまり、すでにおなじみのGTalkServiceが責任を負います。 作業のスキーム（理解を深めるために図を参照）は次のとおりです。

1. ユーザーは、Androidマーケットのアプリインストールボタンをクリックします。
2. アプリケーションはAndroidマーケットサーバーにPOSTリクエストを送信します。
3. Androidマーケットサーバーは、アプリケーションをC2DMシステムにインストールするリクエストに関する情報を送信します。
4. C2DMサーバーは、GTalkService接続を介してINSTALL_ASSETメッセージをユーザーのスマートフォンに送信します。
5. GTalkServiceコンポーネントはINSTALL_ASSETメッセージを受信し、Vendingコンポーネントをアクティブ化します。
6. Vendingコンポーネントは、アプリケーションのAPKパッケージをダウンロードし、最終的にアプリケーションをインストールします。

関心を引く最初のものは、もちろん、サーバーに送信されるPOST要求です。 Androidマーケットが送信できるので、おそらく特別なアプリケーションを使用して送信できますか？ それを理解してみましょう。
インターセプトされたリクエストは次のとおりです。

POST /market/api/ApiRequest HTTP/1.1
Content-Length: 524
Content-Type: application/x-www-form-urlencoded
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: Android-Market/2 (dream DRC83); gzip
version=2&request=CuACCvYBRFFBQUFLOEFBQUJvZWVEVGo4eGV4OVRJaW9 . . .

興味深いのは明らかで隠れているリクエストパラメータを除いて、すべてはささいなものです。 Googleを知っていれば、これはpropobuf独自の構造にパッケージ化され、その後base64でエンコードされたデータであると簡単に推測できます。 そうです。 ハッシュをデコードし、構造をアンパックすると、リクエストデータが取得されます。

1 {
1: "DQAAAK8AAABoeeDTj8xex9TIio . . ."
2: 0
[... ...]
13: "-606db3000d480d63"
}
2 {
10 {
1: "353999319718585473"
}
}

protobufからデコードした後のリクエスト構造

すでに何かですが、問題があります。このパラメーターまたはそのパラメーターが何を担当しているかはわかりません。 ほとんどの場合、これらはデバイスの識別子、プラットフォームに関する情報、承認のための情報、そしてもちろん、マーケットから要求されたアプリケーションの識別子です。 ここでは、Androidマーケットでの作業に参加する多くのプロトブフ構造について、逆転の結果としてマニアが作成した説明が利用可能であると言わなければなりません。 また、サイトcode.google.com/p/android-market-apiには、市場からさまざまなデータ（説明、プログラムアイコンなど）を要求できるようにまとめて記述されたAPIが掲載されています。 確かに、アプリケーションのインストール要求の構造に関するデータはありません。 しかし、逆転は有名なAndroidプラットフォームの研究者であるJohn Oberheidによって行われました。JohnOberheidは、興味深い攻撃を実装しました。 したがって、短縮形のリクエストの構造は次のようになります。

[.. ..]
message InstallRequest {
optional string appId = 1;
}
message RequestContext {
required string authToken = 1;
[.. ..]
required string androidId = 4;
optional string deviceAndSdkVersion = 5;
[.. ..]

要求からのフィールドのほとんどは、デバイス自体から抽出できます（たとえば、インターフェース言語、システムバージョンなど）。 ただし、appIdパラメーターとauthTokenパラメーターではありません。

• appId-Androidマーケットの一意のアプリケーション識別子です。 この識別子はどこにも表示されないため、取得する唯一の方法は、Androidマーケットからアプリケーションをリクエストし、protobuf構造から識別子を取得してトラフィックを取得することです。
• authTokenはClientLoginシステムのトークンであり、Android Marketサーバーはこれを使用してリクエストを認証できます。

authTokenがシークレットのままである場合、リクエストはスプールされません。 しかし、あなたは、デバイスがそれを持っているので、それがまだシステムのある場所に格納されていることを意味することに気付くことができます。 まさに！ このストレージはアカウントマネージャーと呼ばれ、認証データを提供するAndroidプラットフォームの重要なコンポーネントです。 たとえば、一部のアプリケーションがメッセージをTwitterに投稿する場合、Twitterアカウントのユーザー名とパスワードを知る必要はありません。AcountManagerからトークンを要求して、ツイートを送信できます。 そのため、authTokenも同じ場所に格納され、Android Marketサーバーとのやり取りに使用されます。 しかし、このストーリー全体で最も面白いのは、わずか数行のコードで抽出できることです。

AccountManager accountManager = AccountManager.get(getApplicationContext());
Account acct = getAccount(accountManager);
accountManager.getAuthToken(acct, "android", false, new GetAuthTokenCallback(), null);

これはどういう意味ですか？ 上で引用したprotobuf構造をコンパイルし、Androidマーケットサーバーに送信するためのPOSTリクエストを作成するためのすべてのデータがあることがわかりました。 リクエストが正しい場合（それが正しいことを確認します）、メッセージINSTALL_ASSETがGTalkServiceを介してデバイスに送信され、指定したアプリケーションのインストールにつながります！ また、システムはユーザーがリクエストを送信する前にインストールを許可するように設計されているため（再び図を参照）、誰も彼に何も尋ねません。 そして、アプリケーションは必要なすべての権限でシステムにインストールされます！

アプリを介した攻撃

Androidマーケットのアプリケーションインストールメカニズムの微妙な点を理解したので、John Oberheidがなんとか成功させたエレガントな攻撃について話をすることができます。 アイデアはこれです。 インストール要求を自分で作成できる場合、これを自動的に行うアプリケーションを作成することを妨げるものは何もありません。 このような機能を完全に無害なプログラムに追加し、Androidマーケット（これは簡単に制御できません）を通じて配布を開始すると、それをインストールするすべてのユーザーに好きなものをダウンロードできます！ すぐに言ってやった。 JohnはPoCアプリケーションを作成し、Angry Birds Bonus Levelsという名前を付けました。これは、Androidマーケットユーザーの注目を集めることになっています。 最も簡単なソーシャルエンジニアリングが機能しました。ユーザーはプログラムのインストールを開始しました。 最も気がついたのはおそらく、更新エリアにさらに3つのプログラムのインストールに関するメッセージがあることに気付いたということです。場所を追跡し、有料番号に電話をかけ、連絡先リストを盗むことです。 それらのすべてに実際に悪意のある機能がありましたが、決して使用されませんでした。 私は、PoCをテストした直後に研究者がGoogleで問題を報告し、同社がすでにバグを修正していると言わなければなりません。 ところで、解決策は非常に簡単であることが判明しました。 システムは、Androidマーケットを介して行われたアプリケーションのインストール要求をすべて記録し、着信INSTALL_ASSETメッセージに対して対応する要求が以前に行われたことを確認します。 Vendingコンポーネントが予期しないアプリケーションのINSTALL_ASSETメッセージを受信した場合、コマンドは単に無視されます。 これ以上の問題はないと思われます。 しかし！ メッセージの本文には、チェックを切り取ることができる特別なフラグが含まれている場合があります（アプリケーションのリモート削除の機能を維持することを含む）が、これは少し異なる話です。

この記事は、研究者John Oberheidによる資料に基づいて作成されました 。


ハッカーマガジン、 7月（07）150

ハッカーを購読する

• 1 999 p。 12枚の用紙オプション用
• 1249 RUR iOS / iPadの年間サブスクリプション（Androidリリースは近日公開予定！）
• Androidのハッカー