Azure 机器学习服务中的隐秘持久性

在 Azure 机器学习 (AML) 中，信息泄露漏洞允许攻击者从计算实例 (CI) 获取敏感数据。 “dsimountagent”代理中的缺陷暴露了存储帐户访问密钥。此密钥用于轮换密钥、获取工作区机密以及收集托管标识的 Azure Active Directory (AAD) 令牌。即使在密钥轮换之后，证书和私钥对也可以检索存储帐户访问密钥。合法请求和恶意请求生成的日志类似，缺乏IP地址等具体指标。尽管向 Microsoft 报告了该漏洞，但该漏洞被认为严重程度较低，并且修复花了超过 45 天的时间才实施。这凸显了保护 AML 工作区中存储帐户的重要性，因为易受攻击的凭据可能会导致严重的安全风险。

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。该进程作为守护进程运行，并作为 systemd 服务安装在 AML 下创建的所有 CI 中。该服务称为“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 请求中删除了一些标头。此 POST 请求的响应包含存储帐户、密钥保管库、容器注册表、应用程序见解以及有关工作区的元数据（例如租户 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”的环境变量进行解密，这两个环境变量在负责填充守护程序环境变量的文件中定义（图 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向供应商报告了该漏洞。2023年4月11日 – 供应商承认了该报告。2023年7月13日 – ZDI要求更新。2023年7月19日 – 供应商要求我们加入电话讨论报告。2023 年 7 月 19 日 – ZDI 加入通话并向供应商提供了更多详细信息。2023 年 7 月 20 日 – 供应商表示正在考虑此错误的严重程度较低，并将在 30 至 45 天内发布修复程序。 2023 年 2 月 20 日 – ZDI 通知供应商该案例的截止日期为 2023 年 8 月 5 日，我们将于 2023 年 8 月 9 日将此案例作为零日公告发布。对于 Black Hat USA 2023，我们原计划分享与社区进行这项研究。然而，在录制演讲之前，我们发现该漏洞是可重现的且未修复。我们联系了微软，他们认为该错误的严重程度较低。后来，根据微软的要求，我们编辑了这个错误的细节，尽管它已经超过了 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 月修复。目前，该修复不允许在 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.

结论凭证管理及其生命周期在云安全中发挥着至关重要的作用。保护 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 保护部署。对身份使用最少的自定义角色。遵循深度防御实践。