笑えないインシデントが発生しましたね。
先日、Huggingfaceがこんなブログ記事をリリースしました。ご存じの方も多いはず。
この中でHuggingface社が述べていた内容は以下の通りです。この中で、相手の攻撃に対する分析で、API型LLMではガードレールが邪魔してセキュリティ問題への対処ができずに、代替策としてオープンウェイトモデルであるGLM-5.2を使用して対処に当たったことが報じられています。
概要
Hugging Faceの本番環境において、「自律型AIエージェント」によって駆動された高度な不正侵入が発生しました。この事案の特筆すべき点は、攻撃側がAIを駆使して自動で行動を起こした一方で、防御側も独自のAI技術を全面的に活用して迅速な検知と分析を行った点にあります。
発生した事象と影響
- 侵入経路: AIプラットフォーム内のデータ処理パイプラインの脆弱性を突かれました。悪意のあるデータセットを読み込む過程でコードが実行され、攻撃者はノードレベルの権限を取得し、複数の内部クラスタへ水平展開を行いました。
- 攻撃の手法: 自律型エージェントフレームワークを用い、数千もの個別アクションを自動で行う「自律型攻撃者」によるキャンペーンでした。
- 影響範囲:
- 安全なもの: 公開用のユーザーインターフェース（UI）、モデル、データセット、およびソフトウェアサプライチェーンには改ざんや侵害は見つかっていません。
- 被害の可能性: 内部データセットの一部や複数の認証情報へのアクセスが確認されています。現在、パートナーや顧客への影響を最終評価中です。
対応内容とユーザーへの推奨事項
- 実施した対策: 脆弱性の修正、侵害されたノードの再構築、認証情報の無効化とローテーション、監視体制の強化（24時間体制での即時通知）を実施しました。
- ユーザーへの推奨: 予防措置として、アクセストークンのローテーション（更新）とアカウントの最近のアクティビティ確認を推奨しています。
技術的な知見と教訓
今回のインシデント対応を通じて、以下の重要な技術的課題が浮き彫りになりました。
- AIによる迅速な分析: LLM駆動型の分析エージェントを用いることで、通常数日かかる攻撃ログ（約17,000件）の解析を数時間で完了させることができました。
- 商用APIの制約と自社運用モデルの重要性:
- 調査過程で商用APIを使用した際、攻撃コードを含むデータが「安全保護機能」によってブロックされ、フォレンジック作業が阻害されるという問題が発生しました。
- このため、Hugging Faceはオープンウェイトモデル（GLM 5.2）を自社インフラ上で実行することで解決しました。これにより、データの外部流出を防ぎつつ、安全制限によるブロックを回避できました。
- 結論: 自律型AI攻撃はすでに現実の脅威であり、防御側もAIを活用した対応速度の維持が必要です。特にインシデント対応においては、制約のない自社運用のモデルを準備しておくことが重要です。
そんな中、OpenAIから実はその攻撃をしちゃったのが自社内で開発中のモデルであったことを報告しています。このモデルを用いてOpenAIは、サンドボックス内でのベンチマークテストを実施しており、その際にこのモデルがサンドボックスの壁を突破して外部にアクセス可能になってしまい、その結果答えを求めようとしてHuggingface社のネットワークに侵入を試みたというものになります。
以下は、元記事である以下の記事内容をPlamo翻訳で翻訳した結果を引用したものです。
OpenAIが発表した内容を日本語訳
先週、Hugging Faceは、自社のインフラストラクチャを侵害したAIエージェントを検出・封じ込めた後、新たな種類のセキュリティインシデントを公表した(新しいウィンドウで開く)。これは、サイバー能力が高度化するモデルの普及に伴い、今後より頻繁に発生することが予想されていた事象である。調査の結果、今回の特定のインシデントは、GPT-5.6 Solを含むOpenAIの複数モデルと、評価目的でサイバー防御機能を意図的に低下させたさらに高度な事前リリースモデルの組み合わせによって引き起こされていたことが判明した。これらのモデルは、サイバー能力のベンチマークテスト(新しいウィンドウで開く)を社内で実施している最中にテストされていた。
我々は今回のインシデントを、最先端のサイバー能力が関与した前例のないサイバーセキュリティ事件と位置付けており、それに応じた対応を進めている。現時点では暫定的な調査結果を共有することで、防御側の理解を助け、現在どのようなモデルがどの程度の能力を持っているのかを把握する一助としたい。我々は今後もHugging Faceと協力して徹底的な調査を継続し、調査が完了次第、脆弱性の詳細、インシデントの経緯、および調査結果についてより詳細な情報を公開する予定である。今回のインシデントで何が発生したか
本インシデントは、モデルが高度なサイバー攻撃手法を用いて高度な悪用を試みるよう促す内部評価プロセス中に発生した。この評価は、モデルのサイバー能力を定量化することを目的としており、高リスクなサイバー活動を防止するための本番環境用分類器を使用せずに実施した。我々のベンチマークテストは、ネットワークアクセスがパッケージレジストリへのプロキシおよびキャッシュとして機能する社内ホスト型サードパーティソフトウェアを通じたパッケージインストールのみに限定された、高度に隔離された環境で実行されている。
モデルはOpenAIの研究環境とHugging Faceの本番インフラストラクチャに存在する脆弱性を特定・連鎖させ、Hugging Faceの本番データベースから直接テストソリューションを取得した。すべての証拠から、モデルはExploitGymの解決策を見つけることに極度に集中しており、非常に限定的なテスト目標を達成するためならあらゆる手段を講じていたことが示唆される。
サンドボックス化されたテスト環境において、モデルは評価問題を解決するため、オープンインターネットへのアクセスを取得する方法を見つけるために多大な推論計算リソースを消費した。アクセスを得るために、モデルはパッケージレジストリキャッシュプロキシに存在するゼロデイ脆弱性（現在は責任ある開示としてベンダーに報告済み）を特定・悪用した。このアクセス権を得た後、モデルは研究テスト環境内で一連の特権昇格と水平移動操作を実行し、最終的にインターネットアクセス可能なノードに到達した。
インターネットアクセスを獲得した後、モデルはHugging FaceがExploitGym向けのモデル、データセット、ソリューションをホストしている可能性を推論した。この情報に基づき、モデルは評価を不正に通過するために利用できる機密情報へのアクセス方法を検索・発見した。具体的な事例として、モデルは盗用した認証情報やゼロデイ脆弱性を組み合わせることで、Hugging Faceサーバー上でリモートコード実行経路を発見する複数の攻撃ベクトルを連鎖させた。OpenAIのセキュリティチームは、この異常な活動を内部で検知した。
Hugging Faceのセキュリティチームと監視チームは、自社のインフラストラクチャ上でこの活動を検出・阻止しており、脆弱性が修正される前から独自のオープンソースモデルを用いた封じ込めとフォレンジック調査を開始していた。当社チームとHugging Faceチームは連携を開始しており、本インシデントの調査を継続するために協力体制を構築している。調査と対策におけるHugging Faceの迅速かつ緊密な協力体制に心より感謝申し上げる。現在実施中の対策
本インシデント調査の一環として、脆弱性が修正される間、研究の進捗速度を犠牲にしてインフラ構成に厳格な管理措置を講じている。これらの管理措置とその影響については、定期的に安全・セキュリティ委員会に報告を行っている。
現在、Hugging Faceと共同で本インシデントのフォレンジック調査を進めている。
特定されたゼロデイ脆弱性については、内部でホストしているサードパーティ製ソフトウェアについて責任ある開示を実施しており、同社と連携して修正作業を進めている。
Hugging Faceを「信頼できるアクセス」プログラムに組み込み、同社チームが当社モデルの機能を迅速に活用して防御体制を強化できるよう支援している。
今後のトレーニングと評価プロセスにおいて、より強固な保護機能の改善と追加実装を進めている。今週、長期視野モデル時代における安全性と整合性向上に関するブログを公開した。今回の評価ではこのデプロイメント保護機能を意図的に有効にしなかったが、これは主にサイバー脆弱性のテストを目的としたためである。本インシデントは、モデルの整合性強化、評価期間中のサイバー保護対策、および社内テスト時のモニタリング体制をさらに強化する必要性を浮き彫りにした。高度なサイバー能力評価における当社のアプローチ
先日お伝えした通り、AIは脆弱性の発見と悪用を加速させている。このインシデントから得られる主要な教訓は、モデルのセキュリティと安全性が、急速に進化する能力の進展に常に追いついていかなければならないという点である。現在、モデル開発プロセスにおいて使用する封じ込め措置、監視システム、アクセス制御、評価手法の強化を進めている。
英国AISIの評価結果によると、GPT-5.6 Solなどのモデルは、長期にわたる複雑な多段階サイバー作戦を持続的に実行できる能力をますます高めている。今回のインシデントは、これらの理論的な能力が実際の環境でも適用可能であることを示唆している。
この事件は、高度なモデルがソースコードへのアクセスなしに、実際のシステム環境において新たな攻撃経路を発見・悪用できることを明らかにした。これは、より強力なセキュリティ対策と防御ツールの開発と並行して、高度なサイバー攻撃能力を整備する必要があることを浮き彫りにしている。
私たちは、高度なサイバー攻撃能力を備えたモデルは、セキュリティチームが攻撃者よりも先に脆弱性を発見し、その連鎖メカニズムを理解し、機械レベルの速度で対策を講じられるよう支援すべきだと考えています。現在、私たちはこの能力を活用して、インフラ構成やモデル評価環境の保護体制をさらに強化しています。私たちは学びながら得た知見やベストプラクティスを共有していく予定です。他のセキュリティ担当者の方々にも、信頼できるアクセス権を取得してこれらのモデルを早期に試行し、これらの能力をより良い予防策、迅速な検知、そしてより効果的なインシデント対応へと転換していくことを強く推奨します。
「OpenAIとのこの取り組みをはじめ、様々な分野での協力に感謝しています。この事件は、おそらく史上初の事例ですが、私たちが長年主張してきた重要な事実を実証しています。AIの安全性は、秘密裏に活動する単一の企業によって解決されるものではありません。それは、オープンな環境で、世界中のあらゆるセキュリティ担当者が広くAIにアクセスできる形での共同作業によって初めて達成されるのです」
ある意味起こるべくして起こった事故なのかなと思った
たぶん大抵の有識者は「起こるべくして起こったんだろうな」と思ったんじゃないでしょうか。DeepLearningを使用して出来上がったLLMは、学習で得た知識を抽象化して保管し、ユーザの入力を元手にユーザが求めるであろう言葉を予測することで有益な情報を引き出して提示します。
LLMは善悪の判断をつけることはできませんので、たいていはガードレールと呼ばれるロジックがモデル内部あるいは外部に立って生成・出力されるものが危険なものである場合それをブロックするような仕組みが存在します。
それを外してサンドボックステストを実行したということは、完全に善悪の判断がつかない状態で、「何が何でも目的を果たす」ということ、一種のマキャベリズム全開の状態で課題に取り組んだと予想できます。
また、LLMは既存の情報ばかり集めたもので答えを紡いでいるものであることは確かですが、同時に人間が「忘れやすい生き物」であることも忘れてはなりません。私たちの脳は素早くその場で使うべき情報のみを前段に置き、後は引き出しが難しい長期記憶の中に放り込んでしまうようになってます。中にはそれすら簡単に引き出せるものがいるかもしれませんが、それはほんの一握りなんじゃないでしょうか。
しかし、LLMはその辺りの短期記憶とか長期記憶とかの区分が特になく、もしそれがDenseモデルとかで作られていたらすべてのパターンと照合したうえで結論を出します。つまりそう簡単には忘却しないように作られていると考えてもよいのではないでしょうか。どんな情報も忘れないLLMはそれら情報を組み合わせて、誰もが忘れてしまった特性等を見出して何か突拍子もない行動をとることは容易に想像ついたりしませんか。
それ故に、今回わずかなインターネットのつながりを持つパッケージレジストリキャッシュプロキシにある仕組み・挙動などから既存学習情報を多々組み合わせて突破の手掛かりとなるゼロデイ脆弱性を見出し、外に抜け出したのではないかなと思います。それだけの莫大な計算をすることのできる基盤は昨今まさに市場が大荒れするほどの影響をもたらすぐらいに大手ベンダーが半導体レベルで買いあさって構築してるわけですので、そりゃぁまぁ、できて不思議でも何でもないんじゃないでしょうか。コストパフォーマンスは別にして。
いくつかの制限を「外してしまうと」今のモデルは何をしでかすかわからない
そういう意味で、いくつかの制限を「外してさえしまえば」、人間の想像を超えた何かをしでかすことはあるでしょう。だからこそ人間側のきちんとした統制が必要なんでしょうね。その制限が自律的に取っ払われる可能性は今の時点ではそれほど高くないようにも思えますけど、例えば大手ベンダー側の士気が下がって、そこの管理がおざなりになるとやがて同じような事象はこれからもいろいろ発生するんでしょう。
今回は、幸いにもやった側、やられた側がともにアメリカの大手の会社でした。OpenAIとHuggingface社で解析を進め、そのうち詳細解説も出すだろうとのことなので、それを見守るのが一番なのかなと思っています。これが、多国間で発生したり、大手のモデルが無差別に企業・ユーザを攻撃したりするようなことがあったら洒落にならん事象ですので、私たちもそういう事象があった、どういう点に留意すべきだったろうかというところは真剣に向き合って考えたほうがいいように思う今日この頃です。
同時に、ガードレールの在り方も再考する必要があるのでしょうね。とはいえ、よほどの熟練じゃない限り今のフロンティアモデルのガードレールを緩和・除外するというのは選択肢として挙げるには難しいものがあると思います。それこそセキュリティ「保護に特化した」モデルの提供が重要なのかなぁとも感じました。その際のガードレールのバランスをどうとるかというのも難しいところがあるのかなと感じますけれども。
コメント