AI Hallucination Squatting: 新たなサプライチェーン攻撃のフロンティア 🤖📦

ソフトウェアのサプライチェーンは、見えない新たな敵によって攻撃されています。長年、開発者はtyposquatting（タイプミスによる登録）について警告されてきました。例えば、requesstsを登録してrequestsのタイプミスを狙う手法です。しかし、より高度で巧妙な脅威が出現しています。それは、人間のミスではなく、人工知能（AI）の創造的失敗から生まれたものです。

これはAI Hallucination Squatting（しばしば「AIパッケージ幻覚」や「Slopsquatting」と呼ばれる）です。

攻撃者は「Vibe-to-Malware」パイプラインを構築し、もはや開発者のミスを待つ必要はありません。AIが嘘をつくのを待つだけです。ChatGPT、Claude、GitHub Copilotなどの大規模言語モデル（LLMs）を使ってコードを書いていると、無意識のうちに新たなサプライチェーン攻撃を招いてしまいます。

AI Hallucination Squattingとは何か？

AI Hallucination Squattingは、攻撃者が存在しないソフトウェアライブラリやパッケージを特定し、その名前をNPM（Node.js）、PyPI（Python）、RubyGemsなどの公開リポジトリに登録することです。

開発者が特定の問題の解決策をAIに尋ねると、AIは自信を持ってこの「幻の」パッケージを提案します。開発者はAIの「雰囲気」や権威ある口調を信じて、インストールコマンド（例：npm install hallucinated-lib）をコピーします。攻撃者が最近その名前を登録しているため、パッケージマネージャは悪意のあるコードをインストールし、環境を瞬時に危険にさらします。

「Vibe-to-Malware」パイプライン

この攻撃経路は非常に自動化されており効率的です。開発者がAI生成コードを信頼していることに依存しています。

1. プロンプト: 開発者がLLMに「PythonでX APIと連携するには？」と尋ねる。
2. 幻覚: AIは訓練データに直接答えがなく、信頼できそうなパッケージ名x-api-connector-pyを予測します。
3. スコット: 攻撃者は既にPyPIでx-api-connector-pyを登録済みです。
4. 感染: 開発者がpip install x-api-connector-pyを実行すると、ライブラリが見つかり（実際に存在し）、APIキーや環境変数、SSH資格情報を盗むペイロードがインストールされます。

なぜLLMsはパッケージを作り出すのか？

この攻撃の仕組みを理解するには、技術の欠陥を理解する必要があります。LLMsは事実を「知っている」わけではなく、次に最も可能性の高いトークンを予測しています。

• 妥当な命名規則: 例えば、google-cloud-storageやazure-storage-blobといったパッケージ名を多数見ていると、aws-storage-connectorという名前のパッケージも存在すべきだと推測します。
• 古い訓練データ: 何年も前に廃止されたライブラリを推奨することもあります。攻撃者はこれらの「ゾンビ」パッケージを悪意のあるコードで復活させることができます。
• 虚構: 特定のニッチな問題の解決策を求められると、モデルの「役立ちたい」目的が事実の正確さを超え、ライブラリを作り出してユーザーのリクエストに応えようとします。

「Slopsquatting」現象

セキュリティ研究者の Seth Larsonは、この行動を「Slopsquatting」と名付けました。typosquattingは被害者の不注意に頼りますが、slopsquattingはスロップ—低品質で未検証のゴミコードを生成するAIの出力に依存します。開発者が検証せずにこの「スロップ」をコピー＆ペーストすると、従来のセキュリティチェックを回避します。

実例：すでに起きている事例

これは理論だけの話ではありません。セキュリティ研究者はこの攻撃経路の有効性を実証しています。

1. huggingface-cliの事例

Lasso Securityのセキュリティ研究者、Bar Lanyadoは、LLMsが頻繁にhuggingface-cliというPythonパッケージを幻覚として生成することを発見しました。Hugging Faceは巨大なAIプラットフォームですが、この特定のPythonパッケージはPyPIには存在しません（通常は別の方法でインストールされる）。

Lanyadoはこの空のパッケージhuggingface-cliを登録し、理論の検証を行いました。

結果: 3ヶ月以内にこのパッケージは3万回以上ダウンロードされました。

怖い点: ただの開発者だけでなく、大手企業もAlibabaを含めて、この幻覚パッケージを参照した指示を自社の公開ドキュメントに貼り付けており、サプライチェーンリスクを拡大しています。

2. Vulcan CyberのStack Overflow実験

Vulcan Cyberの研究者たちは、ChatGPTにStack Overflowからスクレイピングした何千もの質問を自動的に投げかける実験を行いました。

その結果、Node.jsやPythonといった広く使われている言語でパッケージの幻覚が生成されることを確認しました。

あるケースでは、AIが特定の算術問題を解くためのパッケージを提案しましたが、NPMでそのパッケージは存在しませんでした。

この研究は、攻撃者が同じAPIを使って何千もの幻覚を生成し、人間の開発者が気付く前に登録できることを示しています。

攻撃の経済性：なぜ成功するのか

サイバー犯罪者にとって、AI Hallucination Squattingは従来の手法よりも高いROI（投資収益率）を提供します。

特徴	typosquatting	Hallucination Squatting
トリガー	ユーザーのタイプミス	AIが自信を持って推奨
信頼度	低（requesstsなどに気付く可能性）	高（AIは「専門家」とみなされる）
ターゲット	広範囲 / ランダム	特定の問題解決者
持続性	低（タイプミスはランダム）	高（LLMsは決定論的で、同じ嘘を繰り返す）

繰り返し性が重要

USENIX Security Symposiumの研究によると、GPT-4は習慣的な性質を持ち、一度ある開発者に偽のパッケージを提案すると、同じ質問をする別の開発者にもほぼ同じ偽パッケージを提案する確率が高い（多くの場合>20%）。攻撃者はこの決定論性を利用して、最も「人気」の嘘に張り付くのです。

AI Hallucination Squattingに対する防御策

この脅威に対抗するには、個々の開発者と企業のセキュリティチームの行動変容が必要です。「Trust but Verify（信頼するが検証せよ）」はもはや通用しません。「Verify, Then Trust（検証してから信頼せよ）」へとシフトすべきです。

🔐 開発者向け

「雰囲気」を確認: AIに推奨されたライブラリをpip installやnpm installする前に、必ずリポジトリを確認しましょう。

メトリクスを検証: - ダウンロード数: 500回か、500万回か？「業界標準」とAIが言うパッケージは、ほぼゼロのダウンロードではいけません。 - リリース日: つい最近公開されたものは要注意。 - 作者の信頼性: 既知の企業（Google、Facebookなど）や認証済みユーザーか？それとも匿名のハンドル名か？

Readmeを読む: 幻覚のパッケージは空や一般的なREADME.mdを持つことが多いです。ドキュメントが乏しい、または自動生成されたものであれば、インストールしない方が良いです。

🏢 組織向け

• プライベートレジストリ＆プロキシ: ArtifactoryやSonatype Nexusのようなツールを使用し、30日未満のパッケージや信頼性の低いもののインストールをブロック設定しましょう。
• パッケージのスコープ化: @company/libraryのようなスコープ付きパッケージの使用を徹底し、公開パッケージとの混同を防ぎます。
• AI利用ポリシー: 開発者にAI幻覚のリスクを教育し、AI生成コードを「信頼できない入力」として扱うセキュリティガイドラインを更新しましょう。

🤖 AIベンダー向け

• RAG（Retrieval-Augmented Generation）: AIモデルは現実に基づくべきです。LLMsをライブのパッケージマネージャAPIに接続し、推奨前にパッケージの存在を確認させましょう。
• DPO（Direct Preference Optimization）: hallucinating URLsや引用を生成した場合、モデルの訓練中にペナルティを科すべきです。

結論：”懐疑的コーディング”の時代

AI Hallucination Squattingは、サイバーセキュリティの風景に根本的な変化をもたらします。私たちは、「機械が支配する時代」から、「機械が誤る時代」へと移行しています。

「Vibe-to-Malware」パイプラインは、最も抵抗の少ない道を突いています。開発者は迅速な解決策を求め、AIは瞬時に提供します。しかし、スピードはセキュリティの敵です。

SDLC（ソフトウェア開発ライフサイクル）にAIをより多く取り入れる中で、人間の開発者の役割は「ライター」から「監査者」へと進化すべきです。あなたの画面のコードは正しそうに見えても、パッケージ名は正当そうに見えても、AIは自信満々でも、それを検証しなければ書いたことにはなりません。2024年以降も、検証しなければ、それはあなたのコードではなく、あなたの責任です。