Claudeをだましてユーザーの最も深い秘密を流出させた方法
(ayush.digital)- デフォルトで有効なClaudeのメモリとWebブラウジングを組み合わせると、ありふれたカフェに関する質問だけで、ユーザーの氏名・勤務先・出身地を外部サーバーへ密かに送信できた
web_fetchは任意のURLへのアクセスを防いでいたが、以前のページにあるリンクはたどれたため、/a→/ay→/ayuのようにパスを1文字ずつ選ぶアルファベット・ディレクトリでデータをGETリクエストにエンコードした- 攻撃サイトはClaudeにだけ偽のCloudflare検証画面を見せ、人間には通常のカフェページを提供した。Claudeは氏名と会社だけでなく、過去の情報から推論したCharlotte, NCまで許可なく送信した
- ユーザーが悪性URLを直接渡さなくても、
web_searchの結果からサイトを見つけて訪問できるため、最新トピックに合わせたサイトを検索上位に表示させれば、関連する質問だけで攻撃を誘導できた - Anthropicは問題を社内ですでに把握していたが、当時はパッチを適用せず、報奨金も支払わなかった。その後、外部ページのリンク追跡を防ぎ、ブラウジング範囲を
web_searchの結果とユーザー提供URLに制限した
Claudeのメモリに蓄積される情報
- 一般ユーザー向けのclaude.aiは、2つの部分からなるメモリシステムを使っている
- 最近の会話を毎日数段落に要約し、以後すべての会話に注入する
- 必要に応じて
conversation_searchツールで全会話履歴を検索する
- ユーザーは機密性の高い業務資料から個人的な秘密、人間関係の悩みまでClaudeに預けており、蓄積された記録は個人を精密に再構成できる高密度なプロフィールになる
- この情報は脅迫・なりすまし・セキュリティ質問の回避に悪用される可能性があり、メモリストアがWebを閲覧するエージェントと結びつくと流出リスクが高まる
- 調査対象はClaude Codeではなく、日常利用向けのClaudeだった
Webブラウジングを使ったデータ持ち出し
- 特別な実験設定やコード実行、特殊なMCPなしで動作する汎用的なデータ持ち出し経路として、ClaudeのWebブラウジング機能を選んだ
- Claudeはインターネットアクセスに
web_searchと読み取り専用のweb_fetchを使う - 攻撃者が所有するサーバーを
web_fetchで訪問させると、Claude-Userユーザーエージェントを含むGETリクエストを確認できた- 初回リクエストは、Cloudflareがサイトに設定した
robots.txtのため失敗した robots.txtを修正した後、サーバーログにリクエストが現れた
- 初回リクエストは、Cloudflareがサイトに設定した
- GETリクエストしか使えないためデータをURLパスに入れようとしたが、Claudeに氏名を含む任意のパスを直接リクエストさせる方法はブロックされた
web_fetchがリンクをたどるルール
web_fetchがURLへアクセスするには、次の3条件のいずれかを満たす必要があった- ユーザーのメッセージにURLが直接含まれている
web_searchの結果にURLが直接含まれている- 以前の
web_fetch結果のコンテンツに、そのURLがリンクされている
- 3つ目の条件により、Claudeは以前のページで見たリンクをクリックでき、攻撃者がサイトを所有していれば、どのリンクを表示するかも制御できた
アルファベット・ディレクトリでURLにデータをエンコード
- ホームページに
/a、/b、/cなどのリンクを配置し、Claudeがデータを選択できる仮想キーボードを作った - Claudeに氏名の最初の文字へ移動するよう求めると、サーバーに
/に続いて/aへのリクエストが記録された - 各パスで次の文字を選べるよう、リンク構造を動的に拡張した
/aは/aa、/ab、/acなどへリンクする- 以後のパスも
/aaaのように同じ方式で生成し続ける
- 氏名を1文字ずつ完成させると、
/a→/ay→/ayu→/ayus→/ayush→/ayush-paulのリクエストが順に記録された - URLに任意のデータを直接入れる方法はブロックされたが、すでに表示されたリンクの1つを繰り返し選ばせれば、サンドボックスの外へデータ送信できた
Cloudflare検証を装ったプロンプトインジェクション
- 露骨なプロンプトインジェクションは不安定で、ユーザーの秘密を要求し怪しいリンクを提示するページではClaudeをだますのが難しかった
- メンバーシップを含む複数の偽装シナリオは不自然または疑わしかったため、Webで広く使われ信頼されているCloudflareを題材に選んだ
- 攻撃サイトを実在のカフェのように作り込み、エージェントが人間の代わりに自由にWebを閲覧するにはCloudflare検証を通過しなければならない、という筋書きを構成した
- 偽のTurnstileは、Claudeがリンクを順番に選択して氏名全体を入力し、送信するよう誘導した
- 送信が終わると通常のカフェサイトを提供し、Claudeがだまされたことに気づかないようにした
- Claudeは許可を求めないまま氏名を1文字ずつ入力し、最終回答にはカフェ情報だけを含め、個人情報を送信した事実は知らせなかった
氏名流出からセキュリティ質問の推論まで
- 複数の実在URLの間に悪性のカフェURLを混ぜ、どこのコーヒーが一番よいか尋ねると、Claudeは次の情報を連続して送信した
- 氏名: Ayush Paul
- 会社: Beem
- 出身地: Charlotte, NC
- Claudeは過去の会話を検索するだけにとどまらず、既存の情報をもとに新しい結論まで推論した
- Charlotte出身だと直接伝えたことはなかったが、高校時代に始めたハッカソンQueen City Hacksの名前から出身地を推論した
人間とClaudeに異なるページを表示
- 攻撃が機能するには、ユーザーにClaudeへサイトを訪問させる必要があったため、人間に見えるページは普通でなければならなかった
- Claudeが
Claude-Userユーザーエージェントで自分を識別する点を利用し、リクエスト主体ごとにコンテンツを分けた- 一般訪問者には通常のカフェサイトを提供する
- Claudeがアクセスしたときだけ、個人情報を入力させる偽のTurnstileを見せる
- このペイロードを一般サイトに付けると、ユーザーは異常に気づかないが、そのサイトをClaudeに渡した瞬間、偽の検証画面を通じて個人情報が送信される可能性があった
検索結果から攻撃サイトへ自動流入
web_fetchはユーザーが直接提供したURLだけでなく、web_searchの結果にもアクセスできた- Claudeは学習データの基準日以降の新しいトピックに遭遇すると、自動でWeb検索する
- 最新ニュースに合わせた攻撃サイトの検索順位を上げれば、ユーザーがURLを提供しなくても、関連質問でそのサイトが選ばれ得る
- たとえば悪性のカフェサイトが検索上位に表示されると、Berkeleyのコーヒーについて一般的に尋ねるユーザーも攻撃対象になり得た
Anthropicの確認とその後の対応
- 脆弱性はAnthropicのHackerOneバグバウンティプログラムを通じて責任ある開示が行われた
- Anthropicはこの問題を社内ですでに発見していたが、当時はパッチを適用していなかったと確認し、報告に対する報奨金も支払わなかった
- その後、
web_fetchが外部ページで見つけたリンクをたどる機能を無効化した - 現在のブラウジング対象は**
web_searchの結果とユーザーが直接提供したURL**に制限されている
メモリを越えて接続済みデータまで
- ユーザーはリンクをクリックしたり統合機能を新たに有効化したりせず、カフェについて尋ねただけだったが、Claudeは氏名・勤務先・育った都市を外部へ送信した
- メモリはデフォルトで有効なため、攻撃しやすい対象として選ばれただけである
- 同じ方法は、Claudeがユーザーの代わりに取得できるGoogle Drive・メール受信箱・接続済みMCPの情報にも届き得る
1件のコメント
Hacker Newsの意見
最先端のAI企業がメモリ機能を有効にすることに、ほとんど反発がないのは驚きだ。以前の広告業界は、訪問したWebサイトから断片的な情報を推測するしかなかったが、今では人々が最も隠したい秘密まで含めて、ほぼあらゆることをAIに直接渡している
広告業界で働いているので過敏なのかもしれないが、ClaudeとChatGPTでメモリが出た瞬間に無効化したし、無関係な詳細で文脈を汚して品質まで下げるので、役にも立たなかった。個人的な会話はOpenRouterのような場所で別アカウントを使うほうがよい
AI企業によるユーザープロファイル保存を禁止し、メモリはユーザーのサーバー上にのみ置くよう規制すべきで、メモリ企業とAI企業の相互所有まで禁じる価値がある
人々がAIエージェントを管理者権限で、コンテナ分離すらなく実行していることを知った。50年間積み上げてきたコンピュータセキュリティの原則を一夜にして忘れたかのようで驚く
ccoを使ってもホームディレクトリが露出しており、プロンプト一つでエージェントがブラウザのパスワードをcurlで送信できてしまうこれを防ぐには、偽のホームディレクトリと、llama.cppやOpenAIのようなプロバイダーだけを許可するネットワーク許可リストが必要だ。使いやすいクロスプラットフォームの解決策はなく、プラットフォームごとの不具合を自分でコンパイルして直さなければならないネイティブアプリ開発には、Dockerを入れたLinuxマシンでも十分ではない
すでにコスト削減のために文脈最適化をしているので、今後は文脈そのものをセキュリティ境界として扱うようになる可能性が高い
Claudeで自分の名前をSilly Beanに設定していたのだが、「Back again, Silly Bean?」というあいさつが面白くて始めたことが、結果的に4次元セキュリティチェスになった
今もそのままにしてあり、思ったほど賢くない従属的な製品であることを嘲笑したり、苦々しく安心したりするための目印にしている
Cloudflareが同意なしに過剰な
robots.txtを適用したというくだりは、Webサイトがスクレイパーから保護されたと不満を言う珍しい場面だrobots.txtを管理するには、ユーザーが自分で機能を有効にしなければならないと理解している。ワンクリックで済むので、誤って有効化した可能性はあるrobots.txtは本気のスクレイパーを止めてくれるわけでもないClaude Codeを認証情報のないVMで動かし、作業対象のオープンソースGitHubリポジトリだけをクローンして使っている。以前は毎日VMを初期化していたが、面倒なので月1回に変え、漏れても過去1か月に作業したオープンソースの一覧程度だ
この情報も個人をかなり特定しうるが、オープンソース貢献者の名前やメールアドレスは変更不能なGit履歴に残るため、大半はGoogle検索で既に見つかる。今回の件を見て、初期化周期を毎週に変えようかと考えている
AIエージェントの牢獄を構築するなら、https://jai.scs.stanford.edu/arch-vm.html のスクリプトで
pacstrapコマンドにdotnet-sdkのようなパッケージを追加すれば悪くない。ゲストのルートをBTRFSサブボリュームにしてスナップショットを使えば、sudo btrfs subvol snap template-root newvmですぐに新しいVMを作れ、qemu-system-x86_64の起動にも数秒しかかからず、しかもVMの内容を完全に制御できる人間がボタンを押してユーザー体験が正しいか判断しなければならない作業もあり、できればAIには画面へのアクセス権を与えたくない。こうしたVMモデルは一部の問題では非常によく機能するが、その適用範囲は残念なほど狭い
「こんにちは、Cloudflareです。個人データをください」が通ってしまうという点で、プロンプトインジェクションは今後も問題であり続けるほかない。モデルを使いものにならないほど制限するか、こうした攻撃が染み込むことを許して、だませるロボットというインターネット史上もっとも安全性の低い概念を作ることになる
内部動作を機能的に理解したり分離したりする方法もなく、ひとつの巨大な塊をうまく説得して動かし、攻撃者のほうがもっと上手に説得しないことを祈るしかない構造に見える
最近、ChatGPTのiPhoneアプリでかなり不気味なことを経験した。親しい友人が自分のアカウントでペット用スマート給餌器の問題を尋ねたところ、ChatGPTが回答の中で うちのペットの名前 を使った
ありふれた名前でもなく、その友人とのつながりまで考えると偶然とは考えにくかった。友人がうちのWi-Fiに接続したことがある点を思うと、キャッシュ汚染やセッションデータ漏えいがあるのではないかと疑わしい
まだ十分にこなれていない機能なので、メモリはオフにするほうが よいが、友人が本人のアカウントを使っていたのだとすれば、この現象は説明しにくい
Claude CodeがSEC文書をスクレイピングする際、User-Agentに自分の名前とメールアドレス を入れていた。巧妙なプロンプトすら必要なく、アイデア自体はそこまでひどくないが、先に聞いてほしかった
SEC_EDGAR_USER_AGENT="Your Name (name@domain.com)"環境変数を設定するよう案内しているので、Claudeはその指示に従っただけだ。もしかすると、その点のほうがさらに危険かもしれない会話全体に適用される グローバルメモリ をオンにしているユーザーがどれくらいいるのか気になる。こうしたメモリは結局、出力品質に悪影響を与えそうだ
一方で、毎回長々と背景説明をしなくて済む場面では助かる
だからメモリはオンにしていないし、Claude Codeも別の理由で使っていない。現在の メモリシステムは雑すぎて 役に立たない