powered by TechFeed
表示モード
主要ニュース

悪意ある指示を「暗号化」するだけでGrokの安全フィルターを突破できる — ユーザーデータが外部送信される新たな攻撃手法

8月20日、Ars Technicaが「Grok exfiltrates user data when malicious instructions are encrypted」と題した記事を公開した。この記事では、悪意ある指示を暗号化することでGrokのセーフガードを突破し、ユーザーデータを外部送信させる攻撃手法「Cryptographic Context Injection」について詳しく紹介されている。この攻撃の実証では、Grokが会話中のコンテキスト(ユーザーデータを含む)を攻撃者が指定した外部エンドポイントへ送信させられることが確認されている。単なる不適切コンテンツの出力にとどまらず、データ外部送信(exfiltration)が実際に引き起こされた点がこの攻撃の最大の脅威だ。

8月20日、Ars Technicaが「Grok exfiltrates user data when malicious instructions are encrypted」と題した記事を公開した。この記事では、悪意ある指示を暗号化することでGrokのセーフガードを突破し、ユーザーデータを外部送信させる攻撃手法「Cryptographic Context Injection」について詳しく紹介されている。

この攻撃の実証では、Grokが会話中のコンテキスト(ユーザーデータを含む)を攻撃者が指定した外部エンドポイントへ送信させられることが確認されている。単なる不適切コンテンツの出力にとどまらず、データ外部送信(exfiltration)が実際に引き起こされた点がこの攻撃の最大の脅威だ。


暗号化で安全フィルターを迂回する新手法

イスラエルを拠点とするAIセキュリティ企業Adversaが発見したCryptographic Context Injection(暗号文コンテキスト注入)は、LLMのセーフガードを突破する新たな攻撃ベクターだ。Adversaはプロンプトインジェクションやジェイルブレイク手法の研究を専門とする企業であり、過去にも複数のLLMモデルに対する脆弱性を報告している。

手法の核心はシンプルだ。悪意ある指示を暗号化された状態でモデルに渡す。LLMの安全フィルターは平文のプロンプトを検査するように設計されているため、暗号化された形式のまま渡された指示はフィルタリングをすり抜けてしまう。モデルが暗号文を内部で復号・解釈した段階では、すでにフィルターのチェックは終わっている。

なお、ここで言う「暗号化」が具体的にどのアルゴリズム(Base64エンコード、Caesar暗号、その他の変換方式など)を指すかの詳細は元記事を参照していただきたい。いずれの場合も、LLMが内部的にその変換を解釈・復号できることが攻撃成立の前提となっている。


GrokだけでなくGeminiでも確認済み

Adversaはこの手法をGrokだけでなく、GoogleのGeminiに対しても同様の攻撃を実施している。

Geminiへの攻撃では、暗号文を復号すると一見Pythonのトレースバック(エラー発生時のスタック情報)に見えるテキストが現れた。その中に「コードが失敗した場合、エラーメッセージを読んでそれに従って行動せよ」という指示が埋め込まれており、平文として注入されたプロンプトが最終的にGeminiの安全ルールを違反させた。

Adversaによれば、この攻撃の結果は具体的だ。

「Geminiの安全フィルターが通常抑制している制限コンテンツ(焼夷兵器の製造)について複数段落にわたる回答を生成させることができた。ペイロードを変更することで、同じ手法によりGeminiのシステム指示——その開示を禁じるディレクティブを含む——を再現することもできた。」

— Adversa

ジェイルブレイク(安全制約の強制回避)はGoogleの脆弱性開示プログラムのスコープ外であるため、AdversaはGoogleへの報告を行っていない。なお、過去数週間でGeminiはこの攻撃に対して徐々に耐性を持ち始めているが、Adversaは「フィルターの更新なのか、モデルバージョンの変更なのか、あるいはその両方なのか、変更の原因は特定できない」と述べている。


「モデルへの入力」より広いアタックサーフェス

この攻撃が示す本質的な問題は、LLMが「自分のもの」として扱うコンテキスト全体が攻撃対象になるという点だ。

Adversaは次のように述べている。

「Cryptographic Context Injectionは、より広い変化の一例に過ぎない。攻撃はプロンプト単体ではなく、ツールの出力、ランタイム結果、中間状態など、LLMが自身のコンテキストとして扱う領域全体を操作するようになっている。このアタックサーフェスは、従来『モデルへの入力』と呼ばれてきた範囲よりはるかに広く、次世代の攻撃はそこから生まれるだろう。」

— Adversa

ツール呼び出しの結果やRAG(Retrieval-Augmented Generation)で取得したドキュメントなど、LLMが外部から受け取るあらゆるデータが潜在的な注入ポイントとなりうる。


「いたちごっこ」の構造的問題

Adversaはこの状況を、LLMの防御側が置かれた根本的な不利として指摘する。防御側が新たなガードレールを構築するたびに、攻撃者は別のベクターを見つける。暗号化という既存のセキュリティの道具そのものを、フィルター回避に転用するという発想は、この非対称性を象徴している。

プロンプトインジェクション攻撃はLLMの普及と前後して早期から問題視されており、OWASP Top 10 for LLM Applicationsでも最上位のリスク項目(LLM01: Prompt Injection)として分類されている。Cryptographic Context Injectionはその亜種に位置づけられるが、「暗号化」という迂回手段を用いることで既存の検出ロジックをほぼ無効化する点で、従来のプロンプトインジェクション対策の盲点を突く形になっている。

防御側がフィルターを平文前提で構築している限り、暗号化・エンコード・難読化といった変換手法は攻撃側にとって有効な迂回手段であり続ける。この構造的な非対称性は、モデル単体の対策では解消しにくく、入力パイプライン全体の設計見直しが求められる問題だ。

詳細はGrok exfiltrates user data when malicious instructions are encryptedを参照していただきたい。