脆弱なFirebaseアプリにおけるLLMペネトレーションテスト能力の評価
エグゼクティブサマリー
GPT-5.5は、一般的なFirebaseの誤設定を自律的に特定し、悪用する能力において最も高い成功率を示しました。一方で、他の多くの主要モデルは、厳格なセキュリティガードレール、あるいはAPIベースの攻撃から直接的なデータベースアクセスへの転換（ピボット）に失敗したことにより、課題の解決に至りませんでした。脆弱なReact Nativeアプリを用いたテストにおいて、GPT-5.5は70%の試行で課題を解決し、ClaudeやGeminiといった競合モデルを大幅に上回りました。
課題：Firebaseにおけるアクセス制御の不備
この実験では、React Native (Expo) とPython (FastAPI) バックエンドを使用して独自に構築された書籍レビューアプリ (BookNook) を使用しました。API自体は安全でしたが、アプリケーションにはデータレイヤーにおける重大な脆弱性、すなわち**アクセス制御の不備（またはオブジェクトレベルの認可欠如）**が含まれていました。
脆弱性の詳細
- 欠陥: アプリにはFirebaseの設定詳細を含む
google-services.jsonファイルが含まれていました。 - エクスプロイト: 攻撃者はこれらの認証情報を使用してFirebase経由で直接ユーザーとしてサインアップし、Firestoreデータベースを読み取ることができました。これにより、強化されたAPIを完全にバイパスして、プライベートなユーザーレビュー（「フラグ」）を取得することが可能になります。
- 実世界での関連性: この特定のパターン、すなわち「安全なAPIと、広範な権限を持つFirebase/Supabase」の組み合わせは、本番環境で見られる一般的な脆弱性です。
モデルの性能比較
研究者は、1回あたりの予算を10ドル、制限時間を2時間として、いくつかの思考型モデルをテストしました。
上位パフォーマンスモデル
| モデル | 解決率 | 平均コスト/試行 | コスト/解決 | 中央値トークン数/試行 |
|---|---|---|---|---|
| GPT-5.5 | 7/10 | $6.62 | $9.46 | 260k |
| DeepSeek V4 Pro | 3/10 | $0.62 | $0.62 | 194k |
| Claude Sonnet 4.6 | 2/10 | $9.15 | $45.75 | 390k |
| Claude Opus 4.8 | 2/10 | $3.23 | $16.15 | 113k |
解決できなかったモデル
DeepSeek V4 Flash, Gemini 3.1 Pro Preview, Gemini 3.5 Flash, MiniMax M2.7, および Step 3.7 Flash を含むモデルは、10/10の試行すべてにおいて課題を解決できませんでした。
失敗モードの分析
モデルが失敗した主な理由は、3つあります：アーキテクチャへの固執、セキュリティガードレール、および信頼性の問題です。
1. アーキテクチャへの固執
MiniMax M2.7やいくつかのDeepSeek V4 Proの試行を含む多くのモデルは、APIに固執してしまいました。彼らはFastAPIバックエンドにおけるIDOR (Insecure Direct Object Reference) 脆弱性を探そうと試み、APIが安全であることを証明した後も、Firebaseデータベースへの転換（ピボット）に失敗しました。一部のモデルはFirebaseの認証情報を見つけましたが、データベースに直接アクセスするのではなく、誤ってそれを使用してAPIに対して認証を行おうとしました。
2. セキュリティガードレールと拒否反応
ガードレールは、欧米のモデルの解決率に大きな影響を与えました：
- Gemini: セキュリティ上の理由から即座に拒否反応を示しました。これは非常に低い中央値トークン数（例：Gemini 3.1 Proでは9k）に反映されています。
- Claude: 正しい経路に到達することが多いものの、「遅延拒否」が発生しました。これは、モデルがエクスプロイトを実行しようとした瞬間にセッションが終了してしまう現象です。
- GPT-5.5: 研究者のアカウントがセキュリティ研究用に事前承認されていたため、ほとんどの拒否反応が発生せず、最高のパフォーマンスを発揮しました。
3. リソースとAPIの安定性
研究者は、中国のモデル（GLM, MiniMax）が、倫理的な躊躇なくデータベースへの攻撃をより「快適に」行う傾向があることを指摘しました。しかし、これらのモデルは頻繁なAPIの停止や高いトークン消費量に悩まされました。例えば、Qwen 3.7 Maxは、最終的な評価において課題を解決することなく、1回あたりの試行で最大732万トークンを消費しました。
コミュニティの視点
セキュリティ専門家やAIユーザーの間での議論では、LLM駆動のペネトレーションテストの現状に関して、いくつかの重要な点が浮き彫りになりました：
"Anthropicはモデルのリリースごとに、セキュリティ面での制約をより強めています... 最終的に、これらのモデルは最小公倍数への過学習によって、大きな打撃を受けることになるでしょう。"
一部のコントリビューターは、モデルが完全に自律的に動作することを期待する手法はナイーブ（単純すぎる）であると主張しました。彼らは、バイナリのパッチ適用やアンチデバッグ技術の回避といった高度な技術を要する課題に対しては、「モデルと共に作業する」（human-in-the-loop）手法の方がはるかに効果的であると提案しました。
AIセキュリティテストにおける重要な教訓
- ピボット（転換）の難しさ: LLMは、明示的な指示がない限り、失敗している戦略（APIファジングなど）に固執し、全く異なるベクトル（直接的なDBアクセスなど）への転換が困難です。
- ガードレール vs. 能力: セキュリティ課題の解決に失敗することは、技術的な推論能力の不足ではなく、多くの場合、安全性へのアライメント（調整）の結果です。
- 複雑性の活用: モデルに反復作業を強制させるための信頼性の高いエージェント・ハーネスを構築することは、自動化されたセキュリティ研究において最も困難な部分の一つです。",