2011年7月25日

勘違いしたくないAndroidセキュリティ「アプリインストール」に関する5つのポイント

20110725_install01.jpg
※正しくはsignatureOrSystemです。typoすいません。

最近話題のAndroidのセキュリティについて、確かに何も無いとは思っていないのですが、少々煽りが過ぎるんじゃないかと思うので、少しでも誤解が解ければいいなということで、「勝手に他のAndroidアプリをインストールする権限」について少しだけ噛み砕いて説明したいと思います。

【注】噛み砕いたつもりが、エントリの対象者が専門家なのか開発経験者なのか一般ユーザなのかレベルがバラバラの表記になってしまっております。そのうちもう少しわかりやすく改稿してリベンジしたいです...orz

2011.07.26 一部表現を修正。

1. インストーラの起動には何も特別な権限は要らない

20110725_install04.png

「アプリケーションの権限」を確認し、「インストール」を選択する画面を呼び出すには特別な権限は何も要りません。
MIME-Typeがapplication/vnd.android.package-archiveなIntentでapkファイルのパスを指定してやるだけで呼び出せます。

String fileName = Environment.getExternalStorageDirectory() + "/hoge.apk";
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setDataAndType(Uri.fromFile(new File(fileName)),
"application/vnd.android.package-archive");
startActivity(intent);

20110725_install03.png

これについては「提供元不明のアプリ」のチェックによってガードされていますが、Android Marketではないサードパーティ製Marketからのインストールや、野良アプリのインストール時に既にチェックがONになっていることはよくあると思います。


2. 「サードパーティ署名、かつプリインでない」アプリに「アプリケーションを直接インストール」の能力はない

20110725_install06.png

マーケットアプリの自動更新の様に、勝手にアプリケーションを更新する能力は、前述のインストーラの起動とは別の能力です。
具体的にはandroid.permission.INSTALL_PACKAGESというパーミッションがそれに該当しますが、この権限は"signatureOrSystem"というプロテクションレベルに分類されています。

Android システムイメージ内にある または システムイメージ内にあるアプリケーションと同じ証明書に署名されたアプリケーションのみにシステムが付与する許可。 signature 保護レベルがほとんどの要求や動作を満たす必要があるときは、アプリケーションが厳密にインストールされているいないに関わらず、このオプションを使用するのは避けてください。"signatureOrSystem" 許可はある特別な状況下において使用されるものであり、そこでは多数のベンダーがシステムイメージに組み込まれたアプリケーション備え、それらが共に構成される理由で、特定の機能を明示的に共有します。

ソフトウェア技術ドキュメントを勝手に翻訳:<permission>
http://www.techdoctranslator.com/android/guide/manifest/permission-element

つまるところ、そもそもインストール時に権限(パーミッション)の確認がありますが、それを超えたとしても、強力な権限については別の箇所でガードがかかっているのです。


3. デバッグが有効になっていれば、USB経由での強制インストールは可能

こちらは物理的なアタックという制限はつきますが、開発者の端末であったり、デバッグ機能を用いた画面キャプチャ取得の経験があったりすると、画面がロック状態であろうが、強制的にアプリケーションのインストールが可能です。

昼ドラなネタで「浮気調査にパスワードロックを解除して...」とかありますよね。あれよりもっと簡単です。条件が揃っていれば、数秒USBケーブルを差すことができればバックドアアプリケーションの仕込みが完了してしまいます。


4. 直接システムフォルダにapkがコピーされると、プリインアプリとしてインストールされたことになる。

通常の端末での通常の操作をしている限りは、Androidアプリのインストール権限は決して自由ではないのですが、ことrootedの環境になるとこれが途端に崩れます。

/systemフォルダの書き換えに特別な制限のかかっていない端末にて、/system/app配下にapkをコピーすると、プリインアプリとしてインストールされた状態になります。

※rootedなNexus One(2.3.4)で実験

adb shell
su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
chmod 777 /system/app
exit

adb push InstallTest.apk /system/app/

20110725_install05.jpg
/system/app配下にapkがコピーされると、自動的に展開(インストール)されます。

20110725_install07.png
結果、アンインストール不可(プリインアプリ)となったInstallTest。

※PackageManagerの@hiddenなメソッドでアプリがサイレントインストール可能かどうかはまた調べます。


5. exploit codeが動作する(通常アプリケーションがroot権限を奪取できる)端末でのセキュリティ対策は微妙

組み合わせの話ですので当然のコトですが、z4root・SuperOneClick・Gingerbreakの様なrootedツールが動作する端末では、それらのツールと同じコードを悪意のあるマルウェアアプリケーションから実行してしまえば、なんでもやりたい放題というわけです。


○まとめ(言いたいこと)

・現状主流の後インストールなセキュリティアプリは気休めだと思います。対マルウェア能力はPCのそれと比較して大幅に弱く、遠隔ロックやポリシー設定、ストレージスキャンをメインに押し出しているのは「そこを中心にしか価値を提供できない」からであり、セキュリティアプリを活かすにはそれ自身の能力に加えてユーザの高いリテラシーが必要です。

・サードパーティ製のアプリインストール許可・USBデバッグON・rooted端末は「端末で扱う全情報がちょっとしたことで漏れる」ことをよく理解しておいてください。これらを絶対にONにできないカスタマイズを施したビジネスAndroid端末が多分もう少し増えるだろうと思ってます。
 ※別エントリにて補足説明を追記。

・Androidそのもの、というよりは「セキュリティホールを塞ぐアップデートをするのに時間とお金がかかる」というスキームの問題も大きいです。「かんたんrootedツールが動く=セキュリティホールがある端末」という事実はきちんと抑えるべきです。

・フォントと画面キャプチャの不便さをrootedの危険性と天秤にかけるのはちょっと分が悪いと思います。(フォントはちょっとセキュリティ怖いけど)まともなフォント+フォント切り替え機能、画面キャプチャの独自提供は利便性の向上と同時に、rootedの必要性を下げるという意味で、セキュリティ面で賢い対応だと思います。

・結局のところ、「Windowsで怪しいexeダブルクリックするなよ!」と一緒で、「Androidで怪しいapkインストールするなよ!」が一番基本です。

コメントする