Azure의 스텔스 지속성: 무단 액세스를 위해 클라우드 프록시 자격 증명 악용

AML(Azure Machine Learning)에서는 취약성으로 인해 작업 영역에서 은밀한 지속성이 허용됩니다. 공격자는 관리 ID를 악용하고 "dsimountagent"와 같은 에이전트를 악용하여 스토리지 계정 액세스 키 및 Entra ID 토큰과 같은 중요한 정보를 얻을 수 있습니다. 이 취약점은 일반적으로 파일이나 코드에 저장되는 자격 증명의 공개 접근성으로 인해 발생하며 손상 시 노출 위험이 증가합니다. 공격자는 이 취약점을 이용하여 정찰을 수행하고 권한을 승격하며 민감한 데이터를 유출할 수 있습니다.

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.

이전 기사에서는 AML(Azure Machine Learning) 서비스에서 생성된 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의 관리 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 리소스를 만들고 관리할 수 있습니다. Azure CLI를 CI 소유자 또는 할당된 관리 ID로 사용하여 로그인하여 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 ID 응답자 데몬의 서비스 구성

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"이라는 두 가지 환경 변수가 포함되어 있습니다.

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 항목이 있음을 확인했습니다. 서비스가 수행할 수 있는 작업에 대한 초기 아이디어를 얻으려면 생성된 로그를 사용할 수 있습니다. “certurl”에 정의된 엔드포인트는 그림 7과 같이 “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.

응답으로 해당 ID의 Entra ID JWT를 얻었습니다(그림 9). 이로 인해 공격자가 CI에서 인증서와 개인 키를 유출하는 공격 시나리오를 작성하면 공격자가 CI에 할당된 ID의 Entra ID JWT를 가져올 수 있는지 궁금해집니다. Azure가 아닌 환경에서 실행되는 공격자가 할당된 ID를 가져올 수도 있습니다. "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, Key Vault, 컨테이너 레지스트리, 애플리케이션 인사이트 및 테넌트 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:

또한 "identityresponderd"와 같은 "dsimountagent" 이외의 여러 에이전트가 있었기 때문에 여기에 나열된 "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 서비스는 할당된 리소스에서만 연결할 수 있습니다. 예를 들어 Azure VM(가상 머신)에 관리 ID를 할당하는 경우 관리 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에 대한 로그인 로그에는 관리 ID 서비스의 로깅 측면에서 알려진 개선 영역인 IP 주소가 포함되어 있지 않습니다. 이는 관리 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:

공개 타임라인우리는 Trend Micro의 ZDI(Zero Day Initiative)를 통해 AML CI의 에이전트가 제공하는 API의 차이로 인해 발생하는 이 취약점을 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일 내에 수정 사항을 출시할 것이라고 밝혔습니다.7월 2023년 8월 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.

결론자격 증명 관리와 그 수명 주기는 클라우드 보안에서 중요한 역할을 합니다. 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(공유 액세스 서명) 토큰이 38TB의 민감한 정보를 노출하는 것으로 밝혀졌습니다. 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 환경의 경우 AI 레드팀과 보안 그룹의 실제 공격 관찰과 현실적인 시연을 기반으로 하는 공격 전술 및 기술에 대한 지식 기반인 MITRE ATLAS 프레임워크를 사용할 수 있습니다. 특히 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에 대해 최소한의 사용자 지정 역할을 사용합니다. 심층 방어 방식을 따릅니다.