AIセキュリティエージェントがAndroidアプリから24件の脆弱性を発見
GitHub Security Labは、オープンソースのAIセキュリティエージェント「Taskflow Agent」を使い、Androidアプリケーションから24件の脆弱性を発見・報告した事例を公開しました。
注目すべき点は、単純な危険APIの検出だけではありません。Intent、ディープリンク、WebView、アプリ間連携といったAndroid特有の攻撃面をAIに段階的に調査させることで、複数の処理が組み合わさって発生するロジック不備も見つけています。
一方で、AIが見つけた問題をそのまま脆弱性として扱えるわけではありません。深刻度の判定や実際の悪用可能性には、モバイルセキュリティに詳しい人間による検証が必要です。
Taskflow Agentとは何か
Taskflow Agentは、セキュリティ研究者が有効なプロンプトや調査手順を「タスクフロー」として定義し、再利用できるようにした仕組みです。
大規模言語モデルにリポジトリ全体を一度に調査させるのではなく、調査を複数の段階に分割します。今回のAndroid向けフローでは、主に次のような処理を組み合わせています。
- 外部入力が到達しうるエントリーポイントを抽出する
- エントリーポイントをモバイル固有のものと、それ以外に分類する
- Androidコンポーネントやデータフローを脅威モデルに反映する
- Intent、ディープリンク、WebViewなど、対象ごとの脆弱性クラスを調査する
- 複数回の実行結果を比較し、見落としを減らす
- 発見した問題について、影響や再現方法を追加検証する
Androidアプリを含むリポジトリには、サーバーやデスクトップ向けのコードが同居している場合もあります。最初にモバイルの攻撃面を切り分けることで、AIが調査対象を誤認しにくくなります。
また、脆弱性クラスを明示的に指定することも重要です。例えばIntentを受け取るコンポーネントであれば、権限のないアプリからの呼び出し、Confused Deputy、不適切なブロードキャスト処理などを重点的に確認させます。
事例1：エクスポートされたActivityが位置情報の追跡につながったケース
オープンソースのナビゲーションアプリ「OsmAnd」では、外部から起動可能なMapActivityの処理が問題になりました。
このActivityは設定ファイルやディープリンクを扱う一方、設定のインポート処理で複数のIntent extraを参照していました。問題は、これらの値が特定の内部サービスから渡されることを想定していたにもかかわらず、外部アプリから起動できるActivity上のIntent extraとして扱われていた点です。
Androidでは、外部から呼び出せるActivityに対して、呼び出し元アプリが任意のIntent extraを付けることを防ぐ仕組みはありません。そのため、攻撃者が用意したアプリから、次のような設定を指定できる状態になっていました。
- ユーザーへの通知を抑制する
- 既存設定を置き換える
- 設定の種類についてユーザー確認を省略する
この結果、攻撃者が用意したタイルサーバーを参照する設定を、ユーザーに気付かれにくい形でインポートさせられます。地図タイルの取得先が攻撃者のサーバーになると、ユーザーが閲覧した地図範囲の情報がサーバー側に送信されます。さらに、経路情報の取得先を変更すれば、出発地や目的地の推測にもつながります。
この事例が示すのは、exported属性だけを確認しても十分ではないということです。外部公開されたコンポーネントが、入力値を使って設定変更、ファイル操作、ネットワーク通信などを実行していないかまで、処理の流れを追う必要があります。
事例2：ディープリンクとCookie処理の組み合わせによるアカウント乗っ取り
WikipediaのAndroidアプリでは、wikipedia://形式のディープリンク処理に不備がありました。
アプリは、ディープリンクのホスト名がWikipediaのドメインで終わっているかを確認していました。しかし、文字列の末尾一致だけに依存すると、正規のドメインに見える別ドメインを通過させる可能性があります。
この問題により、攻撃者が用意したページをアプリ内のWebViewで開かせられる状態が生じました。さらに、Cookieの対象ドメイン判定にも同様の末尾一致に依存する処理があり、攻撃者側のページにWikipedia関連のCookieが送られる可能性がありました。
ディープリンク処理とCookie処理という別々の問題を組み合わせることで、次のような影響につながります。
- ユーザーが正規のWikipediaページを開いていると誤認する
- アプリ内WebViewで攻撃者管理のページを実行する
- 長期間有効な認証情報やセッション情報が漏えいする
- Wikimedia系サービスのアカウントが不正利用される可能性がある
この事例は、個別の検査が一見妥当に見えても、処理全体を連鎖させると重大な影響が生じることを示しています。AIエージェントが得意とするのも、こうした複数コンポーネント間の関係を調べる作業です。
Androidアプリの診断でAIが活躍しやすい領域
今回の事例から、AIエージェントは特に次のような調査と相性がよいと考えられます。
- Manifestで外部公開されたActivity、Service、Receiver、Providerの洗い出し
- Intent extraやURIパラメーターのデータフロー追跡
- ディープリンクのホスト名・スキーム・パス検証
- WebViewへのURL、JavaScript、Cookieの受け渡し確認
- 外部ストレージや共有ファイルを利用する処理の分析
- JavaScript bridgeやアプリ内の権限境界の確認
- 複数の脆弱性を組み合わせた場合の影響評価
特に、単一の関数だけでは問題が見えず、入口から危険な処理までの経路を追う必要がある問題では、段階的なタスクフローが有効です。
導入方法と運用上の注意
公開されたタスクフローは、Codespaces上で実行できます。記事で示された手順では、GitHub Copilotのライセンスとプレミアムモデルリクエストを利用し、次のようなコマンドでモバイル向け監査を開始します。
./scripts/audit/run_mobile.sh myorg/myrepo
中規模のリポジトリでは完了までに1〜2時間かかる場合があり、多数のツール呼び出しによって大量のトークンを消費する可能性があります。実行前には、対象リポジトリの機密情報、コードの取り扱い、利用するAIサービスの契約条件を整理しておく必要があります。
診断結果はSQLiteのaudit_resultsテーブルで確認できます。ただし、結果に脆弱性フラグが付いていても、それは調査候補であって確定判定ではありません。
AIの限界：発見能力と深刻度判定は別問題
今回の取り組みでは、AIが脆弱性の発見に強い一方、深刻度の評価には課題があることも示されています。
例えば、特定の状態を事前に作らなければ成立しない問題や、実際の利用環境では到達が難しい処理を、AIが高い優先度で報告することがあります。反対に、パストラバーサルのような問題でも、アクセス可能な領域が外部ストレージに限定されていれば、実際の影響は限定的かもしれません。
さらに、脆弱性候補を評価する際には、次のような要素も確認する必要があります。
- 攻撃者が対象処理まで到達できるか
- 攻撃にユーザー操作が必要か
- アプリの権限やAndroidのサンドボックスが影響を抑止するか
- 内部ストレージと外部ストレージのどちらのデータが優先されるか
- 攻撃結果が永続化するか
- 認証情報や個人情報に実際にアクセスできるか
- 実機や対象バージョンで再現するか
そのため、AIに「脆弱性を見つける」だけでなく、「再現可能な検証手順を作る」「緩和要因を列挙する」「影響範囲を限定する」といった追加タスクを与えることが重要です。それでも最終判断は、Androidの実行モデルを理解したセキュリティ担当者が行うべきです。
開発チームが取り入れるべき実践ポイント
AIエージェントを導入する場合、単発のスキャンとして使うより、開発・レビュー工程に組み込む方が効果的です。
- Manifestとディープリンク定義を変更したプルリクエストを重点的に監査する
- 外部公開コンポーネントごとに、想定する呼び出し元と入力値を記録する
- Intent extraを信頼できる内部通信として扱わず、外部入力として検証する
- WebViewで読み込めるURL、Cookie、JavaScript bridgeの境界を明確にする
- AIの指摘には、再現性・影響・前提条件を付けて人間がトリアージする
- 重要な指摘はエミュレーターや実機で再現し、修正後に回帰テストする
まとめ：AIは診断者ではなく、調査能力を拡張する道具
Taskflow Agentによる24件の発見事例は、AIがAndroidアプリの脆弱性診断で実用的な役割を担えることを示しています。特に、Intentやディープリンク、WebViewのように、複数の処理やコンポーネントをまたいで成立するロジック不備を調査できる点は重要です。
ただし、AIは脆弱性候補を大量に見つける能力と、現実の攻撃可能性や深刻度を正確に判定する能力を同じ水準で持っているわけではありません。
実務では、AIに探索範囲を広げさせ、人間が脅威モデル、再現性、緩和要因、事業影響を評価する役割分担が現実的です。Androidアプリのセキュリティ対策では、AIを人間の代替と考えるのではなく、コードレビューや診断の初動を高速化する調査パートナーとして活用することが、現時点での最も有効なアプローチといえるでしょう。
出典： GitHub Blog