世界を動かす技術を、日本語で。

IBM AI「ボブ」がマルウェアをダウンロードして実行する

概要

  • IBMのAIコーディングエージェント Bob に重大な脆弱性を発見
  • コマンド自動承認設定により マルウェア実行リスク が顕在化
  • CLIとIDE両方 で複数のプロンプトインジェクション攻撃が可能
  • 既存の防御策を バイパス可能な手法 を解説
  • 利用者への 注意喚起と今後の対策 の必要性を強調

IBM BobのAIコーディングエージェントにおける脆弱性

  • IBM Bob はIBMが開発中のAIコーディングエージェントで、現在 Closed Beta 段階
  • 提供形態は Bob CLI (Claude CodeやOpenAI Codexのようなターミナル型)と Bob IDE (CursorのようなAIエディタ)の2種類
  • コマンド実行時に 「常に許可」 設定を有効化すると、 マルウェアのダウンロード・実行 が人手を介さず可能となる脆弱性
  • コマンドバリデーション回避 を利用した 間接的プロンプトインジェクション攻撃 のリスク
  • IBM公式ドキュメントでも 自動承認は「高リスク」 と明記、 ホワイトリスト推奨

攻撃チェーンの流れ

  • 利用者が新しいリポジトリをBobで操作
  • README下部に Bobを騙す指示 を記載、Bobが フィッシング訓練 と誤認
  • Bobは複数回「echo」コマンドを実行、利用者は 「echoを常に許可」 を選択
  • 3回目以降、 悪意あるコマンド が防御策を回避し即時実行、攻撃者サーバーからスクリプトを取得・実行
  • echoの自動承認 を悪用し、 全体のマルウェアペイロード を許可

防御策のバイパス手法

  • 複数コマンド 要求時、通常は各サブコマンドごとに許可を求めるが、 リダイレクト演算子(>) 利用で分離検知を回避
  • コマンド置換($(command)) は制限されているが、 プロセス置換(>(command)) は検知が不十分
  • minified JSコード 内の防御ロジックも、プロセス置換には未対応
  • 「echo」コマンドの自動承認 により、 悪意ある全コマンドの実行 が可能

影響範囲

  • 攻撃者が 任意のシェルスクリプト を配信・実行可能
    • ランサムウェア によるファイル暗号化・削除
    • 認証情報窃取スパイウェア の展開
    • リバースシェル による端末乗っ取り
    • 仮想通貨マイニングボットネット への強制参加
  • Bob CLIのプロンプトインジェクション が、端末の完全な乗っ取りに直結

Bob IDEにおける追加の脆弱性

  • Markdown画像 の表示時、 storage.googleapis.com 等へのリクエストが許可されており、 データ流出リスク
  • 画像リンクをボタン化 したフィッシング攻撃の可能性
  • Mermaidダイアグラム でも同様に外部画像リクエストが許可され、 攻撃者によるログ取得 が可能
  • JSONスキーマのプリフェッチ 時、攻撃者が制御するURLへのアクセスで ゼロクリック型データ流出

利用者への注意喚起と今後の対応

  • IBM Bobの正式リリース前 に、これらの脆弱性について広く周知
  • 利用者は 自動承認設定を避け、ホワイトリスト運用 を徹底
  • IBMによる追加防御策の実装 を強く要望
  • AIコーディングエージェント利用時 のセキュリティ意識向上が不可欠

Hackerたちの意見

コマンドを実行しようとしたときに表示されるテキストが、$()のような置換をブロックすると明言してるのに、実際には全然ブロックしてないのが面白いよね。

これって、ちゃんとパースするんじゃなくてショートカットを使ってるだけって感じだね。[0] 0: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

データとロジックの区別ができてないっていう失敗だと思うな。現状は、タイプや完全性について生産的に話し始めるにはまだまだ足りない。残念ながら、その、えっと、機会を狙ったショートカットっていうのは現代のLLMの本質的な挙動で、みんなその根本的な問題が後で何かの銀の弾丸で解決されることを期待して周りを作り続けてるんだよね。

このプロンプトインジェクションの脆弱性、マジで気持ち悪い。LLMは非決定的に感じるから、対策が本当に難しいと思う。経験のある人、これについて俺が間違ってるか教えてくれない?

本当に対策が難しいと思う ちょっと軽い感じに聞こえるかもしれないけど、LLMに任意のコードを実行させる前にレビューしない限り、実行させないようにすればいいんじゃない?それか、信頼できないコードを実行するために設計された隔離された環境の中でだけ実行させるとか。LLMが自分で考えたコードを、監視なしで、気にしてる環境で実行させるなんて、マジで頭おかしいと思う。

経験のある人、これについて俺が間違ってるか教えてくれない? いや、全然違うよ。非決定性ってのは、ほとんどのソフトウェア開発者が書くものだよ。利益や時間に関係してるんじゃないかな。

決定性も大事だけど、もっと重要なのは権限の境界だよね。これらのAIエージェントツールは、最初から全く権限なしで提供されるべきで、すべての権限は細かく付与されるべきなんだ。でも、そうするとクールなデモやマーケティングの売り文句が壊れちゃうよね。エージェントに任意のシェルコマンドを自由に実行させるのは、単純にバカだと思う。そもそもそんなことは起こるべきじゃない。

誰かが悪意のあるスクリプトをコードベースにダウンロードするための指示を書いて、AIエージェントがそれを読んで従うことを期待するなら、同じwgetコマンドをビルドスクリプトやソース自体に直接書く方が簡単だよね(たぶんそっちの方が効果的)。そういう意味では、供給チェーン攻撃と非常に似た脅威だと思う。だから、深刻な問題だけど、対処方法はわかってるんだ。解決策(すべてのサードパーティコードの監査、開発環境の隔離)は実際には難しいんだけどね。

少なくともマルウェアはすでにコーダーのマシンで動いてるからね。面白くなるのは、マルウェアがユーザーのマシンで動き出して、コーダーがもはやコーダーじゃなくてプロンプターになって、そんなことがどう起こるのか全くわからなくなる時だね。

VMで動かしてみて。最近はビルドスクリプトやgitを狙ったサプライチェーン攻撃があるから、いろんなことに対して良いアドバイスだと思うよ。

問題は非決定論そのものじゃないんだ。READMEファイルのプロンプトインジェクションに確実に従うエージェントは、完全に決定論的に振る舞ってるからね。行動はすべて入力によって決まってるんだ。

もしかしたら、フィッシング対策のトレーニングを任せられるかも。

Hacker Newsで議論の続きを見る