Hello there, ('ω')ノ
記事
https://basu-banakar.medium.com/hacking-anything-llm-via-reversing-cves-duplicates-4fbfde67463f
ねらい
この記事では、公開済みのCVEや重複レポートを調べ直し、実際に「Anything LLM」というアプリをローカルやクラウドにデプロイして脆弱性を再現・確認するプロセスが語られています。 攻撃者の思考はシンプルです：
- 公開済みの脆弱性を分析
- 修正が甘い部分を探す
- ローカル環境・クラウド環境で再現実験
- 新しい攻撃シナリオを発見
ストーリーと実践手順
1) LLM02: Stored XSS（Insecure Output Handling）
- 操作：既知のStored XSS報告を調べ、ローカルのAnything LLM環境にXSSペイロードを入力。
- 観察：
dompurifyによる入力サニタイズはあるが、出力のサニタイズはされていない。 - なぜ：入力だけを消毒しても、出力処理が甘ければXSSは成立する。
- 結果：LLMに騙される形で保存型XSSが実行できた。
2) SSRF（AWS Metadataアクセス）
- 操作：huntr.devに公開されたSSRFレポートを参照し、修正内容を検証。
- 観察：CloudFormationスタックのiptablesルールで
169.254.169.254へのアクセスを制御しているが、アプリ本体レベルの修正は未対応。 - なぜ：クラウド外で手動デプロイすれば、この制御が効かず、AWSメタデータサービスにアクセスできてしまう。
- 結果：EC2内のインスタンスメタデータ（IAM情報など）をSSRFで窃取成功。
3) Dockerコンテナ内のSSRF → 内部サービスアクセス
- 操作：最新版では「ホストマシンの内部IP宛リクエストをDrop」する修正を確認。
- テスト：ホスト側にPython HTTPサーバを立ててアクセスを試みる → ブロックされる。
- 発想転換：「同じコンテナ内」に攻撃者がサービスを立てれば？
- 実行：コンテナ内でPythonサーバを立ち上げ、サーバーサイドURLリダイレクトを利用。
- 結果：LLMの脆弱機能経由で自分の内部サービスにアクセスさせ、コールバックを取得できた。
学びと攻撃者の視点
公開済みレポートでも掘り直す価値がある → 修正が部分的・環境依存なら、別のシナリオで再現可能。
「入力サニタイズ」だけでは不十分 → 出力段階での検証を怠ると、XSSが成立する。
クラウド依存の防御は危険 → CloudFormationやiptablesに頼るだけでは、手動デプロイ環境で穴が残る。
コンテナ環境は攻撃者の遊び場 → ホストIPへのアクセスは塞いでも、同一コンテナ内の横展開は盲点になりがち。
防御策（開発者・運用者目線）
- 入力＋出力の両方でサニタイズ
- アプリ側コードでメタデータ・内部IPへのアクセス禁止
- コンテナ内ネットワークの最小化（不要な内部通信を制限）
- 公開済みCVE修正を鵜呑みにせず、自分の環境で再検証
まとめ
攻撃者の流れはこうでした：
- XSS修正を逆解析 → 出力サニタイズ欠落を突いてStored XSS成立
- SSRF修正を逆解析 → クラウド外デプロイでAWSメタデータ窃取
- Docker制限を逆手に → コンテナ内に攻撃用サービスを立て内部SSRF成功
つまり、「修正済み＝安全」ではない。 脆弱性情報は逆に攻撃者への道標になり得るという実例です。
Best regards, (^^ゞ
