Azure 機器學習漏洞讓攻擊者秘密持續存在

本文詳細介紹了 Azure 機器學習 (AML) 中的一個漏洞，該漏洞允許攻擊者在 AML 工作區中實現秘密持久性。具體來說，它表明從 AML 工作區中的計算實例 (CI) 竊取憑證和私密金鑰的攻擊者可以取得 CI 分配的身份的 Entra ID JWT。這可以透過使用受損的憑證和私鑰向公共端點製作 POST 請求並在請求正文中包含「GetAADToken」的「RequestType」來完成。此漏洞是由於 AML CI 中的代理程式提供的 API 存在差異而導致的。

By Nitesh Surana, David Fiser

作者：尼泰什‧蘇拉納 (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 機器學習 (AML) 服務中建立的運算實例 (CI) 上使用的雲端代理程式之一中發現的資訊外洩漏洞。此漏洞可能會讓網路相鄰的攻擊者遠端洩漏來自 CI 的敏感資訊。在本系列關於 AML 中發現的安全問題的第三部分中，我們詳細介紹了攻擊者如何在 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 開發人員在使用雲端服務時面臨的問題之一是存取金鑰、機密、密碼等的憑證管理。將憑證儲存在雲端資源上的程式碼或檔案中會增加發生外洩時的暴露風險。為了避免這個特定問題，Azure 的託管身分功能使用戶能夠避免在程式碼中儲存憑證（圖 1）。需要存取其他資源的使用者和應用程式本質上是取得 Entra ID 令牌以獲得對所需服務的存取權限。

Figure 1. Brief overview of how managed identities work

圖 1. 託管身分認同運作原理的簡要概述

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.

託管識別支援 Azure 中的各種服務，包括 AML。在 AML 中，使用者可以提供運算目標，例如 CI 和計算叢集、系統分配或使用者指派的託管身分。若要存取其他 Azure 服務，可以使用角色將基於角色的存取控制 (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 資源。透過使用 Azure CLI 作為 CI 擁有者或指派的託管識別登錄，可以使用 Azure 服務（基於其 RBAC 權限）。若要以指派的託管身分登錄，可以執行“az login –identity”，如圖 2 所示。

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

圖 2. 使用 Azure CLI 以託管身分登入

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。該服務稱為「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 包含兩個名為「MSI_ENDPOINT」和「MSI_SECRET」的環境變量，它們在圖 5 所示的 GET 請求中使用。

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 憑證和私鑰的組合來與「/mnt/azmnt/.nbvm」中定義為名為「certurl」的環境變數的公共端點進行通信（圖 6）。

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

圖 6.「/mnt/azmnt/.nbvm」的內容以及「certurl」金鑰中定義的公共端點

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.

從服務配置中，我們還看到從二進位檔案中觀察到標準輸出和標準錯誤檔案描述符的系統日誌條目。若要初步了解服務可能執行的操作，可以使用產生的日誌。在執行「az login –identity」時產生的系統日誌條目中也可以觀察到「certurl」中定義的端點，如圖 7 所示。

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

圖 7.「certurl」中定義的公共端點的系統日誌條目

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 分配身分的 Entra ID JWT。也許被指派的身分甚至可以被在非 Azure 環境中執行的攻擊者取得。值得測試這個場景，因為可以從網路成功解析「certurl」環境變數中定義的端點。

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

圖 9. 包含身分的 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 秒（大約兩分鐘）檢查一次安裝狀態。

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”一樣，也有該服務的系統日誌條目。為了在 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 憑證和私鑰。在檢查對公共端點的出站請求時，我們製作了以下 POST 請求，如圖 12 所示。

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 請求中刪除了一些標頭。 、訂閱 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」的環境變數進行解密，這兩個環境變數在負責填入守護程式環境變數的檔案中定義（圖 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.

對於上述兩種情況，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」候選者「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.”

GetAADTokenGetACRTokenGetACRDetailsGetAppInsightsInstrumentationKeyGetAsiUpdateSettingsGenerateSAS我們可以看到，有許多有趣的候選人可供選擇。在下一節中，我們將研究「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.

取得指派的託管身分的 Entra ID 令牌在檢查「GetAADToken」請求類型時，我們製作了 POST 請求正文（圖 14）來取得系統指派的託管身分。

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

圖 14. 用於取得系統指派的託管身分 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 所示。

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

圖 15. 用於取得使用者指派的託管身分 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 的託管身分的 Entra ID JWT。由於我們可以在 CI 外部執行請求並取得託管身分的 JWT，因此這項發現與託管身分的設計方式不太相符，如託管身分文件中所示（圖 16）。

Figure 16. Microsoft documentation of system-assigned managed identities

圖 16. 系統指派的託管識別的 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.

託管身分是一種將憑證保持在程式碼之外的方式。它的工作方式是，需要存取特定資源的應用程式將從託管身分識別服務請求令牌。託管身分識別服務只能從指派給它的資源存取。例如，如果將託管識別碼指派給 Azure 虛擬機器 (VM)，則只能透過連結本地不可路由 IP 位址（如 169.254.169.254）從 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 中名為Azure Functions 的無伺服器產品中發現了類似的問題，其中攻擊者可能會從應用程式容器的環境變數中洩漏證書，並使用它來獲取應用程式容器外部分配的託管身份的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的系統分配的託管識別：

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

圖 17. 取得指派的託管身分的 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 位址），因此無法確切知道取得令牌的請求源自何處。託管身分的登入日誌不包含 IP 位址（託管身分服務的日誌記錄方面的一個已知改進領域），這很可能是因為託管身分登入是由其機密管理的資源執行的天藍色。但是，在我們的範例中，我們可以在分配了託管身分的資源之外使用憑證（憑證和金鑰對）。

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 創建之日起兩年內有效。

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:

揭露時間表我們透過趨勢科技的零日計畫 (ZDI) 向 Microsoft 報告了該漏洞，該漏洞是由於 AML CI 中的代理提供的 API 存在差異而導致的。以下是 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向供應商報告了該漏洞。要求我們加入電話討論報告。在30 至45 天內發布修復程序。 。然而，在錄製演講之前，我們發現該漏洞是可重現的且未修復。我們聯繫了微軟，他們認為該錯誤的嚴重程度較低。後來，根據微軟的要求，我們編輯了這個錯誤的細節，儘管它已經超過了 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.

微軟最近確認該漏洞已於 2024 年 1 月修復。

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.

結論憑證管理及其生命週期在雲端安全中發揮著至關重要的作用。保護 AML 工作區中的儲存帳戶至關重要，因為 ML 模型、資料集、腳本和日誌以及其他實體都儲存在檔案共用和 Blob 容器中。建立 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) 最近的緩解措施中：發現過於寬鬆的共享存取簽章(SAS) 令牌暴露了38 TB 的敏感資料。此外，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 威脅研究矩陣等各種框架，這有助於評估其環境的安全狀況。特別是對於機器學習環境，可以使用 MITRE ATLAS 框架，這是一個基於真實世界攻擊觀察和人工智慧紅隊和安全小組的實際演示的對手戰術和技術的知識庫。有一些具體的案例研究揭示了針對 ML 環境的現實攻擊，例如 PyTorch 依賴混亂等。

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 保護部署。