Androidアプリ開発のためのセキュリティ入門 3.2[脆弱性]意図しないアクティビティの公開

皆さん、ごきげんよう。貴島(@jnkykn)です。先週のSEB SUMMITが楽しすぎたことを書きたいのに、まだ参加ブログが書けていません。つまり、私のSEB SUMMITは、まだ終わっていないということです。
今週、ミーハーな私は、ミラノ・コルティナオリンピックの金メダリスト、アリサ・リウ選手の発言に触発されて、huluでAnotherを見たり、綾辻行人さんの原作を読んだりしています。（普段エレベーターは「落ちませんように」とビビりながら乗っているし、傘も「刺さったら嫌だなぁ」と思いながら使っているのに、さらに怖くなっています😱）

さて、前回から日にちが経ってしまいましたが、前回ちょっとだけ読んでお茶を濁した「Androidアプリ開発のためのセキュリティ入門 体験して学ぶ16の脆弱性とその対策」の続きを再開します。

学習メモ：3.2[脆弱性]意図しないアクティビティの公開

前回は、Androidアプリのアプリコンポーネントとマニュフェストファイルの、設定の概要と脅威について学習しました。今日は、意図しないアクティビティの公開についてハンズオンを含み学習を進めます。

意図しないアクティビティの公開で発生するセキュリティ上の問題

マニフェストのアクティビティの公開設定が不適切だと、以下のようなセキュリティ上の問題が発生します。

• 想定していない処理の実行

• 意図していない画面へのアクセス

• 他の攻撃の足がかりとしての利用

認証後に実行される想定なのに認証を回避して直接実行されたり、開発途中の画面なのにアクセスできたり、悪意あるアプリが公開されているコンポーネントを利用して機密情報にアクセスしたりといった問題が発生するということですね。開発したアプリ自体に悪意がなくても、意図せず利用されてしまうのは避けたいので、ここはしっかり理解しなくては。

ハンズオンが久しぶりすぎて

いよいよハンズオンです。今回は、アクティビティでexportedがtrueに設定されていたために、「想定していない処理の実行」「意図していない画面へのアクセス」ができることを実際に試します。

躓き１：

エミュレータを起動する前にインストールしようとしてしまいました💦

~# adb.exe install C:\AndroidMobile-Sample-App\chapter03\apk\VulnBank.apk
* daemon not running; starting now at tcp:5037
* daemon started successfully
adb.exe: no devices/emulators found

躓き２：

エミュレータを起動して、いざハンズオン用のアプリをインストールしようとして、パスの区切り文字の違いでモタモタしてしまいました。

root@jnkyknX1:/mnt/c# adb.exe install C:\AndroidMobile-Sample-App\chapter03\apk\VulnBank.apk
Performing Streamed Install
adb.exe: failed to stat C:AndroidMobile-Sample-Appchapter03apkVulnBank.apk: No such file or directory
root@jnkyknX1:/mnt/c# adb.exe install AndroidMobile-Sample-App/chapter03/apk/VulnBank.apk
Performing Streamed Install
Success

Windowsのフォルダからドロップすると、パスのディレクトリ区切りが'\'なのでディレクトリとして認識されず、区切りなしで1つのファイル名になってしまい、そんなファイルは無いよ！と怒られました。'\'を'/'に置換して無事にインストールができました。
Ubuntu22.04を実行しているわけですが、これ、rootで実行してるの良くないですね。ユーザー追加しないと…

以降はスムーズに

その後は、問題なくハンズオンを進めることができました。認証しなくても送金画面が表示できるし、開発中の画面も表示できました。期待どおりです。
また、カスタムパーミッションで制限されているProtectActivityを呼び出す際に署名に使われた鍵の違いによってアクセスが制限されることも確認できました。
パーミッションの定義がアプリのインストール順に依存するので、ハンズオン用の各アプリのインストール順が重要だったことも理解できました。悪意あるアプリが正規のアプリが利用するパーミッションに別の
protectionLevelを定義すると、正規のアプリが保護しているすべてのpermission属性を無視してアクセスできてしまう問題があることもわかりました。こわい。

本の中で紹介されていた"https://blog.trendmicro.co.jp/archives/8760"は、URLが変わったようなのですが、見つけられず…（カスタムパーミッション、protectionLevelなどのキーワードでは検索できませんでした💦）

対策のまとめ

permission属性でコンポーネント間のアクセス制御ができるものの、特定の条件で回避できてしまうので、機能上公開しなくて良いコンポーネントは、非公開にするのが最良の対策ですね。また、非公開コンポーネントや開発中の機能は、リバースエンジニアリングされ悪用される可能性があるため、不要なコンポーネントはリリースアーカイブから削除するのが安全であることも理解できました。

続きは、また今度

キリが良いので、今日はここまでにします。先日、FuraIT. fuel #79ハイブリッドもくもく会。 冬の富良野でもくもくする。にオンライン参加したんですが、高校生のボストン語学研修のお話や旭川の素敵な下宿の話を伺うことができて、最高でした。

いつかまた、FuraITに現地参加したいな～。と富良野に思いを馳せながら、終わります。それでは、皆さんごきげんよう。次の記事またはイベントで、お目にかかりましょう。あっ、そうそう、今度の土曜日は、【札幌3/7】アンカンファレンスどうでしょう （JavaDo #33）が開催されます。ぜひ、ご参加ください。札幌営業所で、お待ちしています。