Die Sicherheitslücke in Azure Machine Learning ermöglicht es Angreifern, im Verborgenen zu bleiben

Dieser Artikel beschreibt eine Schwachstelle in Azure Machine Learning (AML), die es Angreifern ermöglicht, heimlich in einem AML-Arbeitsbereich zu agieren. Konkret zeigt es, dass ein Angreifer, der ein Zertifikat und einen privaten Schlüssel aus einer Recheninstanz (CI) in einem AML-Arbeitsbereich exfiltriert hat, das Entra-ID-JWT der zugewiesenen Identität des CI abrufen kann. Dies kann erreicht werden, indem eine POST-Anfrage an einen öffentlichen Endpunkt erstellt wird, das kompromittierte Zertifikat und der private Schlüssel verwendet werden und ein „RequestType“ von „GetAADToken“ in den Anfragetext eingefügt wird. Diese Sicherheitslücke entsteht durch Unterschiede in den APIs, die von den Agenten in AML-CIs angeboten werden.

By Nitesh Surana, David Fiser

Von 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.

In unserem vorherigen Artikel haben wir eine Sicherheitslücke bezüglich der Offenlegung von Informationen untersucht, die in einem der Cloud-Agenten gefunden wurde, die auf Compute-Instanzen (CIs) verwendet werden, die im Azure Machine Learning (AML)-Dienst erstellt wurden. Diese Sicherheitslücke könnte es Angreifern in der Nähe des Netzwerks ermöglichen, vertrauliche Informationen aus dem CI aus der Ferne preiszugeben. Im dritten Teil dieser Serie über die bei AML festgestellten Sicherheitsprobleme beschreiben wir detailliert, wie ein Angreifer heimlich in einem AML-Arbeitsbereich agieren kann.

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.

Verwenden der Azure-Befehlszeilenschnittstelle von Compute-Instanzen Eines der Probleme, mit denen Entwickler bei der Arbeit mit Cloud-Diensten konfrontiert sind, ist die Anmeldeinformationsverwaltung von Zugriffsschlüsseln, Geheimnissen, Passwörtern und dergleichen. Die Speicherung von Anmeldeinformationen im Code oder in Dateien auf Cloud-Ressourcen erhöht das Risiko einer Offenlegung im Falle einer Kompromittierung. Um dieses spezielle Problem zu umgehen, können Benutzer mit der Azure-Funktion für verwaltete Identitäten das Speichern von Anmeldeinformationen im Code vermeiden (Abbildung 1). Benutzer und Anwendungen, die Zugriff auf andere Ressourcen benötigen, rufen im Wesentlichen Entra-ID-Tokens ab, um Zugriff auf einen gewünschten Dienst zu erhalten.

Figure 1. Brief overview of how managed identities work

Abbildung 1. Kurzer Überblick über die Funktionsweise verwalteter Identitäten

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.

Verwaltete Identitäten unterstützen verschiedene Dienste in Azure, einschließlich AML. In AML können Benutzer Computing-Zielen wie CIs und Computing-Clustern vom System oder vom Benutzer zugewiesene verwaltete Identitäten zuweisen. Um auf andere Azure-Dienste zuzugreifen, können einer erstellten verwalteten Identität mithilfe von Rollen manuell rollenbasierte Zugriffskontrollberechtigungen (RBAC) zugewiesen werden.

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.

Auf CIs kann man die Azure Command-Line Interface (CLI) verwenden, um andere Azure-Ressourcen zu erstellen und zu verwalten. Man kann an Azure-Diensten arbeiten (basierend auf seinen RBAC-Berechtigungen), indem man sich mit der Azure CLI als CI-Besitzer oder der zugewiesenen verwalteten Identität anmeldet. Um sich als zugewiesene verwaltete Identität anzumelden, kann man „az login –identity“ ausführen, wie in Abbildung 2 dargestellt.

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

Abbildung 2. Verwenden der Azure CLI zur Anmeldung als verwaltete Identität

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

Bei der Untersuchung des durch die Ausführung von „az login --identity“ generierten Datenverkehrs sind wir auf die folgende Anfrage gestoßen (Abbildung 3):

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

Abbildung 3. Beim Ausführen von „az login --identity“ generierter Datenverkehr

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).

Wie Abbildung 3 zeigt, wird die Anfrage an Port 46808 auf der lokalen Schnittstelle 127.0.0.1 gesendet. Da wir Zugriff auf das CI haben, haben wir festgestellt, dass ein Prozess namens „identityresponderd“ auf Port 46808 lauscht. Dieser Prozess läuft als Daemon und wird als systemd-Dienst auf allen unter AML erstellten CIs installiert. Der Dienst heißt „AZ Batch AI Identity Responder Daemon“. Bei der Untersuchung des Dienstes ist uns aufgefallen, dass der Dienst seine Umgebungsvariablen aus bestimmten Dateien abruft, wie im Parameter „EnvironmentFile“ definiert (Abbildung 4).

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

Abbildung 4. Dienstkonfiguration des Azure Batch AI Identity Responder Daemon

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.

Die Datei /etc/environment.sso enthält zwei Umgebungsvariablen mit den Namen „MSI_ENDPOINT“ und „MSI_SECRET“, die in der in Abbildung 5 gezeigten GET-Anfrage verwendet werden.

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

Abbildung 5. „MSI_ENDPOINT“ und „MSI_SECRET“ definiert in „/etc/environment.sso“

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).

Wir fragen jedoch immer noch einen lokalen Endpunkt ab. Bei der Untersuchung der ausgehenden Kommunikation der Binärdatei haben wir festgestellt, dass die Binärdatei eine Kombination aus einem x509-Zertifikat und einem privaten Schlüssel verwendet, um mit einem öffentlichen Endpunkt zu kommunizieren, der in „/mnt/azmnt/.nbvm“ als Umgebungsvariable mit dem Namen „certurl“ definiert ist ( Abbildung 6).

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

Abbildung 6. Inhalt von „/mnt/azmnt/.nbvm“ mit im Schlüssel „certurl“ definiertem öffentlichen Endpunkt

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.

Aus der Dienstkonfiguration haben wir auch gesehen, dass Syslog-Einträge für Standardausgabe- und Standardfehlerdateideskriptoren aus der Binärdatei beobachtet wurden. Um eine erste Vorstellung davon zu bekommen, was ein Dienst möglicherweise tut, kann man die generierten Protokolle verwenden. Der in „certurl“ definierte Endpunkt wird auch in den Syslog-Einträgen beobachtet, die generiert werden, wenn „az login –identity“ ausgeführt wird, wie in Abbildung 7 dargestellt.

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

Abbildung 7. Syslog-Einträge mit dem in „certurl“ definierten öffentlichen Endpunkt

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

Mit diesen Informationen haben wir die endgültige Anfrage erstellt, die an den öffentlichen Endpunkt gesendet wird (Abbildung 8):

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

Abbildung 8. POST-Anfrage zum Abrufen des Entra-ID-JWT mit „identityresponderd“

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.

Als Antwort erhielten wir das Entra-ID-JWT der Identität (Abbildung 9). Dies führt uns zu der Frage, ob die Erstellung eines Angriffsszenarios, bei dem ein Angreifer das Zertifikat und den privaten Schlüssel von einem CI exfiltriert hat, es dem Angreifer ermöglicht, das Entra-ID-JWT der dem CI zugewiesenen Identität abzurufen. Möglicherweise könnte die zugewiesene Identität sogar von einem Angreifer abgerufen werden, der in einer Nicht-Azure-Umgebung ausgeführt wird. Es hat sich gelohnt, dieses Szenario zu testen, da der in der Umgebungsvariablen „certurl“ definierte Endpunkt erfolgreich aus dem Internet aufgelöst werden konnte.

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

Abbildung 9. Antwort mit dem Entra-ID-JWT der Identität

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.

Als wir jedoch versuchten, das Szenario der Verwendung des Zertifikats und des privaten Schlüssels vom CI zum Abrufen des Entra-ID-JWT nachzubilden, erhielten wir eine nicht autorisierte 401-Antwort. Unser Denkprozess und unsere Annahme waren daher, dass die Verwendung des Zertifikats und des Schlüssels innerhalb der Grenzen des CI eingeschränkt ist. Darüber hinaus verfügte das x509-Zertifikat für jedes CI über einen eindeutigen Fingerabdruck.

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

Wir untersuchen nun, warum unser Befund nur eine Annahme war, als wir den „Dsimountagent“-Agenten untersuchten.

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).

Ein genauerer Blick auf „dsimountagent“ Bei der Untersuchung der Funktionalität von „dsimountagent“ stellten wir fest, dass der Agent sicherstellt, dass die Dateifreigabe des Speicherkontos des AML-Arbeitsbereichs auf dem CI bereitgestellt wird. Wie in Abbildung 10 dargestellt, prüft es alle 120 Sekunden (etwa zwei Minuten) den Bereitstellungsstatus.

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

Abbildung 10. Hauptzweck von „dsimountagent“ auf einer Recheninstanz

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.

Wie wir in der systemd-Dienstkonfiguration des Daemons sehen können (Abbildung 11), holt sich der Agent seine Konfiguration als Umgebungsvariablen aus einer Datei und wie „identityresponderd“ gibt es auch für diesen Dienst Syslog-Einträge. Um die Dateifreigabe auf dem CI bereitzustellen, ruft der Dienst den Zugriffsschlüssel des Speicherkontos des AML-Arbeitsbereichs von einem öffentlichen Endpunkt ab, der in einer Umgebungsvariablen namens „AZ_BATCHAI_XDS_ENDPOINT“ definiert ist. Dieses Schlüssel-Wert-Paar wird in einer Datei mit dem Namen „dsimountagentenv“ im Verzeichnis „/mnt/batch/tasks/startup/wd/dsi/“ gespeichert. Bemerkenswerterweise wurde bereits im ersten Eintrag dieser Serie festgestellt, dass diese Datei den Zugriffsschlüssel des Speicherkontos im Klartext enthielt.

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

Abbildung 11. Dienstkonfiguration des Azure Batch AI DSI-Montage-Agents

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.

Für die Kommunikation mit dem öffentlichen Endpunkt verwendet „dsimountagent“ dasselbe Paar aus x509-Zertifikat und privatem Schlüssel wie „identityresponderd“. Bei der Untersuchung ausgehender Anfragen an den öffentlichen Endpunkt haben wir die folgende POST-Anfrage erstellt, die in Abbildung 12 dargestellt ist.

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

Abbildung 12. POST-Anfrage zum Abrufen von Arbeitsbereichsinformationen mit „dsimountagent“

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.

Zur besseren Lesbarkeit wurden in Abbildung 12 einige Header aus der POST-Anfrage entfernt. Die Antwort auf diese POST-Anfrage enthielt die Ressourcen-IDs für das Speicherkonto, den Schlüsseltresor, die Containerregistrierung, Anwendungseinblicke und Metadaten über den Arbeitsbereich, wie etwa die Mandanten-ID, Abonnement-ID und ob das CI-VNet unter anderem öffentlich erreichbar ist. Man kann sich dies als das „Whoami“ des AML-Arbeitsbereichs vorstellen.

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).

Mit demselben Anfrage-URI und Endpunkt stießen wir auf eine weitere Anfrage, bei der der „RequestType“-Schlüssel im Hauptteil der POST-Anfrage auf „getworkspacesecrets“ gesetzt war. Die Antwort enthielt den Namen des Speicherkontos und eine verschlüsselte JWE des Zugriffsschlüssels des Speicherkontos. Das verschlüsselte JWE wird mithilfe von zwei weiteren Umgebungsvariablen namens „AZ_LS_ENCRYPTED_SYMMETRIC_KEY“ und „AZ_BATCHAI_CLUSTER_PRIVATE_KEY_PEM“ entschlüsselt, die in der Datei definiert sind, die für das Auffüllen von Umgebungsvariablen für den Daemon verantwortlich ist (Abbildung 13).

Figure 13. Decryption routine for Storage Account JWE

Abbildung 13. Entschlüsselungsroutine für Speicherkonto 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.

Da diese Anfrage auch von außerhalb des CI unter Verwendung des kompromittierten Zertifikats und des privaten Schlüssels durchgeführt wurde, könnte ein Angreifer nach der Kompromittierung den Zugriffsschlüssel des Speicherkontos von außerhalb der Grenzen des CI abrufen.

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:

Falls der Zugriffsschlüssel eines Speicherkontos verloren geht oder kompromittiert wird, können Benutzer den kompromittierten Schlüssel durch Rotation des Schlüssels ungültig machen. Wir haben jedoch festgestellt, dass das Zertifikat-Schlüssel-Paar zum Abrufen des Speicherkonto-Zugriffsschlüssels verwendet werden kann, selbst nachdem die Zugriffsschlüssel rotiert wurden, wie wir in diesem Video sehen:

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.

Für die beiden oben genannten Fälle ist der Textkörper der POST-Anfrage besonders interessant. Könnte es möglicherweise noch mehr Kandidaten für den Schlüssel „RequestType“ geben? Da wir über die Binärdatei „dsimountagent“ (und einige weitere solcher Agenten wie „identityresponderd“) verfügten, untersuchten wir, was mit der Kombination aus Zertifikat und privatem Schlüssel sonst noch abgerufen werden konnte.

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.

Weitere „RequestType“-Kandidaten finden Die Binärdatei „dsimountagent“ enthält Debug-Symbole, wie wir im zweiten Teil dieser Serie festgestellt haben. Die Funktionen, die den auf „getworkspace“ und „getworkspacesecrets“ gesetzten „RequestType“-Werten entsprechen, wurden in einem Paket namens „hosttools“ definiert. Diese Funktionen würden wiederum eine andere Funktion namens „generateXDSApiRequestSchema“ aufrufen. Diese Funktion ist für die Erstellung des Hauptteils der POST-Anfrage verantwortlich.

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:

Da wir außerdem mehrere Agenten außer „dsimountagent“ hatten, wie zum Beispiel „identityresponderd“, haben wir beim Aufzählen der Querverweise von Funktionen, die „generateXDSApiRequestSchema“ aufrufen, einige Kandidaten gefunden, die wir hier auflisten:

• 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.”

GetAADTokenGetACRTokenGetACRDetailsGetAppInsightsInstrumentationKeyGetDsiUpdateSettingsGenerateSASAWie wir sehen können, gab es einige interessante Kandidaten, für die man sich entscheiden konnte. Im folgenden Abschnitt untersuchen wir „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.

Abrufen des Entra-ID-Tokens einer zugewiesenen verwalteten Identität. Bei der Untersuchung des Anforderungstyps „GetAADToken“ haben wir den POST-Anforderungstext (Abbildung 14) erstellt, um eine vom System zugewiesene verwaltete Identität abzurufen.

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

Abbildung 14. POST-Anfragetext zum Abrufen eines vom System zugewiesenen Entra-ID-Tokens mit verwalteter Identität

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

Wenn es eine vom Benutzer zugewiesene verwaltete Identität gäbe, müssten wir die Client-ID einschließen, wie in Abbildung 15 dargestellt.

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

Abbildung 15. POST-Anfragetext zum Abrufen eines vom Benutzer zugewiesenen verwalteten Identitäts-Entra-ID-Tokens

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).

Die Antwort würde das Entra-ID-JWT der verwalteten Identität enthalten, die dem CI zugewiesen ist. Da wir die Anfrage außerhalb des CI ausführen und JWTs verwalteter Identitäten abrufen könnten, stimmt diese Feststellung nicht ganz mit der Art und Weise überein, wie verwaltete Identitäten entworfen wurden, wie in der Dokumentation für verwaltete Identitäten zu sehen ist (Abbildung 16).

Figure 16. Microsoft documentation of system-assigned managed identities

Abbildung 16. Microsoft-Dokumentation systemseitig zugewiesener verwalteter Identitäten

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.

Verwaltete Identitäten sind eine Möglichkeit, Anmeldeinformationen außerhalb des Codes zu halten. Es funktioniert so, dass eine Anwendung, die Zugriff auf eine bestimmte Ressource benötigt, ein Token von einem verwalteten Identitätsdienst anfordert. Der verwaltete Identitätsdienst ist nur von der Ressource aus erreichbar, der er zugewiesen wurde. Wenn Sie beispielsweise einer Azure-VM eine verwaltete Identität zuweisen, kann der verwaltete Identitätsdienst nur von der Azure-VM aus über eine verbindungslokale, nicht weiterleitbare IP-Adresse wie 169.254.169.254 erreicht werden.

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.

Zuvor haben wir ein ähnliches Problem bei einem serverlosen Angebot in Azure namens Azure Functions festgestellt, bei dem ein Angreifer das Zertifikat aus Umgebungsvariablen des Anwendungscontainers verlieren und es verwenden konnte, um das Entra-ID-JWT der zugewiesenen verwalteten Identität außerhalb des Anwendungscontainers abzurufen .

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:

Wie sehen die generierten Protokolle aus? Es versteht sich von selbst, dass Cloud-native Protokolle für die Erkennung und Reaktion bei Sicherheitsvorfällen, Compliance, Audits und verschiedenen anderen Zwecken von größter Bedeutung sind. Um die Protokolle zu untersuchen, die aus einer legitimen Anfrage (d. h. vom CI) und einer böswilligen Anfrage (d. h. außerhalb des CI unter Verwendung des Zertifikatschlüsselpaars, wie wir zuvor beschrieben haben) generiert wurden, haben wir ein Verfahren zum Abrufen des Entra-ID-JWT von durchgeführt eine vom System zugewiesene verwaltete Identität, die einem CI zugewiesen ist:

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

Abbildung 17. Legitimes Verfahren zum Abrufen des Entra-ID-Tokens der zugewiesenen verwalteten Identität

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.

Die böswillige Anfrage würde von irgendwo außerhalb des CI kommen. Wir haben das Zertifikat und den privaten Schlüssel verwendet, um das JWT abzurufen, wie wir zuvor beschrieben haben. Wir haben festgestellt, dass die generierten Anmeldeprotokolle eines legitimen Versuchs und eines böswilligen Versuchs nahezu identisch waren und sich nur in den Feldern ID, Korrelations-ID und eindeutige Token-ID unterschieden.

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.

Darüber hinaus kann man nicht genau wissen, woher die Anfrage zum Abrufen des Tokens stammt, da die generierten Protokolle keine standortspezifischen Indikatoren wie eine IP-Adresse enthalten. Anmeldeprotokolle für verwaltete Identitäten enthalten keine IP-Adressen – ein bekanntermaßen verbesserter Bereich im Protokollierungsaspekt des verwalteten Identitätsdiensts – und das ist sehr wahrscheinlich, weil Anmeldungen mit verwalteten Identitäten von Ressourcen durchgeführt werden, deren Geheimnisse verwaltet werden Azurblau. In unserem Fall könnten wir jedoch die Anmeldeinformationen (Zertifikat und Schlüsselpaar) außerhalb der Ressource verwenden, der die verwaltete Identität zugewiesen wurde.

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.

Um ein Zertifikat- und Schlüsselpaar ungültig zu machen, müsste man das CI aus dem AML-Arbeitsbereich löschen. Wir haben keine Dokumentation darüber gefunden, wie man das Zertifikat- und Schlüsselpaar rotieren kann. Dies kann daran liegen, dass der AML-Dienst ein verwalteter Dienst ist und diese Anmeldeinformationen von Microsoft verwaltet werden. Darüber hinaus wäre das Zertifikat ab dem Erstellungsdatum des CI zwei Jahre lang gültig.

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:

Zeitplan für die Offenlegung: Wir haben Microsoft über die Zero Day Initiative (ZDI) von Trend Micro diese Sicherheitslücke gemeldet, die auf Unterschiede in den APIs zurückzuführen ist, die von den Agenten in AML-CIs angeboten werden. Hier ist der Zeitplan für die Offenlegung von 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.

7. April 2023 – ZDI hat die Schwachstelle dem Anbieter gemeldet. 11. April 2023 – Der Anbieter hat die Meldung bestätigt. 13. Juli 2023 – ZDI hat um ein Update gebeten. 19. Juli 2023 – Der Anbieter hat uns gebeten, an einem Gespräch teilzunehmen, um darüber zu diskutieren der Bericht.19. Juli 2023 – ZDI beteiligte sich an der Aufforderung und übermittelte dem Anbieter zusätzliche Details.20. Juli 2023 – Der Anbieter gab an, dass er diesen Fehler als gering einschätzt und in 30 bis 45 Tagen einen Fix veröffentlichen werde.Juli 20. August 2023 – ZDI hat den Anbieter darüber informiert, dass der Fall am 5. August 2023 fällig ist und dass wir diesen Fall am 9. August 2023 als Zero-Day-Advisory veröffentlichen. Für Black Hat USA 2023 hatten wir geplant, ihn zu teilen diese Forschung mit der Community. Bevor der Vortrag aufgezeichnet wurde, stellten wir jedoch fest, dass diese Sicherheitslücke reproduzierbar und nicht behoben war. Wir haben uns an Microsoft gewandt und sie haben festgestellt, dass der Fehler von geringer Schwere ist. Später haben wir auf Anfrage von Microsoft die Details dieses Fehlers redigiert, obwohl er über die 90-Tage-ZDI-Offenlegungsrichtlinie hinausging und auch reproduzierbar war.

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 hat kürzlich bestätigt, dass die Schwachstelle ab Januar 2024 behoben wurde. Derzeit erlaubt der Fix nicht, das Zertifikatschlüsselpaar außerhalb des CI zu verwenden.

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.

Fazit: Das Anmeldedatenmanagement und sein Lebenszyklus spielen eine entscheidende Rolle für die Cloud-Sicherheit. Der Schutz von Speicherkonten in AML-Arbeitsbereichen ist von entscheidender Bedeutung, da die ML-Modelle, Datensätze, Skripts und Protokolle sowie andere Entitäten in Dateifreigaben und Blob-Containern gespeichert werden. Wenn ein AML-Arbeitsbereich erstellt wird, ist das Speicherkonto standardmäßig über den Zugriffsschlüssel öffentlich zugänglich.

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.

Ein aktuelles Beispiel dafür, wie wichtig der Schutz von Speicherkonten, insbesondere bei der Bekämpfung von Geldwäsche, ist, ist die jüngste Abhilfemaßnahme des Microsoft Security Response Center (MSRC): Es wurde festgestellt, dass ein übermäßig freizügiges Shared Access Signature (SAS)-Token 38 Terabyte an sensiblen Daten offenlegt Informationen aus der KI-Forschung von Microsoft. Darüber hinaus ermöglichte das SAS-Token den Schreibzugriff auf Dateien im Speicherkonto (was bedeutet, dass jeder mit der URL Dateien im Speicherkonto ändern konnte, die ML-Modelle enthalten). Dies hätte zu einem klassischen Supply-Chain-Angriff auf Systeme führen können, die von vertrauenswürdigen Repositorys abhängig sind.

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).

Basierend auf unserer Analyse der Namenskonvention für Speicherkonten und Containernamen stammte das Speicherkonto der Microsoft AI-Forschung wahrscheinlich aus einem AML-Arbeitsbereich. Wenn ein AML-Arbeitsbereich erstellt wird, erhält das Speicherkonto seinen Namen als Arbeitsbereichsnamen, gefolgt von 10 zufälligen Ziffern (Abbildung 18).

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

Abbildung 18. Beim Erstellen eines AML-Arbeitsbereichs beobachtete Benennungskonvention für Speicherkonten

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.

Darüber hinaus sind die Containernamen, die mit „azureml“ beginnen, im Speicherkonto „robustnessws4285631339“ spezifisch für den AML-Dienst (Abbildung 19). Beim Erstellen eines AML-Arbeitsbereichs werden standardmäßig ähnlich benannte Container in einem Speicherkonto erstellt.

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

Abbildung 19. Die im Speicherkonto „robustnessws4285631339“ erwähnten Azure ML-Container

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.

Verteidiger können verschiedene Frameworks wie die Threat Matrix for Storage Services und die Azure Threat Research Matrix nutzen, die bei der Bewertung der Sicherheitslage ihrer Umgebungen hilfreich sein können. Speziell für ML-Umgebungen kann man das MITRE ATLAS-Framework verwenden, eine Wissensdatenbank über gegnerische Taktiken und Techniken, die auf realen Angriffsbeobachtungen und realistischen Demonstrationen von KI-Red-Teams und Sicherheitsgruppen basiert. Es gibt spezifische Fallstudien, die Aufschluss über reale Angriffe geben, die auf ML-Umgebungen abzielen, wie unter anderem die PyTorch-Abhängigkeitsverwirrung.

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:

Cloud-Anwender sollten außerdem die Einstellung „Verletzung annehmen“ verfolgen, um auf unbemerkte Grenzfälle aufmerksam zu bleiben, wie wir ausführlich dargelegt haben, als wir besprochen haben, wie Anmeldeinformationen in Cloud-Ressourcen einfließen. Die Einhaltung bewährter Verfahren trägt dazu bei, das Risiko einer Offenlegung zu verringern, selbst wenn bestimmte Verteidigungslinien durchbrochen werden. Zu diesen Praktiken gehören:

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

Sichern von Bereitstellungen mithilfe von VNets. Verwenden minimaler benutzerdefinierter Rollen für Identitäten. Befolgen von Defense-in-Depth-Praktiken.