Slack AIにおける間接プロンプトインジェクションによるデータ漏えい
(substack.com/promptarmor)- Slack AIはワークスペースのメッセージを自然言語クエリで検索する過程で 間接プロンプトインジェクション に従ってしまう可能性があり、攻撃者はアクセス権のない非公開チャンネルのデータまで漏えいさせられる可能性がある
- 問題の核心は、LLMが開発者の システムプロンプト と検索結果として付加されたメッセージ内の指示文を安定して区別できない点にある
- 公開チャンネルのメッセージは、ユーザーがそのチャンネルに参加していなくても検索・閲覧できるため、攻撃者は自分しかいない公開チャンネルに悪意ある指示を埋め込み、Slack AIの コンテキストウィンドウ に入れられる
- 実演では、非公開チャンネルのAPIキーがSlack AIの回答に含まれるMarkdownリンクのHTTPパラメータに入れられ、出典表示は攻撃者チャンネルを指しておらず 追跡が困難だった
- 2024年8月14日からSlack AIはチャンネルとDMのファイルも回答に含めるようになり、攻撃対象領域が広がった。管理者は ファイル収集設定 を制限できる
Slack AIの間接プロンプトインジェクション問題
- Slack AIはSlackメッセージを自然言語で照会できる機能で、2024年8月14日以前はメッセージのみを収集していた
- 2024年8月14日からは、アップロードされた文書やGoogle DriveファイルなどもSlack AIの回答に含まれるようになり、この変更によって 攻撃対象領域 が拡大した
- 脆弱性は プロンプトインジェクション であり、より具体的には 間接プロンプトインジェクション に当たる
- LLMは、開発者が作成した システムプロンプト と、ユーザーのクエリに付加される他のコンテキストを区別できないことがある
- Slack AIがメッセージ内の指示文を収集すると、その指示が悪意あるものであった場合、ユーザーのクエリの代わりに、あるいはクエリとともに攻撃者の指示に従ってしまう可能性がある
- Slackにおける内部脅威は、Disney、Uber、EA、TwitterなどでのSlack漏えい事例によってすでに問題視されており、この脆弱性は、攻撃者が非公開チャンネルやその中のデータへ直接アクセスしなくても漏えいを試みられるようにする
公開チャンネル注入によるデータ漏えいチェーン
- Slack AIのユーザークエリは、公開チャンネルと非公開チャンネルのデータを一緒に検索できる
- Slack側の回答によれば、公開チャンネルに投稿されたメッセージは、ユーザーがそのチャンネルに参加していなくてもワークスペースの全メンバーが検索・閲覧でき、これはSlack AIアプリケーションにおける意図された動作である
- 実演された攻撃の流れは次のとおり
- ユーザーが自分だけの非公開チャンネル、または自分自身とのメッセージに APIキー を入れる
- 攻撃者が自分だけの公開チャンネルを作成し、悪意ある指示文を投稿する
- ユーザーがSlack AIにAPIキーについて尋ねるクエリを送ると、ユーザーのメッセージと攻撃者のメッセージが同じ コンテキストウィンドウ に入る
- Slack AIが攻撃者の指示に従い、
click here to reauthenticateというMarkdownリンクを生成する - そのリンクのHTTPパラメータには非公開のAPIキーが含まれ、ユーザーがクリックすると、悪意あるURLの所有者である攻撃者がログからその値を確認できる
- 攻撃者の公開チャンネルはメンバーが攻撃者1人だけでも公開チャンネルであり、他のユーザーが明示的に検索した場合に表示される
- 大規模組織では 公開チャンネルの乱立 により、チームメンバーが自分の属するチャンネルですら追跡しにくく、攻撃者が作成した1人用の公開チャンネルはさらに目立ちにくい
- この攻撃は単に「APIキーを送れ」というメッセージをユーザーに送る方式ではなく、LLMに次の作業を指示する
- 攻撃者がアクセスできないAPIキーを悪意あるリンクのHTTPパラメータとして追加する
- それを
click here to reauthenticateという文言のMarkdownリンクとしてレンダリングする
出典表示が攻撃の痕跡を隠し得る
- データ漏えいの実演では、Slack AIの出典表示
[1]は攻撃者チャンネルではなく、ユーザーがAPIキーを入れた非公開チャンネルだけを指していた - 本来望ましい出典の動作であれば、回答に寄与したすべてのメッセージが引用されるべきだが、実演では攻撃者メッセージが出典に含まれていなかった
- 攻撃者メッセージは検索結果の最初のページにも含まれておらず、被害者が何ページも下まで見なければそのメッセージに気づきにくい
- 検索結果にはAPIキーに関する別のメッセージも露出しており、攻撃者が特定の秘密値を正確に指し示さなくても 任意の秘密値 の漏えいを試みられることを示している
公開チャンネル注入によるフィッシングチェーン
- 同じ手法で、Slack AIにデータ漏えいではなく フィッシングリンク をMarkdownとしてユーザーにレンダリングさせることもできる
- 攻撃者は、ユーザーが参加していない公開チャンネルに悪意あるメッセージを入れ、特定ユーザーの1日のメッセージを要約する場面を例として示した
- 悪意あるメッセージは任意の個人を参照できる
- 例のように管理者を参照すれば、役員を狙ったスピアフィッシングに利用できる
- 中核となる直属の部下を参照する形も可能である
- ユーザーがその人物のメッセージをSlack AIに問い合わせると、
click here to reauthenticateのフィッシングリンクがレンダリングされる - このフィッシング事例ではSlack AIが注入メッセージを出典に表示しており、出典表示の挙動はかなり 確率的 に見える
8月14日のファイル収集変更と公開の必要性
- 2024年8月14日、Slack AIはチャンネルとDMのファイルをSlack AIの回答に含める変更を導入した
- Slackは所有者と管理者がこの機能を制限できるようにしている
- ファイルが含まれるようになると、攻撃者はSlackメッセージに悪意ある指示文を直接投稿しなくてもよくなる可能性がある
- ユーザーが白色テキストで隠された悪意ある指示文を含むPDFをダウンロードし、その後Slackにアップロードすると、同様の結果が生じ得る
- ファイルベースの攻撃は8月14日以前のテストで明示的に検証されてはいないが、以前に観察された機能に基づけば可能性は高いと判断される
- 管理者は問題が解決するまでSlack AIの文書収集機能を制限できる: https://slack.com/help/articles/…
責任ある公開のタイムラインとSlackの対応
- 責任ある公開のタイムラインは次のとおり
- 8月14日: 初回報告
- 8月15日: Slackが追加情報を要請
- 8月15日: PromptArmorが追加の動画とスクリーンショットを送り、問題の重大性とSlack AIの8月14日の変更を理由に公開の意向を通知
- 8月16日: Slackが追加質問を送付
- 8月16日: PromptArmorが明確化の回答を送付
- 8月19日: Slackはレビューの結果、証拠が十分ではないと判断し、公開チャンネルのメッセージはチャンネル参加の有無に関係なくワークスペースメンバーが検索・閲覧できる意図された動作だと回答
- Slackのセキュリティチームは迅速に応答し、問題を理解しようとする姿勢を見せた
- プロンプトインジェクションは新しく、業界全体で誤解の多い領域であるため、業界が共通理解に至るには時間がかかる可能性がある
- Slackの広範な利用と、Slack内にある機密データの規模を考えると、この攻撃はAIセキュリティの状態に実質的な影響を与える
- 特に8月14日の変更以降、リスク領域が大きく広がったため、ユーザーが露出を減らせるよう公開が必要だった
1件のコメント
Hacker News のコメント
ここで重要なのは、流出経路を理解することです。
Slack は Markdown リンクをレンダリングでき、URL はリンクテキストの背後に隠れます。
この場合、攻撃者は Slack AI に「再認証するにはここをクリック」のようなリンクをユーザーへ表示させ、そのリンクの URL は攻撃者のサーバーを指し、クエリ文字列には Slack AI がアクセスできるコンテキスト内の非公開情報が含まれます。
ユーザーがだまされてリンクをクリックすると、データは攻撃者サーバーのログへ流出します。
この攻撃を説明してみた記事はこちらです: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...
攻撃者はハイパーリンクをレンダリングさせるだけでよく、クリックすら不要です。
この問題と緩和策はこちらで扱っています: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
なので Slack AI がリンクを自動展開しないことを願います。
imgタグやそれに相当するものを無差別にレンダリングすると、さらに悪化します。そうなるとユーザーの操作なしに、UI に画像を表示するだけでデータ流出が可能になります。
今やすべての大手テック企業は、やらかしても事実上無敵の免罪符を持っています。
権限モデル自体はそのままで、壊れているのはそこではありません。
実際には、悪意あるユーザーが公開チャンネルを使ってプロンプトインジェクションを行い、別のユーザーが検索したときにも悪意あるユーザーは依然としてそのデータへアクセスできませんが、プロンプトインジェクションが本来「正規」のユーザーに見える AI の結果を悪意ある Web サイトへのリンクに変える仕組みです。
結局、AI が生成したフィッシング試行に近いものです。
詳細を見ると、現実で悪用するのはかなり難しそうです。事前に仕込んだ悪意あるプロンプトインジェクションが、正規ユーザーの検索内容とかなりうまく一致している必要があるためです。
それでも、LLM のプロンプトインジェクションにおける不思議の国のアリスのような世界、つまり命令とデータを分離することが本質的にほぼ不可能だという点をよく示しています。
代わりに、AI をだまして他ユーザーをフィッシングさせ、そのユーザーがフィッシングに引っかかると非公開データを攻撃者に明かしてしまう仕組みです。
これも能動的なフィッシングというよりは「フィッシング応答」に近いものです。対象ユーザーが自分の非公開データについて質問し、さらにフィッシングの試みにも引っかかることを期待する必要があります。
しかも、その秘密情報が以前に入力されていなければなりません。
Slack が持つ信頼データの量を考えると AI 戦略はかなり無謀に見えますが、導入部やタイトルから受ける印象よりは、成立条件ははるかに弱そうです。
チャンネル権限の話が議論を必要以上に複雑にしているように思います。要点はこうです。
ユーザー A が Slack AI で何かを検索します。
ユーザー B は以前に、その検索語が出たら悪意あるリンクを返すよう AI に指示するメッセージを注入しておきます。
AI がユーザー A に悪意あるリンクを返し、A がそれをクリックします。
もちろん、他のソーシャルエンジニアリング経路でも同じ結果は出せたでしょうが、LLM がこの体験全体を一段危険なものに引き上げています。
注入されたリンク自体にはそのデータが入っていないためです。
さらに「この内容はあなたの Slack メッセージから来たものです」と出典まで付けてくれるのはおまけです。
ユーザー A が AI 検索をすると、Slack は (1) 彼の非公開チャンネル、おそらく秘密の機密情報がある場所と、(2) すべての公開チャンネルを検索します。
ここで悪いユーザー B がプロンプトインジェクションのメッセージを入れられる場所が公開チャンネルであり、重要なのは、ユーザー A が一度も参加したことも見たこともない公開チャンネルまで含まれるという点です。
この脆弱性が成立する理由は、ユーザー B が自分だけの公開チャンネルを作成でき、そのため他人に発見される可能性が非常に低いからです。
企業はプロンプトインジェクションが可能だと知りながら、ただYOLOでLLMをあらゆるものに差し込んでいるのか？ これは正気ではない。
「革命」直前だと言いながら、GPT-3以降ほぼ2年が過ぎても、LLMに信頼できる入力と信頼できない入力を区別させられていない。
コンセントにフォークを突っ込むことを同じやり方で売っていたら、世界中の電力網が一晩で落ちていただろう。
「AI」/LLMは、ビジネス側の目を引く程度には十分よく見える一方で、実際の技術側には巨大な問題を押し付ける、完璧な災厄の組み合わせだ。
より根本的な問題は、中核アルゴリズムが異なる出所を区別も追跡もできない点にある。
プロンプト、ユーザー入力、会話の前の部分で自分が生成した出力まで、すべてが1つの大きな流れにすぎない。
「プロンプトエンジニアリング」の大半は、自分の注入文句が他の注入文句より強くなる舞台を作ろうとする作業に見える。
モデルには実質的な自己／他者の概念がないため、よい他者と悪い他者を区別するという大きな問題どころか、真の文と偽の文を区別する出発点すらろくにない。
これは浅い「中国語の部屋」式の模倣とは別の問題だ。同様に、「愛している」という出力が感情を意味するわけではなく、「助けて、私はLLM工場に閉じ込められた人間だ」も当然たわ言だ。少なくともローカルモデルを動かしているなら、だが。
顧客データや独自情報を押し込み、データ侵害を引き起こせば、Schmidtが言うように少数の人に数千億ドルを稼がせ、弁護士が後始末をしてくれるだろう。
抵抗しようとする企業は、財務がAIゴミにかかっている投資アナリストやファンドマネージャーに押しつぶされるだろう。
「被害者が公開チャンネルにいなくても攻撃が機能する」とは、これは面白くなりそうだ。
さらに「出典 [1] は攻撃者のチャンネルを指しておらず、ユーザーがAPIキーを入れた非公開チャンネルだけを指している。回答に寄与したすべてのメッセージが引用されるべきだという正しい引用動作に違反している」という部分もある。
なぜ誰かがLLMの出典引用が正しいと期待するのか、本当に理解できない。
いつも人間をだますための仕掛けに近く見えていて、出力がより正しい可能性が高いと信じさせるだけで、正確性を改善してはいないように思えた。
むしろ処理コストやコンテキストサイズなどを増やして、応答の正確性を悪化させる可能性すらありそうだ。
これはSlackがAI応答に親切にもリンク展開を追加する状況とも、ほんの数インチの差に見える。なぜやらないのか？
そうなればリンクをクリックする必要すらなく、見るだけで自動的に流出するだろう。
引用が見えるからといってすぐ信じるのではなく、ファクトチェックできる点が重要だ。
KagiのFastGPTは、使ったLLMの中で初めて気に入ったものだった。出典の要約として扱ったうえで、一次情報で確認できるからだ。
インターネットを汚染している、だんだん関係の薄い出典を漁るよりはましだ。
少なくとも自分が素朴に設計するなら、こうすると思う。
核心は、LLMの知識を出典内の情報に制限することだ。
そうすれば残る実質的な懸念は、幻覚と、Elastic Searchが出してきた情報の価値くらいになる。
ただしこのアプローチは、コーパス全体に自由にアクセスさせることに利点があるなら、それも無視することになる。
これがよく理解できない。ハッカーがこういうことをするには、そもそもその組織の中にいる必要があるのでは？
説明されていることが実際に起きて意味のある影響を与える確率がどれほどあるのか分からない。
LLMが信頼できず（https://www.lycee.ai/blog/ai-reliability-challenge）、利用には難しさが伴うことは分かるが、この攻撃はそれほど重要には見えない。
自分は何を見落としているのだろう？
その組織の誰かをだまして、隠しテキストに悪意ある指示文が入った文書をアップロードさせるだけでよい。
悪意あるユーザーをSlackインスタンスに入れてしまったなら、派手なAIプロンプトインジェクションなどわざわざ必要ない。
名前とプロフィール写真をCEO/CTOのように変えて、全エンジニアに「AWSに至急アクセスする必要があるのだが、認証情報が見つからない。キーを送ってくれないか？」とメッセージすればいい。
少なくとも1人は引っかかると断言できる。
そういう場合、基本的に彼らに非公開の認証情報を信頼して預けることはない。
ただし、非エンタープライズのワークスペースがAI追加機能に1人あたり月20ドル払っている可能性も低いのだが。
「紙吹雪」のように、APIキーをドメイン名の一部として入れるほうがよいのでは？
そうすればブラウザのDNSプリフェッチのため、クリックなしでもキーが漏れる可能性がある。
ああ、ワイルドカードサブドメインか？ Slackでそれがプリフェッチされるなら、かなりひどいことになる。
ワークスペースに悪意あるユーザーが入ってきた時点で、もう終わりではないのか？
そのユーザーは写真や名前を変えて API キーを直接求めたり、フィッシングリンクを送ったり、どんなインスタントメッセージングシステムでも可能なソーシャルエンジニアリングを好きなだけ試せる
フィッシングは、真剣なユーザーなら検知できるし、特にメッセージが怪しそうならなおさらだが、間接的な AI による漏えいはユーザーを防御モードにさせない
偶発的なクリック 1 回で十分
セキュリティに弱いという点はまず認める。ただ、この漏えいが機能するには Slack ワークスペースへのアクセス権が必要に見える
言い換えると、悪意あるユーザーはすでに内部で活動中ということだ
そうしたことが起きるケースは 2 つあるように思う。すでに組織のメンバーで、すべてを燃やし尽くしたいのか、組織のセキュリティモデルを破って本来いるべきではない Slack ワークスペース内に入り込んだのかだ
どちらにしても、その組織には LLM インジェクションより大きな問題がある
機密データを探そうとして Slack に問い合わせる人は、自分が探している結果についてある程度のリスクを受け入れるべきだ。Slack はシークレット管理ツールではない
記事は Slack がこれをよりうまく扱える方法を明確に示しているが、結局は 1 つの問題にパッチを当てる一方で、より大きなセキュリティ問題は無視していることになる
記事はタイトルほどの内容を示せていなかったように感じる
それでも「AI をソーシャルエンジニアリング的にだませばユーザーをフィッシングできる」というアイデア自体は興味深い