「logcat」を含む日記

■Android Installer Hijacking Vulnerability

仕組みがわりと凝ってて面白い。

http://researchcenter.paloaltonetworks.com/2015/03/android-installer-hijacking-vulnerability-could-expose-android-users-to-malware/

1. マルウェア作者はまず、SD読み書きとインターネットアクセス権限くらいしかない「権限的には無害っぽい」アプリAを作成し、アプリストア等に上げて被害者にインストールさせる (アプリAそのものは無害だこの時点では直接的な被害を及ぼさないし、Google Play での配信でもよい)
2. 実はこのアプリAは、PackageInstaller の監視をしている。(rooted 端末であれば logcat を見る、そうでなければ /sdcard などの、3rdアプリストアが .apk を一時的に置くディレクトリを監視)
3. 被害者は、1. の作者とは関係のない、全く問題のない野良アプリBをインストールしようとする。この時、アプリBは /sdcard などにいったんダウンロードされ、それを PackageInstaller が読み取って、権限の確認等のダイアログを出す。
4. ここでアプリA は PackageInstallerActivity を検知し、/sdcard に一時的に置かれた「アプリB.apk」を、マルウェアに置き換えてしまう！(ネット越しにダウンロードしてきて上書きしてしまうか、あるいはアプリAに内包されていたマルウェアを取り出し、上書きする)
5. 被害者が「ふんふんパーミッションも問題ないしオッケー！」と思ってインストールボタンを押すと、4. で上書きされたマルウェアを知らないうちにインストールしてしまう！

要するに PackageInstaller が権限チェックするタイミングと、実際にインストールするタイミングの間に、対象の .apk を置き換えてしまうという手法となります。(Google Play ストアからのインストールの場合は、一時的な .apk は /sdcard などではなく端末内のセキュアな場所に置かれるために、書き換えることができません。)

また Android 4.3 以降は、権限チェック時に AndroidManifest.xml のチェックサムを記録しておき、インストール時にももう一度それを確認するように PackageInstaller が修正されているようです。(一部のベンダの端末では 4.3 でもこのチェックをしていないので脆弱性の影響を受ける)

さらには、4.4 以降であれば、上記のチェックサム確認の他に、そもそもアプリが自由に /sdcard を書き換えることができなくなっているので、.apk を書き換えること自体ができなくなっていますね。

ユーザにできる自衛策としては、Google Play からのみアプリをインストールする、といったところでしょうか。

あるいは、/data/local/tmp はアプリからは書き換え可能でしたっけ？

できないのであれば、PC で .apk ファイルをダウンロードしたのち、adb install でインストールする、という手もありなのかな。

あ、ちなみに Amazonアプリストアアプリ (ややこしいな) は既にこの問題に対処しているようなので、Amazonアプリストアは安心して利用しても大丈夫かと思います。

[※2015/03/26 トラバとブコメでの指摘に合わせて少々書き直しました]

Permalink | 記事への反応(1) | 16:32

ツイートシェア