GitHubのオープンソースAI監査エージェントがAndroidの脆弱性24件を発見 — 深刻度の判定は外し続けた

GitHub Security Labが、オープンソースのAIエージェントを使ってAndroidアプリケーションの脆弱性24件を報告した。開発者なら誰でも自分のリポジトリに向けて実行できるツールである。研究者のKevin StubbingsはGitHub Blogの記事でその作業を公開し、すでに開示済みの2件をたどってみせた。ナビゲーションアプリOsmAndにおける無警告の位置情報漏洩と、WikipediaのAndroidアプリでタップ一回で成立するアカウント乗っ取りである。

要点

• GitHub Security Labのオープンソース実装Taskflow Agent上に自作したタスクフローで、Androidの脆弱性24件を発見し報告した。
• Playストアで1,000万件超のダウンロードを持つOsmAndのエクスポートされたアクティビティにより、端末上の任意のアプリが地図設定を書き換え、利用者のタイル座標や経路を攻撃者のサーバーへ送り出せた。
• モデルはバグの発見には格段に強い一方、深刻度の評価は苦手で、低リスクのノイズと誤検知を出し続け、結局は人のレビューが拾うほかなかった。

Android向けにタスクフローをどう調整したか

エージェント自体は汎用で、価値はプロンプトの側にあった。Stubbingsはエントリポイントをモバイルと非モバイルに振り分けるタスクフローgather_mobile_entry_point_info.yamlを追加した。スマートフォンアプリとWebサーバー、デスクトップクライアントが一つのリポジトリに同居していても、モデルが誤った攻撃面について推論し続けないようにするためである。

続いてclassify_application_local.yamlを書き換え、混乱した代理（confused deputy）や安全でないブロードキャストといった脆弱性クラスを明示的に列挙した。モデルの想起頼みにしなかったわけだ。モデル出力は非決定的なため、厳密なプロンプトを広めのプロンプトと並べて繰り返し走らせた。狭い側が明白なものを捕らえ、広い側が想定外を見つける。

OsmAndの欠陥で何ができたか

24件のうち3件がOsmAndに関するもので、最も深刻なものはコーディング上のミスというより設計上の問題として読める。

1. ディープリンクと設定インポートを扱う画面MapActivityがエクスポートされており、端末上の他アプリから到達できる。
2. そのインポート経路はsilent_import、replace、export_type_list_keyといったインテントのエクストラを読むが、開発側はこれらがプロセス内のAIDLチャネル経由でしか渡らないと想定していた。Androidには、外部の呼び出し元がどのエクストラを添えるかを制限する手段がない。
3. 結果として、権限を持たないアプリでも通知も確認もなしに設定を書き込める。OsmAndが地図タイルのURLを組み立てる際に使うテンプレートまで含めてだ。
4. そのテンプレートを攻撃者のホストに向ければ、読み込まれるすべてのタイルの座標と、計画されたすべての経路が漏れる。その間サーバーは本物のOpenStreetMapの画像を中継するため、地図は手つかずに見える。

メモリ安全性のエラーも、特殊な端末設定も絡んでいない。静的解析器がめったに指摘せず、レビュー担当も端から端まで追う時間を持たない種類のロジック欠陥である。

誤った文字列を信用したディープリンク検査

Wikipediaの件はリンクを一度タップしただけでアカウント乗っ取りに至るが、原因は文字列比較ひとつだ。ディープリンクのハンドラが、URLのオーソリティを基準ドメインと一致判定する代わりにendsWithで検証していた。そのためevil-wikipedia.orgのような類似ドメインを狙ったwikipedia://のURLが検査を通り、アプリのWebView内で描画され、アプリが自分のものとして扱うコンテキストで攻撃者のJavaScriptが動いた。

Cookieマネージャ側の二つ目の検査も同じ誤りを繰り返しており、そのページはWikimediaの全プロパティで有効なセッションCookieを読めた。

モデルが力不足だったところ

Stubbingsは弱点を率直に述べている。深刻度の見積もりだ。報告するなと指示しても影響の小さい問題を上げ続け、緩和要因が攻撃を打ち消す場合には実世界での影響を読み違えた。外部ストレージへのパストラバーサルは、アプリが同じデータで内部ストレージを優先しているなら無価値である。動作する概念実証の作成を義務づければそうした事例の一部は表に出るが、重要でないかもしれないバグに追加の実行コストを払うことになる。

埋め合わせとなった強みはAPIの知識だった。モデルはGoのpath.Cleanとfilepath.Cleanのように、セキュリティ上の意味が分かれる関数の挙動を安定して切り分け、生成された概念実証の多くはほとんど手直しを要さなかった。Help Net Securityがまとめたとおり、どの検出結果にもモバイルアプリを理解したレビュー担当が依然として必要である。

自分のプロジェクトで走らせるには

タスクフローはseclab-taskflowsリポジトリにあり、Codespaceで起動できるよう整備されている。./scripts/audit/run_mobile.sh myorg/myrepoを実行すると監査が始まり、中規模のコードベースで1〜2時間かかったうえで、該当行をSQLiteのhas_vulnerability列に書き出す。Copilotのライセンスが必要でプレミアムモデルのリクエストを消費し、GitHubはトークン費用が軽くない点をあらかじめ警告している。本誌が反対側から追ってきた潮流の、建設的な対になる話でもある。攻撃者はスキャナーに検知されなくなるまでマルウェアを書き換えるエージェントを走らせていた。

FAQ よくある質問

GitHubのAIセキュリティエージェントは無料で使えるのか

Taskflow Agentと例示されたタスクフローはオープンソースだが、実際に動かすのは無料ではない。GitHub Copilotのライセンスが必要で、一度の監査が大量のプレミアムモデルリクエストを発生させる。GitHubは、規模の大きいリポジトリではこれが無視できない費用になると明言している。

OsmAndとWikipediaの脆弱性は開示済みか

開示済みである。いずれも通常の手順で報告され、公表後に初めて内容が記述された。GitHub Security Labは24件の残りについても、公開され次第アドバイザリのページに掲載していく。

AIエージェントは人間のセキュリティレビュー担当を置き換えられるか

今回の材料からは置き換えられない。エージェントは有用な手掛かりと動作する概念実証を生み出したが、深刻度の低い問題を過剰に報告し、緩和要因がある場合には影響を誤って評価した。結局はそのプラットフォームに通じた研究者が一件ずつ検証する必要がある。