カスタムGPTがクラウドバックドアとなるとき：ChatGPT SSRFハッキングとAIセキュリティの未来

セキュリティの世界に長くいると、やがて悪い癖が出てくる。SSRFの脆弱性を悪用したカスタムGPTを使ってChatGPTがハッキングされ、秘密が暴露された」という最近の話は、教科書的な例だ。カスタムGPTの便利なActions機能のように見えたものは、OpenAIのクラウド環境へのトンネルであることが判明した。エキゾチックなプロンプトの魔術でもなく、"AIマジック "の失敗でもなく、非常に古いバグ、サーバーサイドリクエストフォージェリが非常に新しいプラットフォームで再発見されただけなのだ。

だからこそ、この事件は重要なのだ。この事件は、AIが不正を働いたという誇大広告の見出しではない。ひとたびLLMを実際のインフラに組み込めば、アプリケーションとクラウドのセキュリティに関する従来のルールが復活するということを思い起こさせるものだ。モデルは新しくても、根本的な間違いはそうではないのだ。

エクスプロイトの再構築：「アクションの追加」からクラウドトークンまで

何が起こったのかを理解するためには、カスタムGPTがどのように機能するのかを見る必要があります。OpenAIのインターフェイスでは、アクションを定義することができます。アクションは、基本的にOpenAPIスキーマに基づいてGPTが呼び出すことができる外部のHTTP APIです。ユーザーにとって、これはGPTに "スーパーパワー "を与えるようなものです：データをフェッチしたり、ワークフローをトリガーしたり、内部システムに接続したりできます。データの取得、ワークフローのトリガー、内部システムへの接続などです。ボンネットの下には、OpenAIのインフラストラクチャ内で動作するバックエンドのHTTPクライアントがあり、あなたが記述したURLを喜んで呼び出し、レスポンスをモデルにフィードバックします。

Open Securityの研究者がまさにそれに気づいた。カスタムGPTで遊んでいるときに、彼らはおなじみのパターンを見た：ユーザーが制御するURL、ライブリクエストを送信する「テスト」ボタン、明らかにクラウド環境内で実行されているサーバー。クラウドのペンテストをしたことがある人なら、その直感に気づくだろう。そのサーバーを騙して、自分の代わりに内部アドレスを呼び出せるかどうかをチェックするのだ。これがSSRFの本質だ。

クラウド環境では、最も重要な内部ターゲットはほとんど常にメタデータ・サービスである。Azureでは、他のクラウドと同様、リンクローカルアドレスにある 169.254.169.254.VMやコンテナの内部から、このエンドポイントはインスタンスの詳細を明らかにすることができ、さらに重要なことに、ワークロードがクラウド管理APIを呼び出すことを可能にする短命のトークンを発行することができる。クラウドの外からは、このエンドポイントに到達することはできない。SSRFが非常に重要な理由はまさにそこにある。サーバーの有利な立場を乗っ取り、外部の攻撃者であるあなたにはできないことをさせるのだ。

研究者の最初の障害は、カスタムGPTアクションがHTTPS URLしか許可しないのに対し、メタデータ・サービスはHTTPのみであることだった。一見すると、この制限は防御策のように見えるが、実際にはパズルのピースが1つ増えたに過ぎない。回避策は簡単で、研究者の管理下にある外部のHTTPSドメインを登録し、そのドメインに302リダイレクトで応答させることである。 http://169.254.169.254 メタデータのURLで、Actionsバックエンドがリダイレクトに従うかどうかを確認する。リダイレクトされた。突然、カスタムGPT設定の何の変哲もないHTTPS呼び出しが、内部クラウドメタデータエンドポイントへのHTTP呼び出しになったのだ。

しかし、Azureのメタデータサービスは完全にナイーブというわけではない。カジュアルな悪用を防ぐために、特別なヘッダーを要求している、 メタデータ: trueヘッダはリクエストごとに返される。ヘッダーがない場合、サービスは実データの開示を拒否する。この時点で、システムは再び安全になったように思えるかもしれない。なぜなら、アクションを定義するために使われるOpenAPIスキーマインターフェースは、任意のヘッダーコンフィギュレーションを公開しないからである。しかし、大規模なシステムでコンフィギュレーション・サーフェスが1つしかないことはまずない。この場合、Actions機能は、外部サービスを配線するときに定義できる「APIキー」やその他の認証ヘッダーのアイデアもサポートしている。これらのヘッダーは、アウトバウンドリクエストに自動的に付加される。

これで連鎖は完了した。偽の「APIキー」を定義することで、そのヘッダー名は文字通り メタデータ で、その値は 真の研究者は、バックエンドにAzure IMDSが期待するヘッダーを含めるよう説得した。これをリダイレクトのトリックと組み合わせると、Custom GPT ActionsバックエンドからメタデータサービスへのSSRFチャネルができます。 メタデータ: true ヘッダーを使用する。

このチャネルが確立されると、あとはほとんど機械的だった。リサーチャーはメタデータサービスに、よく知られたIMDSパスを使って、Azure Management API用のOAuth2トークンを要求した。その応答には、ChatGPTインフラストラクチャが使用しているクラウドIDにバインドされたアクセストークンが含まれていた。そのトークンは、最低でも管理エンドポイントに問い合わせることができ、そのIDの権限の大きさによっては、機密性の高いリソースに到達できる可能性がありました。その時点で、研究者は作業を中断し、OpenAIのバグ報奨金プログラムを通じて発見を報告しました。

この連鎖を際立たせているのは、攻撃者がシェルアクセスやソースコード、HTTPスタックの古典的なバグを必要としなかったことだ。すべては通常の設定画面の中で起こった：URL、認証設定、そしていたずらを忠実に実行するテストボタン。

SSRF式プローブの小さなコードスケッチ

これをより具体的にするために、セキュリティエンジニアが「Actions-style」HTTPクライアントのサニティチェックに使用するような、非常に小さな内部ヘルパースクリプトを想像してみてください。目標は、本番環境で実際のメタデータサービスをヒットすることではなく、ステージング環境やラボ環境で予期しないリダイレクトや内部IPホップをプローブする習慣を体系化することである：

インポートリクエスト
from urllib.parse import urljoin

def trace_request(base_url: str, path: str = "/")：
    url = urljoin(base_url, path)
    print(f"[+] {url}をリクエストしています")
    try：
        resp = requests.get(url, timeout=3, allow_redirects=True)
    except Exception as e：
        print(f"[!] エラー: {e}")
        リターン

    print(f"[+] 最終URL: {resp.url}")
    print(f"[+] ステータス: {resp.status_code}")
    print("[+] リダイレクトチェーン:")
    for h in resp.history：
        print(f" {h.status_code} -> {h.headers.get('Location')}")

    # 非常に大まかなヒューリスティック: 内部IPに着地したら警告する
    if resp.raw._connection and hasattr(resp.raw._connection, "sock")：
        ピア = resp.raw._connection.sock.getpeername()[0]: ピア = resp.raw._connection.sock.getpeername()[0
        print(f"[+] ピアIP: {peer}")
        if peer.startswith("10.") or peer.startswith("192.168.") or peer.startswith("169.254.")：
            print("[!] Warning: バックエンドが内部アドレスへのリダイレクトを実行しました")

if __name__ == "__main__"：
    # 例: あなた自身のラボでコントロールされたテストエンドポイントに置き換える
    trace_request("")

このようなスクリプトはChatGPTを "悪用 "するものではありませんが、同じような調査の形を捉えています。安全だと思われる外部URLから開始し、リダイレクトをたどり、HTTPクライアントが突然内部またはリンクローカルのIPレンジに接続していることに気づいたら、大声で文句を言うのです。そのパターンを自動化し、独自のAIアクションを動かすコンポーネントに対して実行することは、インシデントについて読むだけよりもはるかに有用である。

これは「AIのバグ」ではなく、新しいステージでの旧態依然としたクラウドの悪用である。

これを「ChatGPTがハッキングされた」と読み替えて、次に進みたいのはやまやまだ。そのフレーミングは深い教訓を見逃している。モデル自体には何も問題はない。禁止された機能を解除するようなプロンプトもなかった。LLMは言われたとおりに、アクションを呼び出し、結果を読み、それを要約した。脆弱性は、LLMと外界との間の接着剤の中に完全に存在していたのだ。

この接着剤にこそ、セキュリティチームが重点を置く必要がある。LLMにツール、アクション、プラグインを呼び出す機能を持たせるときはいつでも、事実上、LLMをインフラストラクチャのプログラム可能なクライアントに変えることになる。以前は、ユーザーが手動でAPIを呼び出し、あなたはその入力を確認していた。今、ユーザーはモデルに指示を与え、モデルはそれをAPI呼び出しに変換する。モデルは、敵対的な意図があなたのバックエンドに到達するもう一つの方法となる。

このレンズを通して見ると、このインシデントは単にOWASP SSRFを別のコスチュームにしたものだ。ユーザーの影響を受けたURL、内部または特権エンドポイントに到達可能なサーバー、欠落または不完全な出口制御、通常のワークロードからアクセス可能なクラウドメタデータサービスなど、条件はすべておなじみのものだ。違いは、エントリー・ポイントがもはや古典的なウェブ・フォームやJSONフィールドではなく、カスタムGPTをより強力にするために設計されたコンフィギュレーション・ブロックであることだ。

これは、爆発半径が重要な理由でもあります。影響を受けたサーバーはランダムなマイクロサービスではなく、ChatGPTのマルチテナントインフラストラクチャの一部であり、OpenAIのAzure環境内にありました。IMDSを介して取得されたトークンは、すでに意味のあるアクセス権を持っているワークロードに属していました。たとえローカルの防御が攻撃者ができることを制限したとしても、リスクプロファイルは忘れられたテストVMとは根本的に異なります。

統合ハブとしてのAI：攻撃対象の拡大と信頼の境界の移動

このバグの背後にあるより興味深い話は、アーキテクチャにある。AIプラットフォームは急速に統合ハブになりつつある。営業チームのためのカスタムGPTは、CRM、請求システム、ドキュメントストアと話すかもしれない。セキュリティに特化したGPTは、スキャナー、発券システム、CI/CDと話すかもしれない。いずれの場合も、LLMが資産なのではなく、コネクターの背後にあるデータとアクションが資産なのだ。

その現実を受け入れれば、精神的な脅威モデルを変えなければならない。AIセキュリティ」を、プロンプトの注入、データ漏洩、有害な出力とだけ考え続けることはできない。ネットワークの境界、クラウドのアイデンティティ、テナントの分離など、華やかさに欠ける質問もしなければならない。

Actionを実行するインフラは、実際にネットワーク上で何と会話できるのだろうか？多くのクラウド環境のデフォルトは、「DNSが解決する限り、アウトバウンドは何でも許される」というものだ。これはサービスが比較的シンプルで、エンジニアが柔軟性を求めていた時代には理にかなっていた。しかし、LLMプラットフォームを導入すると、すべてのテナントが突然、コードではなくコンフィギュレーションによって新しい送信先を提案できるようになる。もし強力なイグレスポリシーがなければ、あなたは事実上プログラマブルなSSRFランチャーを作ったことになる。

これらのワークロードで使用されるIDは、実際にどの程度の権限を持っているのだろうか？ChatGPTのケースでは、研究者はAzure Management APIのトークンをリクエストすることができました。そのトークンがロールの割り当てによって制限されていたとしても、価値の高い秘密であることに変わりはありません。多くの組織では、"プラットフォーム・インフラ "に広い権限を与えようとする誘惑が強い。ユーザーの入力によって間接的に動かされる可能性のあるもの、特にAIを通じて動かされる可能性のあるものにとって、この誘惑は危険だ。

テナント間、コントロールプレーンとデータプレーン間、AIランタイムとクラウドの他の部分との間の信頼の境界は、一体どこにあるのだろうか？よく設計されたシステムは、あるテナントのコンフィギュレーションが敵対的なものになる可能性があること、そのテナントに代わって発信されるコールが敵対的なものになる可能性があること、そしてアクションからメタデータ、管理APIへの昇格が現実的な攻撃者の目標であることを想定する必要がある。このような観点から、厳密なネットワーク・セグメンテーション、ポリシーを実行するコンパニオン・サイドカー、専用サービス・アイデンティティといったパターンを、"あったらいいな "ではなく譲れないものにする。

ある事件から再現可能なテスト手法へ

擁護者と構築者にとって、この話の本当の価値は特定のバグではなく、それが示すテストの考え方である。研究者は本質的に、カスタムGPTアクションを奇妙な新種のHTTPクライアントとして扱い、おなじみのチェックリストを通して歩いた。

この精神的なチェックリストこそ、AIプラットフォーム向けの最新の侵入テスト・ワークフローで自動化されるべきものだ。ヘッドラインや報奨金レポートを待つのではなく、チームは日常的に自分たちのカスタムGPTインフラ、プラグインエコシステム、ツールチェーンをターゲットにするべきだ。

これをもう少し具体的にするために、「AIアクションのSSRFレビュー」は、次のようなシンプルで反復可能なシーケンスと考えることができる：

自分の環境についてこのような表を作成すれば、テストの自動化も説明も非常に簡単になる。社内のプレイブックに組み込んだり、ベンダーと共有したり、将来のAI機能が同じ基準で管理されるようにすることもできる。

ここで、専門的でAIを意識したセキュリティ・ツールが重要になる。一般的なウェブスキャナーは、ネットワークコールをアクションの背後に隠すUIをどのようにナビゲートするか、あるいは、GPT定義の内部で使用されるOpenAPIスキーマをどのように推論するかを知らないかもしれません。対照的に、PenligentのようなAI主導のペンテストプラットフォームは、これらのスキーマや設定をファーストクラスの入力として扱うことができます。一連のカスタムGPTや他のAIツールのアクション設定をエクスポートし、エージェント型テストパイプラインに送り込み、SSRF条件、安全でないリダイレクト、制限のないネットワークアクセス、メタデータの露出を系統的に調査させるワークフローを想像してみてください。

Penligentの自動化と人間によるループ制御を組み合わせるという哲学は、このパターンによく合致している。エージェントはすべてのツールの定義を列挙し、URL やホスト名を受け付けるエンドポイントの候補となるペイロードを生成し、好奇心旺盛な攻撃者が試みるであろうことをシミュレートするスクリプト化されたトラフィックをドライブすることができる。一旦システムが有望な挙動を発見すると、例えば、見かけ上外部の HTTPS エンドポイントが内部 IP 範囲へのリダイレクトをたどるような挙動を発見すると、リクエストログ、レスポンススニペット、推測される内部トポロジーなど、これを証拠として表面化することができる。例えば、クラウドのメタデータ・ルートに特化したピボットや、返されたトークンが管理 API に対して有効かどうかの検証をシステムに依頼するなどである。

このようなワークフローは2つのことを実現する。AIプラットフォームを、ウェブアプリケーションやAPIがすでに享受しているのと同じエビデンス主導のセキュリティループに組み込み、攻撃者が必然的に使用するLLM機能を、防御者のために活用するのだ。ChatGPTを襲ったバグは、もはや一過性のサプライズではなく、新しいインテグレーションを導入したり、Actionsのインフラを変更したりするたびに実行できるリグレッション・スイートのテスト・ケースとなる。

AIプラットフォームの上に構築するチームのための実践的な教訓

もしあなたがAIサービスを構築するのではなく、利用するセキュリティ・エンジニアやアーキテクトであるなら、この事件はまだ大いに関係があります。社内でカスタムGPTに触れることがないとしても、おそらく社内のAPI、ダッシュボード、文書ストアをAIエージェントや何らかのコ・パイロットに公開していることでしょう。アイデアは転用可能だ。

最初のステップは、LLMだけをセキュリティレビューが必要なものとして扱うのをやめることです。明示的なツールであれ、アクションであれ、間接的なウェブフックであれ、モデルにあなたの環境にコールバックさせる機能はすべて、潜在的な攻撃グラフとして見なければなりません。AIコンポーネントがどの内部サービスと会話できるのか、どのようなIDを使用するのか、敵対的なユーザーが意図的にこれらの機能を拡張しようとした場合にどうなるのか、ある程度自信を持って答えられるようにしておく必要があります。

第二のステップは、AIグルー・コードをカバーするようにテスト・プログラムを拡張することである。侵入テストを依頼したり、社内のレッドチームによる演習を実施したりする際には、ツールのコンフィギュレーション・サーフェス、URLやヘッダーの構築方法、AIランタイムと機密サービス間のネットワーク・パス、メタデータ・エンドポイント周辺の保護など、AIの統合がスコープに明示的に含まれていることを確認する。実際の攻撃者が行うように、誰かがどこかでこれらを悪用しようとした証拠を求めてください。

第三のステップは、この攻撃対象が縮小しないことを受け入れることである。より多くのビジネスプロセスがLLMに接続されるようになれば、より多くのアクション、より多くのプラグイン、より多くのバックグラウンドサービスが、プロンプトに代わって作業を実行するようになる。つまり、明確な脅威モデル、ベースラインアーキテクチャパターン、自動化されたテストフロー、Penligentのようなシステムを利用したツールなどである。

見出しを越えて

カスタムGPT SSRFハックは、一ベンダーが一度だけ恥をかいたと誤解されやすい。プレビューとして読む方が生産的だ。AIプラットフォームは、ユーザー、モデル、API、クラウドインフラをつなぐオーケストレーションレイヤーとして急速に成長している。その役割にはパワーがつきものであり、パワーは常に、何か問題が起きたときの大きな爆発半径を伴う。

この物語で勇気づけられるのは、前進への道筋も示していることだ。この脆弱性を発見したのは、新しい状況下で古い直感に従った研究者である。標準的なバグ報奨金チャンネルを通じて報告された。そして修正された。私たちは、理想的にはセキュリティとAIの両方を理解するツールの助けを借りて、同じプレイブックを自分たちのシステムに積極的に適用することができる。

そうすれば、この事件の遺産は「ChatGPTはかつてSSRFを持っていた」というだけのものではなくなります。モデルをより大きなシステムの中の1つのコンポーネントとして扱い、統合を重大な攻撃対象として扱い、Penligentのようなプラットフォームであろうと、社内のパイプラインであろうと、自動化と人間の洞察力を使って、漠然とした懸念を具体的でテスト可能な、証拠に裏打ちされた保証に絶えず変えていくのだ。これこそ、Mediumで語る価値のあるストーリーであり、エンジニアリング組織の中で生きる価値のあるストーリーなのだ。