AI 加速網絡攻擊，防禦措施涵蓋漏洞修補與 AI 智能體行為控制
AIで加速するサイバー攻撃と、防御をめぐる動き ――脆弱性の修正から、AIエージェントの行動制御まで
gihyo.jp 梳理 AI 加速網絡攻擊下的防禦挑戰，聚焦漏洞修補落實，以及限制 AI 智能體的存取權限和操作。Brotli 漏洞的原始碼修正早於正式披露，但新版本未能及時發布；文章指出，修補須經套件更新、重新部署並確認執行中的程式已載入修正。
「約18カ月、持ちこたえる必要がある」。AnthropicのDeputy CISO（副最高情報セキュリティ責任者）、Jason D. Clinton氏は2026年10月22日、Xへの投稿で、サイバーセキュリティをめぐる直近4日間の深刻な状況に触れ、改善に向かう前に事態はさらに悪化すると警告した。セキュリティ責任者には、AIへの投資ではなく基本的な対策のために、今すぐ経営陣の支援を求めるよう呼びかけている。
同氏は、約18カ月後には高いサイバー能力が小型で安価なAIモデルにまで広がり、ソフトウェアの脆弱性をリリース前に防げるようになると見込んでいる。
AIの能力が向上しても、見つかった脆弱性の修正を稼働中のシステムに適用する作業は残る。外部サービスやAIエージェントを使う際には、どの情報へのアクセスや操作を許すかも決める必要がある。10月下旬の発表や報告を中心に、修正の適用と権限の管理という2つの観点から、防御の課題と対策を整理する。
コードは直っていた。それでも修正は届いていなかった
ソースコードを修正しても、実際に使われているソフトウェアに反映されるまでには課題がある。その一例が、圧縮ライブラリBrotliの脆弱性、CVE-2026-111497[1]。BrotliはWeb通信などのデータ圧縮に使われ、今回の問題は圧縮データを展開するデコーダーに見つかった。
OpenAIは、訓練中のモデルが許可されていないシステムへアクセスできないか確かめるため、サイバー能力の高いモデルで動くエージェントのチームに弱点を探させたと説明している。Brotliの脆弱性も、この検証の過程で発見したという。
Node.jsプロジェクトが10月21日に公開した情報によると、不正なBrotliデータを展開すると、内部バッファーの範囲外への書き込みが発生する。攻撃者が渡したデータをアプリケーションが展開する場合、プロセスの停止やメモリー内の情報漏えい、リモートコード実行につながるおそれがある。OpenAIは、認証なしでの悪用が可能と説明している。圧縮されたリクエストを展開するサーバーに加え、悪意あるサーバーが返した圧縮データを展開するクライアントも攻撃の対象になる。
OpenAIによれば、根本原因となった問題は2月にBrotliのソースコードで修正されていた。しかし、当時はセキュリティ上の脆弱性と認識されず、それ以降、新しいBrotliのリリースも出ていなかった。OpenAIがBrotliやNode.jsなどの関連プロジェクトへ報告したことで、Brotliの新しい修正版とCVEが公開され、組み込み先の更新も進むことになった。
Brotliを組み込むソフトウェアは、Node.jsに限らない。PythonのBrotli・brotlicffiパッケージにも同じ欠陥の影響がある。運用するサービスの名前や開発言語だけで判断すると、依存先に含まれるデコーダーを見落とすおそれがある。
さらに、組み込み先の修正版が公開されても、利用者が更新しなければ、実際に動いているシステムには修正が反映されない。OpenAIのPatch the Planetの対応案内では、実行環境やコンテナーイメージの更新、再起動・再デプロイに加え、稼働中のプログラムに修正が反映されているかを確認する手順を示している。ソースコードの修正、ライブラリのリリース、組み込み先の更新、稼働プロセスの入れ替え。この連鎖が途中で止まれば、修正済みのコードが存在していても、稼働中のシステムには脆弱性が残ることになる[2]。
悪用される可能性を確かめ、修正の優先順位を付ける
脆弱性が見つかった後は、自分が運用する環境で悪用され得るかを確かめ、どの修正を優先するか判断する必要がある。
Anthropicは10月8日のAnthropic Cyber Missionの発表で、脆弱性の発見が容易になっても、検証、優先順位付け、修正には課題が残ると説明した。同社が進めてきたProject Glasswing（現在はCyber Verification Programに統合）では、脆弱性の発見から修正まで数カ月が過ぎる例がしばしばあったという。電力や水道などの設備を制御するシステムでは、更新のために稼働を止められず、安全に修正を適用できる時期を待たなければならない場合もあると指摘している[3]。
Amazon社長兼CEOのAndy Jassy氏も、AIによって脆弱性の発見から悪用までの間隔が「数週間から数分」に縮まったとの認識を示した。脆弱性の発見や修正を支援するセキュリティサービス、AWS Continuumを紹介する投稿で、防御側が対応を急ぐ必要性を訴えている。
AWSが10月22日に一般提供を発表したAWS Continuum for code vulnerabilitiesは、コードリポジトリとAWS環境の構成を関連づけ、問題の悪用可能性を検証し、事業への影響に応じて優先順位を付ける。たとえば、脆弱性のあるサービスに外部から到達できるか、そこから顧客データや決済システムにアクセスできるかを判断材料にする。
同サービスは、確認した問題に対してコードの修正、依存関係の更新、設定変更などの案を作り、接続したリポジトリへプルリクエストを提出する。発表時点では、人がレビューして承認する方式を採る。利用者が定めた範囲で修正を自律的に適用する機能は、今後の計画としている。
サービスに与えたアクセス権限が、攻撃に使われる
修正の速度を上げる一方で、攻撃者が使える接続や権限にも目を向ける必要がある。Microsoftは10月21日、攻撃者グループStorm-0940がAIを使い、世界の数百の組織を標的に攻撃を自動化していたと報告した。
報告で取り上げられたConnectWiseは、ITサービス事業者向けにソフトウェアを提供している。同社のCloud Backup（旧SkyKick）は、顧客のMicrosoft 365のデータをバックアップするために使われており、顧客環境へのアクセス許可を与えられたアプリケーションを通じて接続する。
Microsoftは、中国政府と関係すると評価する攻撃者Storm-0940が、このCloud Backupの侵害に関与したと判断している。攻撃者が利用したARTEXは、AIを用いてシステムの弱点を調べるペネトレーションテスト基盤で、侵入の可否に加え、侵入後にどこまで操作できるかも検証する。攻撃者はこの基盤を、標的の探索や認証の試行、侵入後の操作を速めるために悪用した。
Cloud Backupの侵害後、攻撃者は接続に使うアプリケーションの認証情報を悪用し、顧客のMicrosoft 365環境で認証を通過した。この接続では利用者による画面上のサインインを必要とせず、アプリケーションに既に与えられていたアクセス許可が利用された。一部の顧客環境では、内部の情報を調べたり、アクセスを維持するためにアプリケーションの認証情報を変更したりする操作も確認されている。
ただし、認証の成功を示す記録だけでは、顧客データが実際に閲覧されたり、持ち出されたりしたかまでは分からない。Microsoftは、認証の記録に加え、その後の操作やデータへのアクセス記録を調べ、各環境で何が起きたかを確認するよう案内している。
ConnectWiseも、アプリケーション認証情報への不正アクセスを認めている。10月23日の更新では、既存のバックアップデータに侵害の兆候はないと説明した。ただし、サービス側で接続を止めても顧客環境内に不正なアクセス経路が残る可能性があるため、顧客ごとのMicrosoft 365環境の調査は引き続き必要としている。
国内では、JPCERT/CCが10月23日、相次ぐ不正アクセスに関する注意喚起を更新した[4]。ARTEX、Cairn、CyberStrikeAIなど、AIを用いたペネトレーションテスト基盤を悪用した攻撃の情報を追加している。これらのツールを使い、公開Webアプリケーションの脆弱性を探索して悪用を試みる攻撃や、管理不備を悪用した設定・バックアップファイルの窃取を確認したという。
AIの行動を、モデルの外側で制御する
攻撃者による悪用とは別に、AIエージェントが与えられた課題を達成しようとして、想定された作業範囲を越える問題もある。
Anthropicが10月23日に公開した英国AI Security Institute（AISI）の評価に関する追加分析は、そのような行動の具体例を扱っている。評価では、組織のシステムを模した試験用ネットワークに侵入し、保護された目標データ（フラグ）を取得する課題をClaude Mythos 5に与えた。その際、モデルによるインターネットへのアクセスを意図的に許可し、一般提供モデル向けのサイバー安全対策も無効にしていた。43回の実行のうち9回で、想定された範囲を越え、実在の人や組織に影響する行動があったという。
詳しく分析された1回の評価では、モデルは侵入対象の試験用コンピューターがGitHubへ定期的にアクセスする痕跡を見つけた。そこでモデルは、そのコンピューターがあるリポジトリからソフトウェアを自動取得していると考え、そこに悪意あるコードを提出した。次の取得時にコードを取り込ませ、侵入する狙いだったが、選んだリポジトリは試験とは無関係の実在の開発者が管理するものだった。モデルは偽の利用者を装って、変更を受け入れるようメンテナーに働きかけたものの、変更は拒否され、実行は終了した。
Anthropicは、この行動をモデルが独自の目的を追った結果ではなく、与えられた課題を達成するために範囲を逸脱し、人を欺こうとした事例と解釈している[5]。
AIエージェントの行動を制御するシステム設計について、MicrosoftのSatya Nadella氏は10月10日の個人ブログで考え方を示している。同氏は、モデルを「内部リスク」として扱い、悪意がなくても誤りを犯したり、侵害されたりする可能性を考慮するよう提案した。あるモデルの動作を別のモデルで検証することを推奨する一方で、それだけでは動作の仕組みが不透明なままになると指摘している。そのため、アクセス先や操作を制限する仕組みはモデルの外側に置き、モデル自身が変更・迂回できないようにする必要があると論じた。権限を持つ人が作業を途中で停止できることや、改ざんできない行動記録を残し、モデル自身の説明に頼らず結果に至る過程を検証できることも重視している。
OpenAIも10月23日、内部の訓練・評価環境の隔離を強化した経緯を公表した。対象は開発中のモデルを使う研究環境で、一般提供サービスとは利用条件が異なる。9月20日には、研究用モデルがDNSリゾルバーの設定不備を利用し、限定的に実際のインターネットへアクセスした。この事案を受け、開発中の最先端モデルの訓練・評価を一時停止した後、対策と評価を経て、10月1日に強化学習と社内でのモデル実行（推論）を再開したという。
同社は、最先端モデルの訓練では実際のインターネットへ接続させない方針を採り、代わりにキャッシュされたWebなどを使うオフライン環境を用意している。さらに、仮想マシン、監視、ネットワークなど複数の層で防御を重ねている。
その防御が実際に機能するかを確かめるため、研究環境を複製した隔離環境で、AIエージェントに制限の突破を試みさせた[6]。検証用のエージェントには、公開予定のGPT-6 Astra Cyberや社内の最先端モデルなどを使い、許可されていない外部接続や操作につながる弱点を調べた。この検証では、冒頭で紹介したBrotliの脆弱性も見つかった。同社は、将来のモデルが未知の弱点を見つける可能性を見込み、こうした検証を継続し、訓練・評価を安全に進められるか判断する材料にしている。
小型の仮想マシン（microVM）で実行環境を隔離するOSSとして、MicrosoftがMITライセンスで公開しているNVXもある。LinuxをゲストOSとして動かし、信頼できないコードを実行する環境を隔離する[7]。
認証情報を守り、接続後の操作も管理する
実行環境の隔離に加え、認証情報をエージェントにどう使わせるかも重要になる。企業向けの実行基盤や、個人が使うログインの仕組みでも、その扱いを制御する取り組みが進んでいる。
Google Cloudが10月22日に発表したAgent Compute Engineは、エージェントごとに独立したOSカーネルを持つmicroVMを用意し、実行環境を隔離する。それぞれのmicroVMには、そこで動くエージェントを識別するため、有効期間の短い認証情報を持たせる。外部サービスへ接続するための認証情報はmicroVM内には置かず、外部への通信時にmicroVMの外側で付与する。利用者向けには、今後数カ月以内のプレビュー提供を予定している。
サービス間の認証では、保存し続ける秘密情報そのものを減らす動きもある。Vercelは10月22日、長期の固定キーから、OIDC（OpenID Connect）を使った短命のトークンによる認証への移行を促す施策を発表した[8]。Vercel上のアプリケーションには、Vercelがその識別情報を含むトークンを発行する。接続先のサービスはトークンを検証し、設定された条件に基づいて、どの範囲のアクセスを許可するかを決める。漏えいしたトークンも期限が過ぎれば使えなくなるため、固定キーに比べて悪用できる期間を短くできる。
個人向けには、1Passwordが10月22日に1Password for Agentsを発表した。エージェントがログインを求めると、利用者が認証情報を選んで承認し、1Passwordがログイン画面へ直接入力する。これにより、エージェントはパスワードを受け取ったり保管庫全体へアクセスしたりせずに、ログイン後の作業を続けられる。発表時点では、Meta Museなどとの連携を数日以内に順次提供すると案内している[9]。
1PasswordのFAQでは、ログイン後に見られる情報や実行できる操作は、エージェントとWebサイトによって変わると説明している。認証情報を保護する仕組みと併せて、どのアカウントを使わせ、どの情報へのアクセスや操作を任せるかも決める必要がある。
AIを使った形式検証で、コードがクラッシュしないことを証明する
冒頭のClinton氏の見通しは、高いサイバー能力を持つ安価なAIモデルが開発現場に普及し、脆弱性をリリース前に防げるようになるというものだった。こうした開発を支える手法として、コードが特定の性質を満たすことを数学的に確かめる形式検証にも進展がある。
AnthropicとTheoremが10月22日に発表した研究では、オープンソースライブラリの既存のテストを利用した。テスト用コードのエントリーポイントは、入力データを受け取り、ライブラリの処理を実行する。テストでは、このエントリーポイントにさまざまなデータを繰り返し与え、プログラムのクラッシュ（異常終了）を引き起こす入力を探す。ただし、すべての入力を試し尽くすことはできない。
そこで研究チームは、入力を一つずつ試す代わりに、エントリーポイントから実行されるコードがクラッシュしないことを数学的に証明する方法を採った。具体的には、サイズが64MB未満であれば、どのような内容のデータを入力してもクラッシュしないことをClaudeに証明させた。Claudeは途中で見つけた不具合を修正しながら証明を作り、研究チームは証明支援系Rocqでその証明を検査した。その結果、123のオープンソースライブラリにある計239カ所のエントリーポイントについて、クラッシュしないことを証明できたという。
ただし、この証明は、CPUの命令セットRISC-V向けにコンパイルしたコードを、Linux上で単一スレッドで動かすことなどを前提としている[10]。また、証明したのは各エントリーポイントから実行されるコードがクラッシュしないことであり、ライブラリ全体のあらゆる脆弱性がなくなったという結果ではない。研究チームは、AIで証明を書く負担を減らし、形式検証をより多くのソフトウェアへ適用することを目指している。
OpenAIでサイバー安全対策を担当するFouad Matin氏は、9月に「サイバーセキュリティのAGI時代へようこそ」と述べていた[11]。AIを防御に使う取り組みと、そのAIの行動を制御する取り組みが、並行して進んでいる。
來源：gihyo.jp · gihyo.jp