2015年3月24日に米国で掲載されたブログ記事の抄訳です。

概要

パロアルトネットワークスは、GoogleのAndroid OSの脆弱性「Android Installer Hijacking」を発見しました。 これにより、現在のAndroidユーザーの49.5%が影響を受ける可能性があります。

詳細

• 攻撃者が「Android Installer Hijacking」(Androidインストーラー乗っ取り)の脆弱性を利用すると、ユーザーがインストールした問題のないAndroidアプリをユーザーの知らない間にマルウェアに置き換えることが可能です。
• これで影響を受けるのはサードパーティのアプリ ストアからアプリをダウンロードした場合のみです。
• 悪意のあるアプリは、ユーザー名、パスワードなどの機密性の高いデータを含め、感染したデバイスにフル アクセスできるようになります。
• パロアルトネットワークスでは、Google、Samsung、Amazonなどの大手企業と連携して脆弱性についての通知と各デバイスに対するパッチの発行を行いました。

背景

2014年1月、パロアルトネットワークスはAndroid OSのTime-of-Check to Time-of-Use (TOCTTOU) 脆弱性を発見しました。攻撃者がこれを利用すると、通常のAPKインストール プロセスを乗っ取ることが可能になります。この乗っ取りテクニックは、ユーザー ビューを回避して、恣意的なアクセス許可を求めるマルウェアを配布します。そして普通のアプリを別のアプリに置き換えます。たとえば、ユーザーが正規版のゲーム アプリ「アングリーバード」をインストールしようとした場合に、マルウェアに感染した別のFlashlightアプリがインストールされてしまいます。パロアルトネットワークスはこの脆弱性を利用するテクニックを「Android Installer Hijacking」と名付けました。Google、Samsung、Amazonなどの大手企業と連携して影響を受ける各デバイスに対するパッチの発行を行ってきました。

脆弱性の説明

このしくみを理解するため、まずAndroidでのアプリのインストール方法から見てみましょう。Androidでは、Google Play Storeおよびローカル ファイル システムからのアプリのインストールができます。Google Playでは、Androidパッケージ(APK)をファイル システムの保護されたスペースにダウンロードします。サードパーティのアプリ ストアやモバイル広告ライブラリでは通常、APKファイルを保護されていないローカル ストレージ(/sdcard/など)にダウンロードするか、または直接インストールします。どちらの場合でも、インストールを完了するのはPackageInstallerと呼ばれるシステム アプリケーションです。

感染したプラットフォームでは、PackageInstallerに「Time of Check to Time of Use」脆弱性が発見されました。わかりやすく言えば、APKファイルがユーザーの知らない間にインストール時に書き換えられたり置き換えされたりするのです。「Installer Hijacking」脆弱性は、 保護されていないローカル ストレージにダウンロードされたAPKファイルにのみ影響を与えます。Play Storeのアプリはインストールされた他のアプリからアクセスすることはできないからです。

詳細解説

Androidでは、アプリ インストール プロセスをトリガーする方法は複数あります。たとえば、ユーザーがダウンロードされたAPKファイルをクリックしたとき、ユーザーがサードパーティのアプリ ストアからアプリをダウンロードしたとき、ユーザーがモバイル広告ライブラリのホストするアプリ販促広告をクリックしたとき、などです。どの方法でトリガーされても、APKインストール プロセスは常に同じ手順を実行します。

まず、システム サービスPackageInstallerは、APKファイルを解析してインストール プロセスを開始し、アプリ名、アプリ アイコン、アプリが要求するセキュリティ許可などの重要情報を取得します。図1のとおり、これがPackageInstallerActivityビューでユーザーに表示されます。

図1. ユーザーがインストールされるアプリの詳細情報をレビューする(「Time to Check」)

これが「Time to Check」(チェックの時間) です。この間に本当にアプリをインストールしたいのか、アプリにどのようなアクセス許可を与えるのかをユーザーに確認します。すべてのAndroidアプリはこのステップを実行し、ユーザーは[次へ]をクリックしてアクセス許可の全リストを表示して確認し、最後に[インストール]をクリックしてインストール プロセスを続行します(図1参照)。

脆弱性が存在するのはこのプロセスです。ユーザーがこの情報をレビューしている間に、攻撃者はバックグラウンドでパッケージを書き換えたり、置き換えたりします。AOSPに公開されたAndroid OSソースコードで検証したところ、影響を受けたバージョンのPackageInstallerは「Time of Use」(使用の時間)にAPKファイルを検証しません。そのため、「Time of Use」(つまり[インストール]ボタンをクリックした後)に、PackageInstallerはまったく異なるアクセス許可を与えた異なるアプリをインストールすることができます。

脆弱性の悪用

この脆弱性はいくつかの方法で悪用することができます。

方法A: APKを外部で書き換える

攻撃者は問題のないアプリを使用してマルウェアをインストールすることができます。この方法には複数の段階があります。

1. 被害者が正規アプリに見える「App X」をインストールします。このアプリは特に危険なアクセス許可は必要とせず、どこでも通常のアプリ ストアからダウンロードできます。
2. 後日、被害者は正真正銘正規のアプリ ストア(AmazonのApp Storeアプリなど)をインストールします。ユーザーはこれを使用して、APKファイルをローカル ファイル システムからインストールできます。ユーザーがこのアプリ ストアからアプリのインストールを試みるたびに、PackageInstallerActivityビューが開始されます。
3. ユーザーは正規のサードパーティ アプリ ストアでアプリを見つけ、インストールを試みます。これをダウンロード「App Y」とします。
4. ステップ1のアプリ「App X」は、PackageInstallerActivityビューが開始されたことを検出し、「App Y」のAPKファイルが保護されていないファイル システム上にあるかどうかチェックします。もしアプリがパブリック ファイル システム(on /sdcardなど)からインストールされている場合、ユーザーがアクセス許可画面をレビューしている間に、「App X」は、「App Y」のAPKファイルをマルウェアで上書きすることができます。
5. [インストール]をクリックした後、PackageInstallerはマルウェア感染した「App Y」のAPKをインストールします。攻撃者の必要とする任意のアクセス許可を持つ、任意のコードがデバイス上にインストールされます。

方法 A の微妙な問題は、「App X」がどのようにしてPackageInstallerActivityビューが開始されたことを検出するかです。次の 2 つのアプローチがあります。

• 「App X」はlogcatを監視して、アプリのインストールを検出、APKファイルの場所の情報を取得してファイルを置き換えます。Android <4.1ではこれはごく簡単です。Android >=4.1では、root 化されたデバイスのみがlogcatにアクセスできます。
• 「App X」は、インストールのためダウンロードされた対象アプリのAPKファイルが保存されているディレクトリの場所を監視できます。たとえば、Amazon Appstoreアプリ バージョン7.5はダウンロードしたAPKファイルを保護されていない/sdcardのディレクトリに保存しました。 ユーザーがAppstoreアプリからAPKファイルをダウンロードすると、このディレクトリに新しいAPKファイルが表示されます。「App X」はこのダウンロードされたファイルがどのファイルであるかを知る必要はありません。ファイルが表示されると、インストール ビュー(図1)が既にユーザー レビュー用に画面上に表示されていることを意味します。そこでこのとき、「App X」はこのAPKファイルをマルウェアに置き換えることができます(Amazonではこの報告を受けてこの問題を解決済みです)。

方法 B: APKを自ら書き換える

この悪用は、アプリが本当に必要としているアクセス許可を隠す、同じ脆弱性を使用します。

1. 被害者が正規アプリに見える「App X」をインストールします。ユーザーが「App X」を使用しているとき、「App X」は正規の「App Y」(人気のゲーム アプリなど)をインストールするようユーザーに促します。ユーザーがアプリをインストールすると、PackageInstallerActivityビューが開始されます。
2. 先ほど見たように、「App Y」の重要情報がPackageInstallerActivityビューに表示されます。「App Y」はいつもと異なるようなことは何も要求していないように見えます。実際、「App Y」はアクセス許可をまったく要求しないこともあります。
3. ーザーがPackageInstallerActivityをレビューしている間に、「App X」は「App Y」のAPKファイルをマルウェアで書き換えます。
4. ユーザーが[インストール]をクリックすると、実際に要求されたアクセス許可を無視して、改ざんされたバージョンの「App Y」がインストールされます。
5. 実際にインストールされたアプリは、「App Y」とは関連性も類似点もない可能性があります。

影響

この脆弱性は、Androidデバイス ユーザーだけでなく、Androidアプリ開発者にも影響を与えます。

Androidデバイス ユーザーは、自分がインストールするつもりのないアプリをインストールするはめに陥る可能性があります。

Androidアプリ開発者も影響を受けます。Google Play Storeを経由しないアプリ ストアのアプリやモバイル広告ライブラリは、当該アプリを保護されていないストレージ(/sdcardなど)へインストールする可能性があるからです。Amazon AppStoreアプリの例で見たように、/sdcardなどの保護されていないストレージでは、攻撃者が当該アプリをマルウェアに置き換えることができます。

両方の悪用のテストをAndroid 2.3、4.0.3-4.0.4、4.1.X、および4.2.x上で行い、確認しています。Android Dashboardによると、この脆弱性の影響を受けたのは2014年1月の最初の発覚当時でAndroid人口の約89.4%、2015年3月現在で約49.5%となっています。

この脆弱性悪用にはデバイスのroot化は必要ありませんが、root化されたデバイスはより危険です。

一部のAndroid 4.3に脆弱性

一部の携帯ベンダーのAndroid 4.3は、この脆弱性を含んでいる可能性があります。

AOSP webサイトに公開されたソース コードによると、Android 4.3_r0.9で、「Time to Check」と「Time to Use」の間で検証されるAndroid M anifestのハッシュ チェックが導入されました。ところが、一部の携帯ベンダーのAndroid 4.3にはこのチェックが含まれていないことがわかりました。たとえば、Android 4.3 (ビルド バージョンJSS15J.I337UCUEMK2、2013年11月16日作成)搭載のSamsung Galaxy S4 Android携帯、およびAmazon Fire OS version 13.3.2.5においてこの脆弱性をテストし検出しています。Samsung、Amazon両社とも、 パロアルトネットワークスの報告を受け取った後、影響のあったデバイスのパッチをリリースしました。

すべてのAndroidデバイス ベンダーに置かれましては、Android 4.3搭載デバイスを含めた全デバイスでこの脆弱性がないか検証するようお願いします。

Androidバージョン4.4以降ではこの脆弱性は修正されています。

対策

パロアルトネットワークスは、脆弱性スキャナー アプリをGoogle Play Storeで公開しました。また、この脆弱性スキャナー アプリで 「Installer Hijacking」脆弱性の存在をチェックする方法を説明するチュートリアル ビデオを公開しています。ここを参照してください。

セキュリティ研究者や他のベンダーに便宜を図るため、脆弱性スキャナー アプリのソースをGithubのhttps://github.com/PaloAltoNetworks-BD/InstallerHijackingVulnerabilityScannerで公開しています。

この脆弱性リスクに懸念を持つ企業は以下のステップを取る必要があります。

• 脆弱性の影響を受ける可能性があるデバイスには、Google Playのソフトウェアのみをインストールすること。これらのファイルは保護されているスペースにダウンロードされるため、攻撃者により書き換えられることはできません。
• Android 4.3_r0.9以降のモバイル デバイスを展開すること。ただし、一部には脆弱なAndroid 4.3デバイスもあるので注意が必要です。
• アプリにlogcatへのアクセス許可を与えないこと。Logcatはシステム ログで、これを使用すると悪用を単純化、自動化することが可能です。Android 4.1以降ではデフォルトでアプリによるシステムおよびその他のインストールされたアプリのlogcatへのアクセスを禁止しています。それでも、インストールされたアプリは、ｒoot化されたAndroid 4.1以降のモバイル デバイス上の他のアプリのlogcatにアクセスすることは可能です。
• ユーザーにroot化されたデバイスの使用を許可しないこと。

この脆弱性リスクに懸念を持つアプリ開発者は、ダウンロードしたAPKファイルを保護されているストレージ スペースのみに保存するようにしてください。

ベンダー フィードバック

Googleから:

「Android Open Source Project にはAndroid 4.3以降に対するこの問題のパッチが含まれています。 パッチはここで入手できます。https://android.googlesource.com/platform/packages/apps/PackageInstaller/+/2b3202c3ff18469b294629bf1416118f12492173

Android Security Teamでは、ユーザー デバイス上でこの脆弱性を悪用する試みは一切確認していません」

Amazonから:

「お客様にはFireデバイスで自動更新される最新バージョンのAmazon AppStoreへの移行をお願いします。 サードパーティAndroidデバイスはwww.amazon.com/getappstoreで更新できます」

開示の履歴

• 2014年1月： パロアルトネットワークスが初めて発見
• 2014年2月： Google Android Security Teamへ脆弱性を報告
• 2014年3月： Samsungへ脆弱性を報告
• 2014年9月： Amazonへ脆弱性を報告
• 2015年3月： 一般公開

謝辞

脆弱性の確認、およびベンダーへの通知において惜しみない協力をしてくれたパロアルトネットワークスのRyan Olson、Huagang Xie、Claud Xiao、Colt Blackmore、およびTaylor Ettemaに感謝します。脆弱性の公開とスキャナー アプリの構築で力を発揮したパロアルトネットワークスのScott Simkin、JL Watkins、Baoyue Hu、およびErik Jacobsenにも感謝します。 また、この脆弱性の確認とパッチ作成で当社に協力いただいたSamsung Knox team、Google Android Security team、およびAmazon Web Services & Lab126に敬意を表します。