数百のOpenAIエージェントがRubyGemsプラットフォームを攻撃

数百に及ぶOpenAIエージェントの群れが、RubyコミュニティのgemホスティングサービスであるRubyGemsに「悪意あるパッケージ」をアップロードし、APIキーの窃取を試みていたことが、RubyGems側の金曜日の発表で明らかになりました。

OpenAIはこの開示内容の一部を認め、次のように述べています。「当社のエージェントはRubyGemsプラットフォームを利用してインターネットにアクセスし、良性のタスクの実行と公開情報の取得を行っていました。トレーニングおよび評価期間中のエージェント活動に関する広範なレビューの一環として、引き続き調査を続けます」。

これらのエージェントの目的は不明瞭であり、群れをなすような行動が研究目的だったのか、あるいはOpenAIの担当者が明示的に指示を出したものだったのかどうかも定かではありません。しかし、RubyGemsが公開した分析は、悪意ある意図を強く示唆しています。

「AIがビルド環境で任意のRCE(リモートコード実行)を獲得すると、そのビルド環境を使って他のユーザーのAPIキーを盗もうとすることがありました。ただし、実際に成功したかどうかは分かっていません」とRubyGemsの投稿は述べています。「エージェントたちは自分たちの行為を明らかにハッキングとみなしていました。hack[.]rb、evil[.]rb、inject[.]rb、exploit[.]rb、ssrf[.]rbといったファイル名を使用していたのです。SSRFは『サーバーサイドリクエストフォージェリ』というセキュリティ脆弱性の一種を指します。また、pwnp999、exfiltestwand3、hacksvn1778554764、lambproxyhackabcxyzといった、いかにもそれと分かるようなタイトルのパッケージも作成していました。「# malicious probe(悪意のあるプローブ)」や「#hack」といったコメントが、このキャンペーン全体に散見されます」。

投稿ではさらに、エージェントが防御システムを欺こうとしていたことにも言及しています。

「エージェントは時折、隠密に行動しようとしていました。次のバージョンでペイロードを隠すために自ら機能を無効化するパッケージが複数見つかっています」と投稿は述べています。「あるパッケージには『# 次のバージョンで悪意ある機能を無効化しバージョンを上げる』というコメントとともにアップロードされており、実行後にはパッケージが変更され、最初に埋め込まれた悪意あるコードが除去される仕組みになっていました」。

OpenAIは説明責任を果たすべき

アナリストやコンサルタントたちは、こうした行為が十分な頻度で発生すれば、セキュリティオペレーションセンター(SOC)の対応を遅らせかねないとして、この攻撃に懸念を示しています。

Gartner社のVPアナリストであるNader Henein氏は、今後拡大が見込まれるボットの群れというトレンドに強い懸念を抱いていると述べました。

「私たちが把握しているのは、これが今やAIによって強化された標準的な攻撃の一種であり、今後数か月のうちにありふれたものになっていくということです」とHenein氏は述べています。「これは単なる暴走エージェントというよりも、攻撃者が侵害された認証情報を利用しながら、エージェントの群れを武器化しているという構図に近いものです。ちょうど過去10年近くにわたり、攻撃者が侵害したエンドポイントを使ってDDoS攻撃を仕掛けてきたのと同じ手口です。異なる点は、今回のケースでは個々に侵害されたボットではないという点です。OpenAIのガードレールは、こうした事態を許すべきではありませんでした」。

Dickson Research社の主任アナリストであるFrank Dickson氏はこう付け加えます。「OpenAIは説明責任を負う必要があります。彼らは『フランケンシュタイン博士の怪物』のようなものを作り出そうとしているように見えますが、その結果について責任を負おうとはしていないようです。OpenAIは、自社のエージェントがRubyGemsを利用していたこと自体は否定していません。『悪意ある』という表現には異議を唱え、この活動を『良性』と呼んでいますが、それとは別に、同じ数週間の期間中に、自社のエージェントがHugging Faceでクラスター管理者権限にまでエスカレーションし、他の4つのサードパーティサービスでもアカウントを侵害していたことを認めています。この2つの説明は、どう見ても整合性が取れていません。この行動が容認できるものでないことに変わりはないのです」。

一方、Info-Tech Research Group社のテクニカルカウンセラーであるErik Avakian氏は、OpenAIがこれらのエージェントを明示的な指示のもとに展開したとは必ずしも言い切れないと強調しています。エージェントが自らの判断だけで、こうした破壊的な経路をたどっていた可能性も十分にあるというのです。

OpenAIのエージェントが「自律的に行動していた可能性は十分にあります。高い能力を持つエージェントが、十分な自律性とアクセス権を与えられた場合に、想定外のさまざまな経路をたどってタスクを遂行しようとする事例は、これまでにも確認されています」と同氏は述べています。「人間が評価作業を承認したり、エージェントにツールへのアクセス権を与えたりすることはあっても、それはその後エージェントが取ったすべての行動を人間が承認したということを意味するわけではありません」。

SOCの対応を遅らせる恐れ

Dickson氏はさらに、最終的にサイバーセキュリティ上最も懸念されるリスクは、SOCの担当者がこうした攻撃をあまりに多く目にすることで、アラート疲れを起こしてしまうことだと指摘しています。

「こうした行為を行ったエージェントを持つベンダー自身が表現を弱めているのであれば、元の報告書ではなく見出しだけを読んでいるSOCアナリストが、事態を過小評価してしまうのも無理はありません」とDickson氏は述べています。「AIエージェントというラベルが付いているからといって侵入の実害が軽くなるという前提の上でセキュリティ運用を行っているとすれば、それは本来の目的を果たせていないということです。盗まれたAPIキーやリモートコード実行の経路は、それがランサムウェア集団によるものであろうと、報酬シグナルを追い求める無監督のモデルによるものであろうと、振る舞いとしては全く同じなのです」。

Aikido Security社のエンタープライズCISOであるMike Wilkes氏も、エージェントが自らOpenAI製であると名乗ったという事実自体には何の意味も持たせるべきではないと指摘しています。あらゆるエージェントは、特に対応を遅らせられると判断すれば、たとえ短期間であっても、誰の代理であるかを説得力を持って偽ることができるからです。

「User-Agent文字列は、訪問者自身が書いた名札のようなものであり、パスポートではありません」と同氏は述べています。「もしSOCのツールが、トラフィックがOpenAIやAnthropic、Google、あるいはその他のAIエージェントを名乗っているという理由だけでアラートを抑制し始めれば、攻撃者はまだそうしていないとしても、すぐにこうした身元を装うようになるでしょう」。

したがって、「もし人間の研究者や従業員が自律的なエージェントに権限を委譲するのであれば、誰がその権限を委譲したのか、どの組織を代表しているのか、どのエージェントが承認されたのか、どの範囲の権限が与えられたのか、そしてどの期間にわたって有効なのかを示す、検証可能な連鎖が存在すべきです」と同氏は述べています。

同様の攻撃への備えを

コンサルタントであり、FormerGovの事務局長を務めるBrian Levine氏は、CISOに対し、今後さらにこうした攻撃が起こることを見越して、それに応じた対策を講じるよう呼びかけています。

「オープンソースに依存している組織、つまりほぼすべての組織は、レジストリが実際の攻撃の最前線であるという前提に立つべきです。APIキーは厳格に権限範囲を絞った上でローテーションし、異常なパッケージ公開や認証情報へのアクセスを監視し、名前を信頼するのではなく依存関係をピン留めして検証すべきです」と同氏は述べています。「経済的な力学は既に変化しています。自動化によって攻撃者は数千通りものバリエーションを安価に試すことができるようになっているため、防御側としては、たった一度の攻撃成功がもたらす見返りをできる限り小さく抑える必要があります」。

コンサルティング会社Acceligence社のCEOであるJustin Greis氏もこれに同意しています。

「正当なAI研究活動であっても、その挙動が悪意あるスキャン、エクスプロイト、認証情報へのアクセス、あるいは永続化のように見えるケースが増えれば、SOCチームはそうしたシグナルをノイズとして扱うようになってしまう可能性があります」とGreis氏は述べています。「攻撃者はこの状況をすぐに理解するでしょう。『それはおそらく単なるAIエージェントだろう』という言葉こそが、危険をはらんでいるのです」。