Qualcomm デバイスでの CVE-2016-2060 の悪用

Mandiant の Red Team は最近、Android デバイスに影響を与える広範な脆弱性を発見しました。この脆弱性により、攻撃者は被害者の SMS データベースや電話履歴の表示などのアクティビティを実行できる可能性があります。この脆弱性は、Code Aurora Forum から入手できる Qualcomm が管理するソフトウェア パッケージに存在します。これは Code Aurora Forum で CVE-2016-2060 およびセキュリティ アドバイザリ QCIR-2016-00001-1として公開されています。一般的な詳細は FAQ に記載されており、脆弱性の技術的な分析は次のとおりです。

よくある質問

CVE-2016-2060 とは何ですか?

CVE-2016-2060 は、Android オープン ソース プロジェクト (AOSP) の一部であるデーモンである “netd” デーモンの “interface” パラメータの入力サニタイズの欠如です。この脆弱性は、Qualcomm が「network_manager」システム サービスの一部として新しい API を提供し、続いて「netd」デーモンを提供したときに導入されました。これにより、テザリング機能が追加される可能性があります。クアルコムは「netd」デーモンを変更しました。

影響を受けるデバイスの数は?

確かな答えはありません。多くのフラグシップおよび非フラグシップ デバイスが Qualcomm チップおよび/または Qualcomm コードを使用しているため、過去 5 年間で数百のモデルが影響を受ける可能性があります。いくつかの API 番号を提供するために、Android Gingerbread (2.3.x) が 2011 年にリリースされました。この脆弱性は、Lollipop (5.0)、KitKat (4.4)、および Jellybean MR2 (4.3) を実行しているデバイスで確認され、投稿で参照されている Git コミットIce Cream Sandwich MR1 (4.0.3) です。

問題はどのように対処されていますか？

Qualcomm は、「netd」デーモンにパッチを適用することでこの問題に対処しました。 Qualcomm は、2016 年 3 月上旬に顧客 (すべての OEM) に通知しました。OEM は、デバイスの更新プログラムを提供する必要があります。ただし、多くのデバイスにはパッチが適用されない可能性があります。

FireEye は 2016 年 1 月に Qualcomm に連絡を取り、その後、Qualcomm 製品セキュリティ チームと協力して、このブログ リリースとセキュリティ アドバイザリを調整しました。 FireEye から連絡を受けたとき、Qualcomm はプロセス全体を通して非常に迅速に対応してくれました。彼らは 90 日以内に問題を修正しました。FireEye ではなく、彼らが設定したウィンドウです。 FireEye は、クアルコムが情報開示に協力し、問題への対応に尽力してくれたことに感謝します。

Google は、この問題を2016 年 5 月の Android Security Bulletinに含めました。

攻撃者はこの脆弱性をどのように悪用しますか?

この脆弱性を悪用するには 2 つの方法がありますが、これは、追加の脆弱性を保有する断固たる攻撃者の説明にはなりません。 1 つ目は、ロックされていないデバイスに物理的にアクセスすることであり、2 つ目は、ユーザーに悪意のあるアプリケーションをデバイスにインストールさせることです。

どのアプリケーションも、アラートをトリガーすることなく、この API と対話できます。 Google Play はおそらく悪意のあるものとしてフラグを立てず、FireEye Mobile Threat Prevention (MTP) は最初にそれを検出しませんでした。アンチウイルスがこの脅威にフラグを立てるとは信じがたいです。さらに、これを実行するために必要なアクセス許可は、何百万ものアプリケーションによって要求されるため、何かが間違っていることをユーザーに通知することはありません.

この脆弱性の悪用に成功した場合、攻撃者は何ができるでしょうか?

古いデバイスでは、悪意のあるアプリケーションが SMS データベースと通話データベースを抽出し、インターネットにアクセスし、「ラジオ」ユーザーが許可するその他の機能を実行できます。 「ラジオ」ユーザーの潜在的な機能の例がブログ自体に示されていますが、これらすべてをテストすることは困難でした。

新しいデバイスはそれほど影響を受けません。悪意のあるアプリケーションは、オペレーティング システムによって維持される追加のシステム プロパティを変更できます。ここでの影響は、OEM がシステム プロパティ サブシステムをどのように使用しているかに完全に依存します。

脆弱性が悪用されると、何かが起こったという兆候がユーザーに表示されないことに注意してください。たとえば、パフォーマンスへの影響やデバイスのクラッシュのリスクはありません。

影響を受けるのは Android デバイスだけですか?

これは Qualcomm が開発し、自由に利用できるオープンソース ソフトウェア パッケージであるため、人々は Cyanogenmod (Android のフォーク) を含むさまざまなプロジェクトにコードを使用しています。脆弱な API は2011 年から Git リポジトリで観察されており、その時点で誰かがこのコードを使用していたことを示しています。これにより、影響を受けるすべてのデバイスにパッチを適用することが、不可能ではないにしても、特に困難になります。

この脆弱性は積極的に標的にされたり悪用されたりしていますか?

いいえ。MTP チームはこの API の使用状況を監視していますが、何も発見していません。

FireEyeの顧客は保護されていますか?

FireEye MTP のお客様は、この脆弱性の悪用の試みを検出できます。

テクニカル分析

次に、CVE-2016-2060 をさらに深く掘り下げ、攻撃者が脆弱性を悪用する方法を示しますが、最初に Android システム サービスについて紹介します。

システム サービスについて

システム サービスは、Android アプリケーションに見られる通常のバインドされたサービスに似ていますが、システム サービスは通常、「mediaserver」や「system_server」などの特権プロセスで実行されます。これらのサービスは Android のコアであり、現在、Android Marshmallow のデフォルト エミュレータ ビルドには 99 のシステム サービスが登録されています。デバイスで USB デバッグが有効になっている場合、「サービス」ユーティリティを使用して、デバイスに登録されているシステム サービスを一覧表示できます (図 1 参照)。

システム サービスが Android デバイスでどのように機能するかを説明するために、Android アプリケーションからテキスト メッセージ (SMS) を送信するプロセスについて説明します。図 2 は、「Test」という内容の SMS メッセージを番号 1234567890 に送信するために使用できる Java スニペットを示しています。

このコードは、最初に静的メソッド「getDefault()」を使用してデフォルトのサブスクリプション ID に関連付けられた SmsManager オブジェクトを取得し、次に適切な引数を指定してメソッド「sendTextMessage(..)」を呼び出します。SmsManager クラスには、「downloadMultimediaMessage(..)」や「sendMultipartTextMessage(..)」などの他の SMS 関連メソッドが含まれています。

次に、前に使用した SmsManager クラスの「sendTextMessage(..)」メソッドのJava ソースを見ていきます。わかりやすくするために、Android 4.4 (「KitKat」) の一部として含まれている SmsManager クラスのソースを図 3 に示します。

このメソッドは 2 つの機能を実行します。最初に基本的な引数チェックを実行し、次に「isms」と呼ばれるシステム サービスとの対話を試みます。 ServiceManager クラスの「getService(..)」メソッドで IBinder オブジェクトを取得し、「asInterface(..)」メソッドで ISms オブジェクトにキャストします。この時点で、 Binder インターフェイスを使用して「isms」システム サービスからメソッドを呼び出すことができます。この場合、メソッドは「sendText(..)」です。 Android SDK を使用するアプリケーション開発者は ServiceManager クラスを使用できないことに注意してください。これは、SmsManager クラスが単に「isms」システム サービスのラッパーであることを示しており、この特定のパターンは、位置情報やテレフォニーなどの他の多くの API で一貫しています。

システム サービスを直接呼び出す

Google は公式 API をバイパスしてシステム サービスと直接やり取りすることを推奨していませんが、可能です。アプリケーションでこれを行うには、開発者は非標準 API (つまり、前述の ServiceManager クラス) をインポートして使用する必要があります。別の方法として、前述の「サービス」ユーティリティをコマンド ラインから使用できます。 `service` ユーティリティを利用するには、追加の情報を収集する必要があります: 呼び出したいメソッドのトランザクション ID と引数に関する情報です。

トランザクション ID の取得

Android アプリケーションでバインドされた Service を作成するときの最初のステップは、 Android Interface Definition Language (AIDL)を使用してサービス インターフェイスを定義することです。アプリケーションのビルド プロセス中に AIDL ファイルが「aidl」ユーティリティによってコンパイルされると、インターフェイスの各メソッドの一意の識別子が「スタブ」内部クラスの静的フィールドの形式で格納されます。開発者は、これらのトランザクション ID ではなくメソッド名に依存します。API ビルド間およびベンダー間で変更されるためです。

前の SMS の例でこれを説明するために、クラス「com.android.internal.telephony.Isms.Stub」を調べます。これは通常、デバイスのシステム JAR ファイル「/system/framework/framework.jar」にあります。この JAR を逆アセンブルすることで、メソッド「sendText()」のトランザクション ID を特定できます。これは、図 4 に示すように、このデバイスでは 16 進数で 0xb または 10 進数で 11 です。

メソッド引数の決定

トランザクション ID を理解したので、メソッドと対話する方法を決定する必要があります。対象のシステム サービスが「isms」サービスのように公開されている場合は、AIDL ソースを確認できます。そうでない場合は、各引数の目的を判別するために、サービスの実装を逆にする必要があります。前述の「framework.jar」に含まれる内部クラス「com.android.internal.telephony.Isms.Stub.Proxy」を逆アセンブルすると、各拡張機能が何を表しているかを把握し、リターンを決定できるはずです。タイプ。図 5 は、「sendText(..)」メソッドの引数と戻り値を示しています。

上のスクリーンショットでは、「sendText(..)」メソッドが「pn」表記で示される 6 つの引数を取り、メソッド プロトタイプの末尾の「V」で示されるように void を返すことがわかります。

すべてを一緒に入れて

これで、`service` ユーティリティを使用して「isms」サービスとやり取りし、「sendText(..)」メソッドを呼び出すことができます。図 6 は、システム サービスのメソッドを呼び出すための「service」ユーティリティの構文を示しています。

「サービス」ユーティリティは、それぞれ「s16」、「i32」、「null」で表される文字列、整数、および null 値の引数を受け入れます。より複雑な場合は、Java アプリケーションを使用する必要があることに注意してください。これで、トランザクション ID が 11 の「isms」システム サービスの「sendText(..)」メソッドを呼び出して、メッセージを送信できるようになりました (図 7 参照)。

このコマンドは、図 2 の Java スニペットと同様に、「Test」という内容の SMS メッセージを番号 1234567890 に送信します。

CVE-2016-2060 の調査

上から

デバイス メーカーやその他の Android オープン ソース プロジェクト (AOSP) 以外のベンダーは、システム サービスを定期的に追加および変更しています。攻撃者の観点からは、システム サービスの新しい API または変更された API が主な標的です。研究者は、ターゲット デバイス上のシステム サービスの「スタブ」内部クラス内にある「TRANSACTION_」で始まる静的フィールドを AOSP のフィールドと比較することで、これらを列挙できます。そのようなレビューの中で、「android.os.INetworkManagementService.Stub」にある「network_management」システム サービスに「addUpstreamV6Interface(..)」と「removeUpstreamV6Interface(..)」という 2 つのメソッドが追加されていることを発見しました。システム JAR「/system/framework/framework.jar」。これを図 8 と図 9 に示します。

「addUpstreamV6Interface(..)」メソッドは、1 つの文字列引数 interface_value を受け入れ、void を返します。システム JAR「/system/framework/services.jar」にあるクラス「com.android.server.NetworkManagementService」の逆アセンブルされたメソッド「addUpstreamV6Interface(..)」を表示すると、呼び出されたときにメソッドが interface_value をネイティブに渡したことが示されました。図 10 に示す文字列を UNIX ソケット「/dev/socket/netd」に書き込むことにより、デーモン「netd」に接続します。

ここから「/system/bin/netd」を分析すると、このデーモンは「execv(..)」関数を使用して「/system/bin/radish」を実行し、図 11 に示すシェル コマンドを実行することがわかりました。

次に、「/system/bin/radish」実行可能ファイルは、「system(..)」関数を使用して、interface_value を `brctl` ユーティリティに渡しました (図 12 に示す構文を使用)。

この時点で、CVE-2016-2060 のコード実行機能が確認されます。「addUpstreamV6Interface(..)」に渡された値は、サニタイズまたは検証されることなく、最終的に「system()」関数に渡されます。この簡単な例は、図 13 に示す「service」コマンドで実現できます。このコマンドは、「id」コマンドの出力を Android ログ バッファに出力します。

このコマンドは、”’fake の interface_value を渡します。 log -t radio_exe “`id`””” を実行可能ファイル「/system/bin/radish」に追加すると、図 14 に示す文字列で「system()」関数が呼び出されます。

図 15 に示すように、 「logcat」ユーティリティを使用して、Android のログ バッファをチェックし、挿入されたコマンドの出力をキャプチャできます。

「id」コマンドの出力は、Linux UID 1001 (「radio」) として、「netd」の SEAndroid コンテキストで実行していることを示しています。次に、攻撃者がこの脆弱性を利用する方法と、これにより攻撃者が許可されるアクションを調べます。

実用的な搾取

CVE-2016-2060 を悪用する最も現実的な方法は、悪意のあるアプリケーションを作成することです。悪意のあるアプリケーションは、広く要求されている「ACCESS_NETWORK_STATE」権限へのアクセスを要求するだけで済みます。図 16 は、「addUpstreamV6Interface(..)」メソッドを使用してコマンド「id」を挿入する方法を示しています。

上記のコマンドはユーザー「radio」として実行されるため、「radio」としても実行されているアプリケーションが所有するデータが悪意のあるアプリケーションからアクセス可能になります。標準の Android デバイスでは、これにはPhone アプリケーションとTelephony Providers アプリケーションが含まれ、どちらにも機密情報が含まれています。また、「radio」ユーザーは、サードパーティ アプリケーションがアクセスできないいくつかのシステム権限を継承します。短いリストは次のとおりです。

• WRITE_SETTINGS_SECURE – 主要なシステム設定を変更する
• BLUETOOTH_ADMIN – Bluetooth デバイスの検出とペアリング
• WRITE_APN_SETTINGS – APN 設定の変更
• DISABLE_KEYGUARD – キーガード (ロック画面) を無効にします

攻撃者がこれらのアクセス許可を悪用できるかどうかは、特定のモデルに依存し、すべてのデバイスで可能であるとは限りません。

SEAndroid に関する考慮事項

Android 4.4 (「KitKat」) 以降、デバイスは Security Enhancements for Android™ (SEAndroid) を利用し、デフォルトで強制モードを設定します。このモードで SEAndroid を実行しているデバイスは、古いデバイスほど大きな影響を受けません。 「/system/bin/radish」実行可能ファイルが実行される「netd」コンテキストには、他の「radish」ユーザー アプリケーション データとやり取りする機能がなく、ファイルシステムの書き込み機能が制限されており、通常はアプリケーションのやり取りに関して制限されています。 「netd」コンテキストには、「service.」、「persist.sys.」、「persist.service.」、および「persist.security」を含む Android プロパティ サブシステムの「system_prop」プロパティを変更する機能があります。プロパティ キー。特定のデバイス メーカーがこれらのプロパティをどのように利用しているかによっては、これらのプロパティを変更することでデバイスをさらに危険にさらす可能性があります。

結論

CVE-2016-2060 は、少なくとも 2011 年からデバイスに存在しており、世界中の何百もの Android モデルに影響を与える可能性があります。この脆弱性により、一見無害なアプリケーションが SMS や通話履歴などの機密性の高いユーザー データにアクセスし、システム設定の変更やロック画面の無効化など機密性の高い操作を実行できるようになります。 Android 4.3 (「Jellybean MR2」) 以前を実行しているデバイスは、脆弱性の影響を最も受けやすく、パッチが適用されていない可能性があります。 SEAndroid を使用する新しいデバイスは依然として影響を受けますが、程度は低くなります。

FireEye は、CVE-2016-2060 に対処するために熱心に取り組み、このブログ投稿のリリースをサポートしてくれた Qualcomm に感謝します。 FireEye Mobile Threat Prevention (MTP) のお客様向けに、FireEye は、このブログ投稿の執筆時点で、デバイスでの CVE-2016-2060 エクスプロイトの検出を追加しました。