導入

モバイル アプリケーションの急速な開発と広範なアプリケーションにより、サードパーティ SDK がモバイル開発の重要な部分になっています。サードパーティ SDK は、豊富な機能と便利な統合方法を備えており、開発者にアプリケーション機能を迅速に開発および強化する方法を提供します。ただし、ブラックボックスの性質とサードパーティ SDK の広範な使用により、そのセキュリティが大きな注目を集めています。この記事では、モバイル APP におけるサードパーティ SDK のセキュリティ問題に焦点を当て、実際の脆弱性マイニングの事例を通じて、潜在的なセキュリティ リスクと攻撃方法を示します。

サードパーティ SDK のセキュリティ ステータス:

モバイル アプリで広く使用されているサードパーティの SDK には、セキュリティ リスクがいくつかあります。まず、サードパーティの SDK は、jar パッケージなどのライブラリの形式でアプリケーションに統合され、ブラック ボックスとして存在するため、開発者はセキュリティを監査できません。次に、SDK は広く使用されているため、SDK に脆弱性が存在すると、多くのアプリケーションに影響を及ぼします。さらに、SDK を統合すると、アプリケーションの攻撃対象領域が増加し、アプリケーションのセキュリティ リスクが増加する可能性があります。

Umeng SDK オーバーライドの脆弱性:

Umeng SDK の不正アクセスの脆弱性は 2017 年 9 月に発見されました。この脆弱性は、Umeng のメッセージ プッシュ SDK に存在しており、攻撃者はこの脆弱性を利用して、エクスポートされていないコンポーネントを許可なく呼び出すことで、影響を受ける APP のコンポーネントへの悪意のある呼び出し、任意の偽メッセージの通知、リモート コード実行などの攻撃を実行する可能性があります。約 30,000 を超える APP がこの脆弱性の影響を受け、さまざまな種類のアプリケーションを含む 7,000 を超える APP 製品がこの脆弱性の影響を受けます。

 

Baidu SDK バックドアが公開されました

2015 年 11 月にトレンドマイクロによって発見された、Baidu Moplus SDK バックドアの脆弱性。この脆弱性は Baidu Moplus SDK に存在しており、攻撃者はこの脆弱性を利用して root 化された Android デバイスにアプリケーションをサイレントにインストールし、ユーザーの機密情報を盗んだり、デバイスを制御したりする可能性があります。この脆弱性は約 1 億台の Android デバイスに影響し、数千の Android アプリが関係します。

金融サプライチェーンに関わるリスクは深刻です

中でも、Android アプリケーションのサプライチェーンにおけるサードパーティ SDK のセキュリティ リスクは、金融アプリにおいて特に深刻です。

脆弱性のマイニングと分析

基本的な考え方

 アプリケーションサンドボックス

Linux ベースの権限制御メカニズム: アプリケーションのインストール後、UID と GID が割り当てられ、UID はファイルへのアクセスを制限するために使用されます。理論上、アプリケーションは他のアプリケーションのプライベート ファイルにアクセスできません。GID はリソースへのアクセスを制限するために使用されます。アプリケーションがアクセス許可を適用すると、他の UID がアクセス許可に対応するユーザー グループに追加されます。アクセス許可と GID 間のマッピング関係は、/data/etc/platform.xml です。必要なアクセス許可は、インストール時または実行時に適用されます。システム/ユーザーなどによって制御されます。

 意図

Android の一般的な IPC フォーム: IPC メッセージ オブジェクトであり、APP コンポーネント間の通信、同じプロセス/プロセス間での通信に使用されます。

、startActivity()/startService()/bindService()/sendBroadcast()、Action または ComponentName を使用してターゲット コンポーネントを指定し、追加データを運ぶことができます (追加)

コンポーネントのセキュリティ

Android APP の基本コンポーネント: アクティビティ、ブロードキャスト レシーバー、コンテンツ プロバイダー、およびサービス。例: XML ファイルで宣言: コンポーネントは外部エクスポート/アプリケーションのプライベートとして宣言でき、アクセス許可を使用して保護できます。

コンポーネントのエクスポートのセキュリティ

コンポーネントのエクスポート: エクスポートされたコンポーネントは、android:exported=true、registerReceiver() を使用して任意のアプリケーションからアクセスできます。 android:export=false が設定されていない場合、ラベル コンポーネントはデフォルトでエクスポートされます。例：

<receiver アンドロイド:名前=”com.xxx.android.pushservice.PushServiceReceiver” android:process=”:xxservice_v1″>

<インテント・フィルター

<action android:name=”android.intent.action.BOOT_COMPLETED” />

<action android:name=”android.net.conn.CONNECTIVITY_CHANGE” />

<!– … –>

</intent-filter

</receiver>

プライベート コンポーネント: プライベート コンポーネントにはアプリケーションに依存する機能が含まれることが多く、入力データの検証が少なく、他のアプリケーションのプライベート コンポーネントへの不正アクセス (アプリケーション サンドボックス エスケープ) や重大なセキュリティ リスクが伴います。

悪用方法

SDK の脆弱性を悪用することで、悪意のあるアプリケーションは権限を必要とせず、サンドボックスの制限を回避し、アプリケーションのプライベート コンポーネントにアクセスし、悪意のある通知メッセージをプッシュし、フィッシング Web サイトへのアクセスを誘導し、SMS 検証コードを取得し、ユーザーの個人データにアクセスし、任意のコードを実行します。 、など。

この記事では、実際の脆弱性マイニングの事例をいくつか示し、サードパーティ SDK の潜在的なセキュリティ リスクと攻撃方法を示します。

押すSDKの脆弱性マイニング

SDK のプッシュはモバイル アプリケーションの一般的な機能の 1 つですが、これにはいくつかのセキュリティ ホールが存在します。プッシュ SDK の脆弱性をマイニングすることにより、攻撃者はアプリケーションのサンドボックス制限を回避し、アプリケーションのプライベート コンポーネントにアクセスし、悪意のある通知メッセージをプッシュし、ユーザーをフィッシング Web サイトにアクセスするように誘導することができます。具体的なケースとしては、市の公式地下鉄 APP に統合されているプッシュ SDK-A の脆弱性が挙げられ、攻撃者は悪意のあるプッシュ メッセージとエクスポートされたレシーバーを作成することでフィッシング通知をポップアップ表示します。

SDKをプッシュする

プッシュ SDK – A

• 公式ドキュメントでは、開発者がエクスポートされた Receiver を追加するようにガイドされています。
• エクスポートされた Receiver の特定の機能は開発者によって実装されます。
• 開発者を攻撃の入り口から離れるように「ガイド」する

。

<インテント・フィルター

のようなアクションを実行する。

<action android:name=”cn.xxxxx.android.intent.MESSAGE_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_OPENED” />

<action android:name=”cn.xxxxx.android.intent.CONNECTION” />

<category android:name=”您应用的包名” />

</intent-filter

</receiver>

この場合、都市の公式地下鉄 APP 統合プッシュ SDK です

• エクスポート受信者xxxxx顧客受信者
• xxxxxCustomerReceiver でインテントの受信データを解析し、アプリで指定された URL を開きます
• POC

市の公式地下鉄アプリが悪質なフィッシングページにアクセス

プッシュSDK – B

• エクスポートされたレシーバーを追加するようにユーザーをガイドします
• エクスポートされたReceiverはcom.xxx.android.xxxxxから継承します。.xxxBaseReceiver

<receiver android:name=”com.xxxx.xxdemo.receiver.MessageReceiver”

アンドロイド:エクスポート=”真実” >

<インテント・フィルター

を実行する。

<action android:name=”com.xxxxx.android.xxxxx.action.FEEDBACK” />

</intent-filter

</receiver>

プッシュSDK – B

xxxxx.android.xxxxx. プッシュ メッセージは xxxBaseReceiver で処理されます。配信されたメッセージは RSA によって暗号化され、アプリによってローカルで復号化されます。復号化が成功すると、ユーザーに表示されます。ただし...、暗号化がありますメソッドが SDK に含まれており、攻撃者はこの暗号化メソッドを呼び出して、偽造メッセージを暗号化できます。

XX Credit Card Manager はプッシュ SDK-B を統合し、エクスポートされたレシーバーを追加します。攻撃者は SDK の暗号化メソッドを呼び出して悪意のあるプッシュ メッセージを作成し、エクスポートされたレシーバーを使用してフィッシング通知をポップアップします。 POC:

影響範囲

共有カテゴリSDKの脆弱性掘る

共有 SDK は、モバイル アプリケーションにソーシャル共有機能を実装するためによく使用されますが、一部の共有 SDK にはセキュリティ上の脆弱性があります。たとえば、特定の共有 SDK-A にエクスポートされたアクティビティがある場合、攻撃者はアプリケーション サンドボックスの制限を回避し、プライベート アクティビティに不正にアクセスできる可能性があります。攻撃者は悪意のある入力文字列を作成することで、一般的なサービス拒否の脆弱性を引き起こし、アプリケーションをクラッシュさせる可能性があります。さらに、一部の共有 SDK では、アプリケーションのパスワード ロックがバイパスされ、ユーザーの個人データにアクセスされる場合があります。

SDKを共有 – A

SDK には、エクスポートされたアクティビティ XxShareXxXxxxxActivity があり、入力文字列をコンポーネント名として受け取り、検証なしで指定されたコンポーネントを直接開始します。悪意のあるアプリケーションは、アプリケーション サンドボックスの制限をバイパスし、プライベート アクティビティへの不正アクセスを取得する可能性があります。

XxShareXxXxxxxActivity は、インテントから受信文字列を受け取ります。検証なしで、受信文字列は ActivityName として保存され、現在のアプリケーション コンテキストで startActivity を呼び出して、ActivityName などで指定されたアクティビティを開始します。

脆弱性の悪用 – 一般的なサービス拒否: アクティビティが開始されると、パラメータを渡したり、いくつかの初期化操作を実行したり、SDK の脆弱性を悪用してエクスポートされていないアクティビティを強制的に呼び出す必要があり、不適切な例外処理によりアプリケーションのクラッシュが引き起こされます。

テスト ツールを作成し、多数のアプリケーションでバッチ テストを実行します。SDK を統合するアプリケーションの中で、90%+ にこの問題が発生します。統計によると、SDK を統合するアプリケーションの中で、90%+ にこの問題が発生します。既知の国内メーカーのアプリケーションがこの脆弱性の影響を受けます。

脆弱性の悪用 – アプリケーションのパスワード ロック バイパス: ユーザーのプライバシー データはアプリケーションに保存されます。アプリケーションに入るときは、正しいパスワードを入力する必要があります。金融および IM アプリケーションでは一般的です。この SDK の脆弱性を利用した不正アクセスには、パスワードのリセット、パスワードの設定など。アプリケーション内の機密機能コンポーネントや高特権コンポーネントは厳密に認証されず、その結果、パスワード ロックがバイパス/リセットされます。テストの結果、多くの有名なメーカーのアプリにこの問題があることが判明しました。 。

脆弱性の悪用 - 許可なくデバッグ モードをオンにする: オンラインでバグを見つけやすくするために、多くのアプリケーション リリース バージョンには、デバッグ コード、ログ スイッチの適用、オンライン サーバー アドレスのカスタマイズ、ユーザー データやその他の機密機能が含まれています... デバッグ機能は通常、 UI では利用できない 一般ユーザーが簡単にアクセスできない直観的な入り口 たとえば、デバッグ モジュールには機密性の高い操作が含まれており、本質的にバックドアのようなものです SDK の脆弱性は、アプリケーションのエクスポートされていないすべてのコンポーネントを走査し、隠されたデバッグ機能を発見するために悪用されます。たとえば、エンタープライズ レベルの IM アプリケーションでは、デバッグ機能を含むエクスポートされていないコンポーネントが複数あることがわかりました。逆分析の結果、UI 上にデバッグを開始するための隠し入り口があることが判明しました。ただし、UI を通じてデバッグ コンポーネントを開始するには、パスワードを入力する必要があります: 、認証は厳密ではありません。この SDK の脆弱性は、パスワード保護をバイパスするために悪用され、許可なくデバッグ機能を有効にします。

通常のユーザー ID ログイン: SDK の脆弱性を悪用して管理者権限機能を開く、サーバーはユーザー ID の検証に厳格ではない、一部の管理者機能は権限なしで呼び出すことができるなど。

影響範囲

概要と感想：

モバイル APP のサードパーティ SDK のセキュリティ問題を真剣に受け止め、解決する必要があります。開発者は、統合されたサードパーティ SDK を監査して、そのセキュリティと信頼性を確保する必要があります。同時に、開発者は、モバイル アプリのサードパーティ SDK のセキュリティを向上させるために次の措置を講じることをお勧めします。

1. 信頼できるサードパーティ SDK サプライヤーを選択する: サードパーティ SDK を選択して統合する前に、開発者はサプライヤーを十分に調査および評価し、良い評判とセキュリティ記録を持つサプライヤーを選択する必要があります。

2. SDK バージョンを定期的に更新およびアップグレードする: サードパーティ SDK ベンダーは通常、既知のセキュリティ脆弱性に対処するために更新をリリースし、バージョンを修正します。開発者は、アプリケーションのセキュリティを確保するために、統合 SDK を速やかに更新およびアップグレードする必要があります。

3. セキュリティ監査と脆弱性マイニングの実施: 開発者は、セキュリティ監査と脆弱性マイニングを通じて、サードパーティ SDK の潜在的なセキュリティ脆弱性を検出できます。これにより、これらの脆弱性を早期に検出して修復できるようになり、アプリケーションのセキュリティが向上します。

4. SDK の権限とアクセス範囲を制限する: サードパーティの SDK を統合する場合、開発者はその権限を確認し、必要な権限のみを付与する必要があります。さらに、潜在的なセキュリティ リスクを軽減するために、アプリのプライベート コンポーネントへの SDK のアクセスを制限します。

5. ユーザーの機密データの保護を強化する: サードパーティの SDK を使用する場合、開発者はユーザーの機密データの保護に注意を払う必要があります。ユーザーデータのセキュリティを確保するために、暗号化、認証、その他の措置を講じることができます。

最後に、モバイル APP におけるサードパーティ SDK のセキュリティ問題は重要な問題です。開発者とセキュリティ研究者は、サードパーティ SDK のセキュリティ監査と脆弱性マイニングに細心の注意を払い、強化する必要があります。共同の取り組みを通じてのみ、モバイル APP の全体的なセキュリティを向上させ、ユーザーのプライバシーとプライバシーを向上させることができます。データセキュリティ。