Azure Machine Learning サービスのステルス永続性

Azure Machine Learning (AML) では、情報漏えいの脆弱性により、攻撃者がコンピューティング インスタンス (CI) から機密データを取得することができました。 「dsimountagent」エージェントの欠陥により、ストレージ アカウントのアクセス キーが公開されました。このキーは、キーのローテーション、ワークスペース シークレットの取得、マネージド ID の Azure Active Directory (AAD) トークンの収集に使用されました。キーのローテーション後でも、証明書と秘密キーのペアにより、ストレージ アカウント アクセス キーの取得が可能になりました。正規のリクエストと悪意のあるリクエストによって生成されたログは類似していましたが、IP アドレスなどの特定の指標がありませんでした。この脆弱性は Microsoft に報告されましたが、重大度が低いと判断され、修正の実装には 45 日以上かかりました。これは、脆弱な資格情報が重大なセキュリティ リスクにつながる可能性があるため、AML ワークスペースでストレージ アカウントを保護することの重要性を強調しています。

By Nitesh Surana, David Fiser

ニテーシュ・スラナ、デヴィッド・ファイザー

In our previous article, we examined an information disclosure vulnerability found in one of the cloud agents used on compute instances (CIs) that were created in the Azure Machine Learning (AML) service. This vulnerability could let network-adjacent attackers disclose sensitive information from the CI remotely. In the third installment of this series about the security issues found in AML, we detail how an attacker could achieve stealthy persistence in an AML workspace.

前回の記事では、Azure Machine Learning (AML) サービスで作成されたコンピューティング インスタンス (CI) で使用されるクラウド エージェントの 1 つで見つかった情報漏えいの脆弱性を調べました。この脆弱性により、ネットワークに隣接する攻撃者が CI からの機密情報をリモートで開示する可能性があります。 AML で見つかったセキュリティ問題に関するこのシリーズの 3 回目では、攻撃者が AML ワークスペースでステルス永続化を達成する方法について詳しく説明します。

Using Azure CLI from Compute Instances

One of the issues that developers face while working with cloud services is credential management of access keys, secrets, passwords, and the like. Credentials being stored in code or in files on cloud resources increases risk of exposure in the event of a compromise. To circumvent this particular issue, Azure’s managed identities feature enables users to avoid storing credentials in code (Figure 1). Users and applications requiring access to other resources essentially fetch Entra ID tokens to gain access to a desired service.

コンピューティング インスタンスから Azure CLI を使用するクラウド サービスを使用する際に開発者が直面する問題の 1 つは、アクセス キー、シークレット、パスワードなどの資格情報の管理です。認証情報がクラウド リソース上のコードまたはファイルに保存されていると、侵害が発生した場合に漏洩のリスクが高まります。この特定の問題を回避するために、Azure のマネージド ID 機能を使用すると、ユーザーは資格情報をコードに保存することを回避できます (図 1)。他のリソースへのアクセスを必要とするユーザーとアプリケーションは、基本的に Entra ID トークンをフェッチして、必要なサービスへのアクセスを取得します。

Figure 1. Brief overview of how managed identities work

図 1. マネージド ID の仕組みの概要

Managed identities support various services in Azure, including AML. In AML, users can give compute targets, such as CIs and compute clusters, system-assigned or user-assigned managed identities. To access other Azure services, role-based access control (RBAC) permissions can be manually assigned to a created managed identity using roles.

マネージド ID は、AML を含む Azure のさまざまなサービスをサポートします。 AML では、ユーザーは CI やコンピューティング クラスターなどのコンピューティング ターゲット、システム割り当てまたはユーザー割り当てのマネージド ID を指定できます。他の Azure サービスにアクセスするには、ロールを使用して、作成されたマネージド ID にロールベースのアクセス制御 (RBAC) アクセス許可を手動で割り当てることができます。

On CIs, one can use the Azure Command-Line Interface (CLI) to create and manage other Azure resources. One can work on Azure services (based on their RBAC permissions) by signing in using the Azure CLI as the CI owner or the assigned managed identity. To sign in as the assigned managed identity, one can run “az login –identity,” as shown in Figure 2.

CI では、Azure コマンド ライン インターフェイス (CLI) を使用して、他の Azure リソースを作成および管理できます。 CI 所有者または割り当てられたマネージド ID として Azure CLI を使用してサインインすることで、(RBAC アクセス許可に基づいて) Azure サービスを操作できます。割り当てられたマネージド ID としてサインインするには、図 2 に示すように、「az login –identity」を実行します。

Figure 2. Using Azure CLI to sign in as a managed identity

図 2. Azure CLI を使用してマネージド ID としてサインインする

While inspecting the traffic generated upon running “az login --identity,” we came across the following request (Figure 3):

「az login --identity」の実行時に生成されたトラフィックを検査しているときに、次のリクエストを発見しました (図 3)。

Figure 3. Traffic generated on running “az login --identity”

図 3. 「az login --identity」の実行時に生成されるトラフィック

As Figure 3 shows, the request is sent to port 46808 on the local interface 127.0.0.1. Since we have access to the CI, we found that a process named “identityresponderd” listens on port 46808. This process runs as a daemon and is installed as a systemd service across all CIs created under AML. The service is called “AZ Batch AI Identity Responder Daemon.” While examining the service, we noticed that the service fetches its environment variables from certain files as defined in the “EnvironmentFile” parameter (Figure 4).

図 3 に示すように、リクエストはローカル インターフェイス 127.0.0.1 のポート 46808 に送信されます。 CI にアクセスできるため、「identityresponderd」という名前のプロセスがポート 46808 でリッスンしていることがわかりました。このプロセスはデーモンとして実行され、AML で作成されたすべての CI にわたって systemd サービスとしてインストールされます。このサービスは「AZ Batch AI Identity Responder Daemon」と呼ばれます。サービスを調査しているときに、サービスが「EnvironmentFile」パラメータで定義されている特定のファイルから環境変数を取得していることに気付きました (図 4)。

Figure 4. Service configuration of Azure Batch AI Identity Responder Daemon

図 4. Azure Batch AI Identity Responder デーモンのサービス構成

The file /etc/environment.sso contains two environment variables named “MSI_ENDPOINT” and “MSI_SECRET” that are used in the GET request shown in Figure 5.

ファイル /etc/environment.sso には、図 5 に示す GET リクエストで使用される「MSI_ENDPOINT」および「MSI_SECRET」という 2 つの環境変数が含まれています。

Figure 5. “MSI_ENDPOINT” and “MSI_SECRET” defined in “/etc/environment.sso”

図 5. 「/etc/environment.sso」で定義された「MSI_ENDPOINT」と「MSI_SECRET」

However, we are still querying a local endpoint. While examining outbound communication of the binary, we found that the binary uses a combination of an x509 certificate and a private key to communicate with a public endpoint defined in “/mnt/azmnt/.nbvm” as an environment variable named “certurl” (Figure 6).

ただし、引き続きローカル エンドポイントにクエリを実行しています。バイナリのアウトバウンド通信を調査したところ、バイナリは x509 証明書と秘密キーの組み合わせを使用して、「certurl」という名前の環境変数として「/mnt/azmnt/.nbvm」に定義されたパブリック エンドポイントと通信していることがわかりました (図6）。

Figure 6. Contents of “/mnt/azmnt/.nbvm” with public endpoint defined in “certurl” key

図 6. 「certurl」キーでパブリック エンドポイントが定義された「/mnt/azmnt/.nbvm」の内容

From the service configuration, we also saw that there are syslog entries observed for standard output and standard error file descriptors from the binary. To get an initial idea of what a service possibly does, one can use the generated logs. The endpoint defined in “certurl” is also observed in the syslog entries that are generated when “az login –identity” is run, as shown in Figure 7.

サービス構成からは、バイナリからの標準出力および標準エラー ファイル記述子について syslog エントリが観察されることもわかりました。サービスが何を行うのかを最初に把握するには、生成されたログを使用できます。図 7 に示すように、「certurl」で定義されたエンドポイントは、「az login –identity」の実行時に生成される syslog エントリでも確認されます。

Figure 7. Syslog entries with the public endpoint defined in “certurl"

図 7. 「certurl」で定義されたパブリック エンドポイントを含む Syslog エントリ

With this information, we crafted the final request that is sent to the public endpoint (Figure 8):

この情報を使用して、パブリック エンドポイントに送信される最終リクエストを作成しました (図 8)。

Figure 8. POST request to fetch Entra ID JWT using “identityresponderd”

図 8. 「identityresponderd」を使用して Entra ID JWT を取得する POST リクエスト

In the response, we got the Entra ID JWT of the identity (Figure 9). This leads us to wonder if crafting an attack scenario wherein an attacker has exfiltrated the certificate and private key from a CI allows the attacker to fetch the Entra ID JWT of the CI’s assigned identity. Perhaps the assigned identity could even be fetched by an attacker running in a non-Azure environment. It was worth testing this scenario since the endpoint defined in the “certurl” environment variable could be successfully resolved from the internet.

応答で、アイデンティティの Entra ID JWT を取得しました (図 9)。このことから、攻撃者が CI から証明書と秘密キーを窃取する攻撃シナリオを作成することで、攻撃者が CI に割り当てられた ID の Entra ID JWT を取得できるようになるのではないかと疑問に思うようになりました。おそらく、割り当てられた ID は、Azure 以外の環境で実行されている攻撃者によって取得される可能性もあります。 「certurl」環境変数で定義されたエンドポイントがインターネットから正常に解決できるため、このシナリオをテストする価値はありました。

Figure 9. Response containing the Entra ID JWT of the identity

図 9. ID の Entra ID JWT を含む応答

However, upon trying to recreate the scenario of using the certificate and private key from the CI to fetch the Entra ID JWT, we got a 401 unauthorized response. Hence, our thought process and assumption were that the certificate and key are restricted for usage within the boundary of the CI. Additionally, the x509 certificate for every CI had a unique thumbprint.

ただし、CI からの証明書と秘密キーを使用して Entra ID JWT を取得するシナリオを再作成しようとすると、401 不正な応答が返されました。したがって、私たちの思考プロセスと仮定は、証明書とキーは CI の境界内での使用に制限されるというものでした。さらに、すべての CI の x509 証明書には固有の拇印がありました。

We now explore why our finding was just an assumption as we probed the “dsimountagent” agent.

ここで、「dsimountagent」エージェントを調査する際に、なぜ私たちの発見が単なる仮定であったのかを探ります。

A closer look at “dsimountagent”

While examining the functionality of “dsimountagent,” we observed that the agent makes sure that the file share of the AML workspace’s Storage Account is mounted on the CI. As shown in Figure 10, it checks for the mount status every 120 seconds (about two minutes).

「dsimountagent」の詳細「dsimountagent」の機能を調べていると、エージェントが AML ワークスペースのストレージ アカウントのファイル共有が CI にマウントされていることを確認しました。図 10 に示すように、120 秒 (約 2 分) ごとにマウント ステータスがチェックされます。

Figure 10. Main purpose of “dsimountagent” on a compute instance

図 10. コンピューティング インスタンスにおける「dsimountagent」の主な目的

As we can observe in the systemd service config of the daemon (Figure 11), the agent fetches its configuration as environment variables from a file and, like “identityresponderd,” there are syslog entries for this service too. To mount the file share on the CI, the service fetches the AML workspace’s Storage Account’s access key from a public endpoint defined in an environment variable named “AZ_BATCHAI_XDS_ENDPOINT.” This key value pair is stored in a file named “dsimountagentenv” under the “/mnt/batch/tasks/startup/wd/dsi/” directory. Notably, in the first entry of this series, this file was previously observed to contain the Storage Account’s access key in clear text.

デーモンの systemd サービス構成 (図 11) で確認できるように、エージェントはその構成を環境変数としてファイルから取得します。また、「identityresponderd」と同様に、このサービスにも syslog エントリがあります。ファイル共有を CI にマウントするために、サービスは、「AZ_BATCHAI_XDS_ENDPOINT」という名前の環境変数で定義されたパブリック エンドポイントから AML ワークスペースのストレージ アカウントのアクセス キーを取得します。このキーと値のペアは、「/mnt/batch/tasks/startup/wd/dsi/」ディレクトリの下の「dsimountagentenv」という名前のファイルに保存されます。特に、このシリーズの最初のエントリでは、このファイルにはストレージ アカウントのアクセス キーがクリア テキストで含まれていることが以前に観察されました。

Figure 11. Service configuration of Azure Batch AI DSI Mounting Agent

図 11. Azure Batch AI DSI マウント エージェントのサービス構成

To communicate with the public endpoint, “dsimountagent” uses the same pair of x509 certificate and private key used by “identityresponderd.” While examining outbound requests to the public endpoint, we crafted the following POST request shown in Figure 12.

パブリック エンドポイントと通信するために、「dsimountagent」は、「identityresponderd」で使用されるのと同じ x509 証明書と秘密キーのペアを使用します。パブリック エンドポイントへのアウトバウンド リクエストを調査する際に、図 12 に示す次の POST リクエストを作成しました。

Figure 12. POST request to fetch workspace information using “dsimountagent”

図 12. 「dsimountagent」を使用してワークスペース情報を取得するための POST リクエスト

For readability, a few headers are removed from the POST request in Figure 12. The response for this POST request contained the resource IDs for the Storage Account, key vault, container registry, application insights, and metadata about the workspace such as tenant ID, subscription ID, and whether the CI VNet is publicly reachable, among others. It is possible to think of this as the “whoami” of the AML workspace.

読みやすくするために、図 12 の POST 要求からいくつかのヘッダーが削除されています。この POST 要求に対する応答には、ストレージ アカウント、キー コンテナー、コンテナー レジストリ、アプリケーションの分析情報、およびテナント ID などのワークスペースに関するメタデータのリソース ID が含まれていました。サブスクリプション ID、CI VNet がパブリックにアクセス可能かどうかなど。これは、AML ワークスペースの「whoami」と考えることができます。

With the same request URI and endpoint, we came across another request where the “RequestType” key in the POST request’s body was set to “getworkspacesecrets.” The response contained the Storage Account name and an encrypted JWE of the Storage Account’s access key. The encrypted JWE is decrypted using two other environment variables named “AZ_LS_ENCRYPTED_SYMMETRIC_KEY” and “AZ_BATCHAI_CLUSTER_PRIVATE_KEY_PEM,” defined in the file responsible for populating environment variables for the daemon (Figure 13).

同じリクエスト URI とエンドポイントを使用して、POST リクエスト本文の「RequestType」キーが「getworkspacesecrets」に設定されている別のリクエストを発見しました。応答には、ストレージ アカウント名と、ストレージ アカウントのアクセス キーの暗号化された JWE が含まれていました。暗号化された JWE は、デーモンの環境変数を設定するファイルに定義されている「AZ_LS_ENCRYPTED_SYMMETRIC_KEY」と「AZ_BATCHAI_CLUSTER_PRIVATE_KEY_PEM」という名前の他の 2 つの環境変数を使用して復号化されます (図 13)。

Figure 13. Decryption routine for Storage Account JWE

図 13. ストレージ アカウント JWE の復号化ルーチン

Since this request was also being performed from outside the CI using the compromised certificate and private key, an attacker post-compromise could fetch the Storage Account’s access key from outside the CI’s boundaries.

この要求は侵害された証明書と秘密キーを使用して CI の外部からも実行されていたため、侵害後の攻撃者は CI の境界の外部からストレージ アカウントのアクセス キーを取得する可能性があります。

In case a Storage Account’s access key is leaked or compromised, users can invalidate the compromised key by rotating the key. However, we found that the certificate and key pair could be used to fetch the Storage Account access key, even after the access keys were rotated, as we see in this video:

ストレージ アカウントのアクセス キーが漏洩または侵害された場合、ユーザーはキーをローテーションすることで侵害されたキーを無効にすることができます。ただし、次のビデオで見るように、アクセス キーがローテーションされた後でも、証明書とキーのペアを使用してストレージ アカウント アクセス キーを取得できることがわかりました。

For the two aforementioned cases, the body of the POST request is particularly interesting. Could there possibly be more candidates for the “RequestType” key? Since we had the “dsimountagent” binary (and a few more of such agents like “identityresponderd”), we investigated what else could be fetched using the certificate and private key combination.

前述の 2 つのケースでは、POST リクエストの本文が特に興味深いです。 「RequestType」キーの候補はさらにある可能性がありますか? 「dsimountagent」バイナリ (および「identityresponderd」などの同様のエージェントもいくつか) があったので、証明書と秘密キーの組み合わせを使用して他に何が取得できるかを調査しました。

Finding more “RequestType” candidates

The “dsimountagent” binary comes with debug symbols, as we noted in the second installment of this series. The functions corresponding to the “RequestType” values set to “getworkspace” and “getworkspacesecrets” were defined in a package called “hosttools.” These functions would, in turn, call another function named “generateXDSApiRequestSchema.” This function is responsible for creating the POST request’s body.

さらに多くの「RequestType」候補を見つけるこのシリーズの第 2 回で述べたように、「dsimountagent」バイナリにはデバッグ シンボルが付属しています。 「getworkspace」および「getworkspacesecrets」に設定された「RequestType」値に対応する関数は、「hosttools」というパッケージで定義されています。これらの関数は、次に「generateXDSApiRequestSchema」という名前の別の関数を呼び出します。この関数は、POST リクエストの本文を作成します。

Additionally, since we had multiple agents other than “dsimountagent,” such as “identityresponderd,” we found some candidates while enumerating the cross references of functions calling “generateXDSApiRequestSchema,” which we list here:

さらに、「dsimountagent」以外にも「identityresponderd」など複数のエージェントがあったため、「generateXDSApiRequestSchema」を呼び出す関数の相互参照を列挙する中でいくつかの候補を見つけました。これをここにリストします。

• GetAADToken
• GetACRToken
• GetACRDetails
• GetAppInsightsInstrumentationKey
• GetDsiUpdateSettings
• GenerateSAS

As we can see, there were quite a few interesting candidates to go for. In the following section, we examine “GetAADToken.”

GetAADTokenGetACRTokenGetACRDetailsGetAppInsightsInstrumentationKeyGetDsiUpdateSettingsGenerateSASA を確認すると、かなりの数の興味深い候補がありました。次のセクションでは、「GetAADToken」について調べます。

Fetching Entra ID token of an assigned managed identity

While examining the “GetAADToken” request type, we crafted the POST request body (Figure 14) to fetch a system-assigned managed identity.

割り当てられたマネージド ID の Entra ID トークンの取得「GetAADToken」要求タイプを調査する際に、システム割り当てのマネージド ID を取得するように POST 要求本文 (図 14) を作成しました。

Figure 14. POST request body to fetch a system-assigned managed identity Entra ID token

図 14. システム割り当てのマネージド ID Entra ID トークンを取得するための POST リクエスト本文

If there was a user-assigned managed identity, we would need to include the client ID, as shown in Figure 15.

ユーザー割り当てのマネージド ID がある場合は、図 15 に示すように、クライアント ID を含める必要があります。

Figure 15. POST request body to fetch a user-assigned managed identity Entra ID token

図 15. ユーザー割り当てのマネージド ID Entra ID トークンを取得するための POST リクエスト本文

The response would contain the Entra ID JWT of the managed identity assigned to the CI. Since we could perform the request outside the CI and fetch JWTs of managed identities, this finding doesn’t quite go along with how managed identities have been designed, as seen in the documentation for managed identities (Figure 16).

応答には、CI に割り当てられたマネージド ID の Entra ID JWT が含まれます。 CI の外部でリクエストを実行し、マネージド ID の JWT をフェッチできるため、この発見は、マネージド ID のドキュメント (図 16) に見られるように、マネージド ID の設計方法と完全には一致しません。

Figure 16. Microsoft documentation of system-assigned managed identities

図 16. システム割り当てマネージド ID に関する Microsoft のドキュメント

Managed identities are a way of keeping credentials off-code. It works in such a way that an application needing access to a certain resource will request a token from a managed identity service. The managed identity service is only reachable from the resource to which it has been assigned. For instance, if you assign a managed identity to an Azure virtual machine (VM), the managed identity service can only be reached from the Azure VM on a link-local unrouteable IP address like 169.254.169.254.

マネージド ID は、資格情報をオフコードに保つ方法です。これは、特定のリソースにアクセスする必要があるアプリケーションがマネージド ID サービスからトークンを要求するように機能します。マネージド ID サービスには、割り当てられているリソースからのみアクセスできます。たとえば、マネージド ID を Azure 仮想マシン (VM) に割り当てる場合、マネージド ID サービスには、169.254.169.254 などのリンクローカルのルーティング不可能な IP アドレス上の Azure VM からのみアクセスできます。

Previously, we found a similar issue in a serverless offering in Azure known as Azure Functions, wherein an attacker could leak the certificate from environment variables of the application container and use it to fetch the Entra ID JWT of the assigned managed identity outside the application container.

以前、Azure Functions として知られる Azure のサーバーレス製品でも同様の問題が見つかりました。この問題では、攻撃者がアプリケーション コンテナーの環境変数から証明書を漏洩し、それを使用してアプリケーション コンテナーの外部に割り当てられたマネージド ID の Entra ID JWT を取得する可能性があります。 。

How do the generated logs look?

It goes without saying that cloud-native logs are paramount in performing detection and response for security incidents, compliance, auditing, and various other purposes. To examine the logs generated from a legitimate request (that is, from the CI) and a malicious request (that is, outside the CI using the certificate key pair as we detailed previously), we performed a procedure to fetch the Entra ID JWT of a system-assigned managed identity assigned to a CI:

生成されたログはどのように表示されますか?セキュリティ インシデント、コンプライアンス、監査、およびその他のさまざまな目的の検出と対応を実行するには、クラウドネイティブ ログが最も重要であることは言うまでもありません。正当なリクエスト (つまり、CI から) と悪意のあるリクエスト (つまり、前に説明した証明書キー ペアを使用した CI の外部) から生成されたログを調べるために、Entra ID JWT を取得する手順を実行しました。 CI に割り当てられたシステム割り当てマネージド ID:

Figure 17. Legitimate procedure to fetch Entra ID token of assigned managed identity

図 17. 割り当てられたマネージド ID の Entra ID トークンを取得する正当な手順

The malicious request would be from anywhere outside the CI. We used the certificate and private key to fetch the JWT, as we detailed previously. We found that the generated sign-in logs from a legitimate attempt and a malicious attempt were almost identical, with differences only in ID, correlation ID, and unique token identifier fields.

悪意のあるリクエストは CI の外部から送信される可能性があります。前に詳しく説明したように、証明書と秘密キーを使用して JWT を取得しました。正当な試行と悪意のある試行によって生成されたサインイン ログは、ID、相関 ID、および一意のトークン識別子のフィールドのみが異なるだけで、ほぼ同一であることがわかりました。

Additionally, one can’t know exactly where the request to fetch the token originated from since the generated logs don’t contain location specific indicators, like an IP address. Sign-in logs for managed identities don’t contain IP addresses — a known area of improvement in the logging aspect of the managed identity service — and this is quite likely because managed identity sign-ins are performed by resources that have their secrets managed by Azure. However, in our case we could use the credentials (certificate and key pair) outside the resource to which the managed identity was assigned.

さらに、生成されたログには IP アドレスなどの場所固有のインジケーターが含まれていないため、トークンを取得するリクエストの発信元を正確に知ることはできません。マネージド ID のサインイン ログには IP アドレスが含まれていません (これは、マネージド ID サービスのログ機能の改善の既知の領域です)。これは、マネージド ID のサインインが、シークレットが管理されているリソースによって実行されるためである可能性が非常に高いです。アズール。ただし、この例では、マネージド ID が割り当てられているリソースの外部で資格情報 (証明書とキーのペア) を使用できました。

To invalidate a certificate and key pair, one would have to delete the CI from the AML workspace. We didn’t find any documentation on how one could rotate the certificate and key pair. This might be because AML service is a managed service, and these credentials are managed by Microsoft. Additionally, the certificate would be valid for two years from the date of creation of the CI.

証明書とキーのペアを無効にするには、AML ワークスペースから CI を削除する必要があります。証明書とキーのペアをローテーションする方法に関するドキュメントは見つかりませんでした。これは、AML サービスがマネージド サービスであり、これらの資格情報が Microsoft によって管理されていることが原因である可能性があります。さらに、証明書は CI の作成日から 2 年間有効です。

Disclosure timeline

We reported this vulnerability arising from differences in the APIs offered by the agents in AML CIs to Microsoft via Trend Micro’s Zero Day Initiative (ZDI). Here's the disclosure timeline for ZDI-23-1056:

開示スケジュール私たちは、AML CI のエージェントによって提供される API の違いに起因するこの脆弱性を、トレンドマイクロのゼロデイ イニシアチブ (ZDI) 経由で Microsoft に報告しました。 ZDI-23-1056 の開示スケジュールは次のとおりです。

• April 7, 2023 – ZDI reported the vulnerability to the vendor.
• April 11, 2023 – The vendor acknowledged the report.
• July 13, 2023 – ZDI asked for an update.
• July 19, 2023 – The vendor asked us to join a call to discuss the report.
• July 19, 2023 – ZDI joined the call and provided the vendor with additional details.
• July 20, 2023 – The vendor stated that it is considering this bug low severity and that it would release a fix in 30 to 45 days.
• July 20, 2023 – ZDI informed the vendor that the case is due on Aug. 5, 2023 and that we are publishing this case as a zero-day advisory on Aug. 9, 2023.

For Black Hat USA 2023, we had planned to share this research with the community. However, before the talk was recorded, we found that this vulnerability was reproducible and not fixed. We reached out to Microsoft, and they deemed the bug to be of a low severity. Later, upon Microsoft's request, we redacted the details of this bug although it was over the 90-day ZDI disclosure policy and was reproducible too.

2023年4月7日 – ZDIはベンダーに脆弱性を報告しました。2023年4月11日 – ベンダーは報告を認めました。2023年7月13日 – ZDIはアップデートを求めました。2023年7月19日 – ベンダーは私たちに、議論するための電話会議に参加するよう求めました。 2023年7月19日 – ZDIは電話会議に参加し、ベンダーに追加の詳細を提供した。2023年7月20日 – ベンダーは、このバグの重大度は低いと考えており、30日から45日以内に修正版をリリースすると述べた。 2023 年 20 日 – ZDI は、この訴訟の期限が 2023 年 8 月 5 日であること、およびこの訴訟を 2023 年 8 月 9 日にゼロデイ勧告として公開することをベンダーに通知しました。Black Hat USA 2023 では、以下の内容を共有する予定でした。この調査はコミュニティと協力して行います。ただし、講演を録音する前に、この脆弱性は再現可能であり、修正されていないことが判明しました。 Microsoft に問い合わせたところ、このバグの重大度は低いと判断されました。その後、Microsoft の要請に応じて、このバグの詳細を編集しましたが、このバグは 90 日間の ZDI 開示ポリシーを超えており、再現可能でもありました。

Microsoft has recently confirmed that the vulnerability has been patched as of January 2024. Currently, the fix doesn’t allow the certificate key pair to be used outside the CI.

Microsoft は最近、この脆弱性が 2024 年 1 月にパッチされたことを確認しました。現時点では、この修正により証明書キー ペアを CI の外部で使用することはできません。

Conclusion

Credential management and its life cycle play a crucial role in cloud security. Safeguarding Storage Accounts in AML workspaces is of critical importance since the ML models, datasets, scripts, and logs, among other entities, are stored in file shares and blob containers. When an AML workspace is created, by default, the Storage Account is publicly accessible using the access key.

結論認証情報管理とそのライフサイクルは、クラウド セキュリティにおいて重要な役割を果たします。 ML モデル、データセット、スクリプト、ログなどのエンティティはファイル共有や BLOB コンテナーに保存されるため、AML ワークスペースでストレージ アカウントを保護することは非常に重要です。 AML ワークスペースが作成されると、既定では、アクセス キーを使用してストレージ アカウントにパブリックにアクセスできるようになります。

A recent example of how critical it is to safeguard Storage Accounts, particularly in AML, lies in the recent mitigation from the Microsoft Security Response Center (MSRC): An overly permissive Shared Access Signature (SAS) token was found to expose 38 terabytes of sensitive information from Microsoft AI research. Additionally, the SAS token allowed for write access to files in the Storage Account (meaning anyone with the URL could modify files on the Storage Account containing ML models). This could have resulted in a classic supply-chain attack on systems dependent on trusted repositories.

特に AML において、ストレージ アカウントを保護することがいかに重要であるかを示す最近の例は、Microsoft セキュリティ レスポンス センター (MSRC) による最近の緩和策にあります。許容度が高すぎる Shared Access Signature (SAS) トークンにより、38 テラバイトの機密データが公開されていることが判明しました。 Microsoft AI 研究からの情報。さらに、SAS トークンにより、ストレージ アカウント内のファイルへの書き込みアクセスが許可されました (つまり、URL を知っている人は誰でも、ML モデルを含むストレージ アカウント上のファイルを変更できるということです)。これにより、信頼できるリポジトリに依存するシステムに対する典型的なサプライチェーン攻撃が発生する可能性がありました。

Based on our analysis of Storage Account naming convention and container names, the Storage Account of Microsoft AI research was likely to be from an AML workspace. When an AML workspace is created, the Storage Account has its name as the workspace name, followed by 10 random digits (Figure 18).

ストレージ アカウントの命名規則とコンテナー名の分析に基づくと、Microsoft AI 調査のストレージ アカウントは AML ワークスペースからのものである可能性があります。 AML ワークスペースが作成されると、ストレージ アカウントの名前はワークスペース名となり、その後に 10 個のランダムな数字が続きます (図 18)。

Figure 18. Storage Account naming convention observed while creating an AML workspace

図 18. AML ワークスペースの作成中に観察されるストレージ アカウントの命名規則

Additionally, the container names beginning with “azureml” in the Storage Account “robustnessws4285631339” are specific to the AML service (Figure 19). When creating an AML workspace, similarly named containers are created by default in a Storage Account.

さらに、ストレージ アカウント「robustnessws4285631339」の「azureml」で始まるコンテナー名は、AML サービスに固有のものです (図 19)。 AML ワークスペースを作成すると、デフォルトで同様の名前のコンテナーがストレージ アカウントに作成されます。

Figure 19. The Azure ML containers mentioned in the Storage Account “robustnessws4285631339”

図 19. ストレージ アカウント「robustnessws4285631339」で言及されている Azure ML コンテナー

Defenders can leverage various frameworks like the Threat Matrix for Storage Services and Azure Threat Research Matrix, which can help in assessing the security posture of their environments. Specifically for ML environments, one can use the MITRE ATLAS framework, a knowledge base of adversary tactics and techniques based on real-world attack observations and realistic demonstrations from AI red teams and security groups. There are specific case studies that shed light on real-world attacks targeting ML environments such as the PyTorch dependency confusion, among others.

防御者は、ストレージ サービスの脅威マトリックスや Azure 脅威リサーチ マトリックスなどのさまざまなフレームワークを活用でき、環境のセキュリティ体制の評価に役立ちます。特に ML 環境の場合、MITRE ATLAS フレームワークを使用できます。MITRE ATLAS フレームワークは、現実世界の攻撃観察と、AI レッド チームやセキュリティ グループによる現実的なデモンストレーションに基づいた、敵対者の戦術とテクニックの知識ベースです。 PyTorch の依存関係の混乱など、ML 環境をターゲットとした実際の攻撃を明らかにする具体的なケーススタディがあります。

Cloud practitioners should also follow an “assume breach” mindset to stay vigilant of unnoticed edge cases, as we detailed when discussing how credentials are sourced in on cloud resources. Following best practices helps reduce the risk of exposure, even when certain lines of defenses are breached. These practices include:

クラウド実務者は、認証情報がクラウド リソースでどのように調達されるかについて説明したときに詳しく説明したように、「侵害を想定する」という考え方に従って、気づかれないエッジ ケースに常に警戒する必要があります。ベスト プラクティスに従うことは、特定の防御線が突破された場合でも、暴露のリスクを軽減するのに役立ちます。これらの実践には次のものが含まれます。

• Securing deployments by using VNets.
• Using minimal custom roles for identities.
• Following defense-in-depth practices.

VNet を使用して展開を保護します。ID に最小限のカスタム ロールを使用します。多層防御の実践に従います。