Persistance furtive dans le service Azure Machine Learning

RésuméCe rapport détaille comment un attaquant peut obtenir une persistance furtive dans un espace de travail Azure Machine Learning (AML) en exploitant les vulnérabilités des agents « Identityresponderd » et « dsimountagent ». Ces agents utilisent des certificats X.509 et des clés privées pour communiquer avec un point de terminaison public, permettant ainsi aux attaquants de récupérer des informations sensibles en dehors des limites du CI, y compris le jeton Entra ID d'une identité gérée attribuée. La vulnérabilité provient du fait que le certificat et la paire de clés peuvent être utilisés pour récupérer la clé d'accès au compte de stockage même après la rotation des clés, ce qui entraîne une exposition potentielle des données et une compromission des modèles ML.

By Nitesh Surana, David Fiser

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

Dans notre article précédent, nous avons examiné une vulnérabilité de divulgation d’informations trouvée dans l’un des agents cloud utilisés sur les instances de calcul (CI) créées dans le service Azure Machine Learning (AML). Cette vulnérabilité pourrait permettre aux attaquants adjacents au réseau de divulguer à distance des informations sensibles du CI. Dans le troisième volet de cette série sur les problèmes de sécurité rencontrés dans AML, nous détaillons comment un attaquant pourrait parvenir à une persistance furtive dans un espace de travail 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.

Utilisation d'Azure CLI à partir d'instances de calculL'un des problèmes auxquels les développeurs sont confrontés lorsqu'ils travaillent avec des services cloud est la gestion des informations d'identification des clés d'accès, des secrets, des mots de passe, etc. Les informations d'identification stockées dans du code ou dans des fichiers sur des ressources cloud augmentent le risque d'exposition en cas de compromission. Pour contourner ce problème particulier, la fonctionnalité d’identités gérées d’Azure permet aux utilisateurs d’éviter de stocker les informations d’identification dans le code (Figure 1). Les utilisateurs et les applications nécessitant un accès à d'autres ressources récupèrent essentiellement des jetons Entra ID pour accéder à un service souhaité.

Figure 1. Brief overview of how managed identities work

Figure 1. Bref aperçu du fonctionnement des identités managées

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.

Les identités managées prennent en charge divers services dans Azure, notamment AML. Dans AML, les utilisateurs peuvent attribuer à des cibles de calcul, telles que des CI et des clusters de calcul, des identités managées attribuées par le système ou par l'utilisateur. Pour accéder à d'autres services Azure, les autorisations de contrôle d'accès basé sur les rôles (RBAC) peuvent être attribuées manuellement à une identité managée créée à l'aide de rôles.

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.

Sur les CI, on peut utiliser l'interface de ligne de commande (CLI) Azure pour créer et gérer d'autres ressources Azure. On peut travailler sur les services Azure (en fonction de leurs autorisations RBAC) en se connectant à l'aide d'Azure CLI en tant que propriétaire du CI ou de l'identité managée attribuée. Pour vous connecter en tant qu'identité managée attribuée, vous pouvez exécuter « az login –identity », comme le montre la figure 2.

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

Figure 2. Utilisation d'Azure CLI pour vous connecter en tant qu'identité managée

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

Lors de l'inspection du trafic généré lors de l'exécution de « az login --identity », nous sommes tombés sur la requête suivante (Figure 3) :

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

Figure 3. Trafic généré lors de l'exécution de « 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).

Comme le montre la figure 3, la requête est envoyée au port 46808 sur l'interface locale 127.0.0.1. Depuis que nous avons accès au CI, nous avons constaté qu'un processus nommé « identityresponderd » écoute sur le port 46808. Ce processus s'exécute comme un démon et est installé en tant que service systemd sur tous les CI créés sous AML. Le service s’appelle « AZ Batch AI Identity Responder Daemon ». En examinant le service, nous avons remarqué que le service récupère ses variables d'environnement à partir de certains fichiers tels que définis dans le paramètre « EnvironmentFile » (Figure 4).

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

Figure 4. Configuration du service du démon 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.

Le fichier /etc/environment.sso contient deux variables d'environnement nommées « MSI_ENDPOINT » et « MSI_SECRET » qui sont utilisées dans la requête GET illustrée dans la figure 5.

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

Figure 5. « MSI_ENDPOINT » et « MSI_SECRET » définis dans « /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).

Cependant, nous interrogeons toujours un point de terminaison local. En examinant la communication sortante du binaire, nous avons constaté que le binaire utilise une combinaison d'un certificat x509 et d'une clé privée pour communiquer avec un point de terminaison public défini dans « /mnt/azmnt/.nbvm » en tant que variable d'environnement nommée « certurl » ( Figure 6).

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

Figure 6. Contenu de « /mnt/azmnt/.nbvm » avec le point de terminaison public défini dans la clé « 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.

À partir de la configuration du service, nous avons également constaté qu'il existe des entrées syslog observées pour les descripteurs de sortie standard et de fichier d'erreur standard du binaire. Pour avoir une première idée de ce que fait éventuellement un service, on peut utiliser les journaux générés. Le point de terminaison défini dans « certurl » est également observé dans les entrées syslog générées lorsque « az login –identity » est exécuté, comme le montre la figure 7.

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

Figure 7. Entrées Syslog avec le point de terminaison public défini dans « certurl »

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

Avec ces informations, nous avons élaboré la requête finale qui est envoyée au point de terminaison public (Figure 8) :

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

Figure 8. Requête POST pour récupérer Entra ID JWT à l'aide de « 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.

Dans la réponse, nous avons obtenu l'Entra ID JWT de l'identité (Figure 9). Cela nous amène à nous demander si l'élaboration d'un scénario d'attaque dans lequel un attaquant a exfiltré le certificat et la clé privée d'un CI permet à l'attaquant de récupérer l'Entra ID JWT de l'identité attribuée au CI. Peut-être que l’identité attribuée pourrait même être récupérée par un attaquant s’exécutant dans un environnement non-Azure. Cela valait la peine de tester ce scénario puisque le point de terminaison défini dans la variable d'environnement « certurl » pouvait être résolu avec succès depuis Internet.

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

Figure 9. Réponse contenant l'Entra ID JWT de l'identité

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.

Cependant, en essayant de recréer le scénario d'utilisation du certificat et de la clé privée du CI pour récupérer l'Entra ID JWT, nous avons obtenu une réponse 401 non autorisée. Par conséquent, notre processus de réflexion et notre hypothèse étaient que le certificat et la clé sont limités à une utilisation dans les limites du CI. De plus, le certificat x509 de chaque CI avait une empreinte numérique unique.

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

Nous explorons maintenant pourquoi notre découverte n'était qu'une hypothèse alors que nous sondions l'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).

Un examen plus approfondi de « dsimountagent » En examinant la fonctionnalité de « dsimountagent », nous avons observé que l'agent s'assure que le partage de fichiers du compte de stockage de l'espace de travail AML est monté sur le CI. Comme le montre la figure 10, il vérifie l'état du montage toutes les 120 secondes (environ deux minutes).

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

Figure 10. Objectif principal de « dsimountagent » sur une instance de calcul

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.

Comme nous pouvons l'observer dans la configuration du service systemd du démon (Figure 11), l'agent récupère sa configuration en tant que variables d'environnement à partir d'un fichier et, comme « identityresponderd », il existe également des entrées syslog pour ce service. Pour monter le partage de fichiers sur le CI, le service récupère la clé d'accès du compte de stockage de l'espace de travail AML à partir d'un point de terminaison public défini dans une variable d'environnement nommée « AZ_BATCHAI_XDS_ENDPOINT ». Cette paire clé-valeur est stockée dans un fichier nommé « dsimountagentenv » sous le répertoire « /mnt/batch/tasks/startup/wd/dsi/ ». Notamment, dans la première entrée de cette série, il avait déjà été observé que ce fichier contenait la clé d’accès du compte de stockage en texte clair.

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

Figure 11. Configuration du service de l'agent de montage DSI Azure Batch AI

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.

Pour communiquer avec le point de terminaison public, « dsimountagent » utilise la même paire de certificat x509 et de clé privée utilisée par « identityresponderd ». Lors de l'examen des requêtes sortantes vers le point de terminaison public, nous avons créé la requête POST suivante illustrée dans la figure 12.

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

Figure 12. Requête POST pour récupérer les informations de l'espace de travail à l'aide de « 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.

Pour plus de lisibilité, quelques en-têtes sont supprimés de la requête POST dans la figure 12. La réponse à cette requête POST contenait les ID de ressource pour le compte de stockage, le coffre de clés, le registre de conteneurs, les informations sur les applications et les métadonnées sur l'espace de travail telles que l'ID de locataire, ID d'abonnement et si le CI VNet est accessible au public, entre autres. Il est possible de considérer cela comme le « whoami » de l’espace de travail AML.

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

Avec le même URI de requête et le même point de terminaison, nous sommes tombés sur une autre requête dans laquelle la clé « RequestType » dans le corps de la requête POST était définie sur « getworkspacesecrets ». La réponse contenait le nom du compte de stockage et un JWE chiffré de la clé d’accès du compte de stockage. Le JWE chiffré est déchiffré à l'aide de deux autres variables d'environnement nommées « AZ_LS_ENCRYPTED_SYMMETRIC_KEY » et « AZ_BATCHAI_CLUSTER_PRIVATE_KEY_PEM », définies dans le fichier responsable du remplissage des variables d'environnement pour le démon (Figure 13).

Figure 13. Decryption routine for Storage Account JWE

Figure 13. Routine de déchiffrement pour le compte de stockage 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.

Étant donné que cette requête était également effectuée depuis l’extérieur du CI à l’aide du certificat et de la clé privée compromis, un attaquant post-compromis pourrait récupérer la clé d’accès du compte de stockage depuis l’extérieur des limites du 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:

En cas de fuite ou de compromission de la clé d'accès d'un compte de stockage, les utilisateurs peuvent invalider la clé compromise en la faisant tourner. Cependant, nous avons constaté que le certificat et la paire de clés pouvaient être utilisés pour récupérer la clé d'accès au compte de stockage, même après la rotation des clés d'accès, comme nous le voyons dans cette vidéo :

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.

Pour les deux cas précités, le corps de la requête POST est particulièrement intéressant. Pourrait-il y avoir plus de candidats pour la clé « RequestType » ? Puisque nous avions le binaire « dsimountagent » (et quelques autres agents comme « identityresponderd »), nous avons étudié ce qui pouvait être récupéré en utilisant la combinaison de certificat et de clé privée.

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.

Trouver plus de candidats « RequestType » Le binaire « dsimountagent » est livré avec des symboles de débogage, comme nous l'avons noté dans le deuxième volet de cette série. Les fonctions correspondant aux valeurs « RequestType » définies sur « getworkspace » et « getworkspacesecrets » ont été définies dans un package appelé « hosttools ». Ces fonctions appelleraient à leur tour une autre fonction nommée « generateXDSApiRequestSchema ». Cette fonction est responsable de la création du corps de la requête 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:

De plus, comme nous avions plusieurs agents autres que « dsimountagent », tels que « identityresponderd », nous avons trouvé certains candidats en énumérant les références croisées des fonctions appelant « generateXDSApiRequestSchema », que nous répertorions ici :

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

GetAADTokenGetACRTokenGetACRDetailsGetAppInsightsInstrumentationKeyGetDsiUpdateSettingsGenerateSASAComme nous pouvons le voir, il y avait un certain nombre de candidats intéressants à sélectionner. Dans la section suivante, nous examinons « 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.

Récupération du jeton Entra ID d'une identité gérée attribuéeEn examinant le type de requête « GetAADToken », nous avons conçu le corps de la requête POST (Figure 14) pour récupérer une identité gérée attribuée par le système.

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

Figure 14. Corps de la requête POST pour récupérer un jeton Entra ID d'identité gérée attribué par le système

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

S'il existait une identité gérée attribuée par l'utilisateur, nous devions inclure l'ID client, comme le montre la figure 15.

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

Figure 15. Corps de la requête POST pour récupérer un jeton Entra ID d'identité gérée attribué par l'utilisateur

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

La réponse contiendrait l’Entra ID JWT de l’identité gérée attribuée au CI. Étant donné que nous pourrions effectuer la requête en dehors du CI et récupérer les JWT des identités gérées, ce résultat ne correspond pas tout à fait à la façon dont les identités gérées ont été conçues, comme le montre la documentation sur les identités gérées (Figure 16).

Figure 16. Microsoft documentation of system-assigned managed identities

Figure 16. Documentation Microsoft sur les identités managées attribuées par le système

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.

Les identités gérées sont un moyen de conserver les informations d'identification hors code. Cela fonctionne de telle manière qu'une application ayant besoin d'accéder à une certaine ressource demandera un jeton à un service d'identité géré. Le service d'identité géré n'est accessible qu'à partir de la ressource à laquelle il a été attribué. Par exemple, si vous attribuez une identité managée à une machine virtuelle (VM) Azure, le service d’identité managée n’est accessible qu’à partir de la machine virtuelle Azure sur une adresse IP non routable de lien local telle que 169.254.169.254.

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.

Auparavant, nous avions découvert un problème similaire dans une offre sans serveur dans Azure connue sous le nom d'Azure Functions, dans laquelle un attaquant pouvait divulguer le certificat des variables d'environnement du conteneur d'application et l'utiliser pour récupérer l'Entra ID JWT de l'identité managée attribuée en dehors du conteneur d'application. .

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:

À quoi ressemblent les journaux générés ? Il va sans dire que les journaux cloud natifs sont primordiaux pour effectuer la détection et la réponse aux incidents de sécurité, à la conformité, à l'audit et à diverses autres fins. Pour examiner les journaux générés à partir d'une requête légitime (c'est-à-dire du CI) et d'une requête malveillante (c'est-à-dire en dehors du CI en utilisant la paire de clés de certificat comme nous l'avons détaillé précédemment), nous avons effectué une procédure pour récupérer l'Entra ID JWT de une identité managée attribuée par le système à un CI :

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

Figure 17. Procédure légitime pour récupérer le jeton Entra ID de l'identité gérée attribuée

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.

La requête malveillante proviendrait de n’importe où en dehors du CI. Nous avons utilisé le certificat et la clé privée pour récupérer le JWT, comme nous l'avons détaillé précédemment. Nous avons constaté que les journaux de connexion générés par une tentative légitime et une tentative malveillante étaient presque identiques, avec des différences uniquement dans les champs ID, ID de corrélation et identifiant de jeton unique.

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.

De plus, il est impossible de savoir exactement d’où provient la demande de récupération du jeton, car les journaux générés ne contiennent pas d’indicateurs spécifiques à l’emplacement, comme une adresse IP. Les journaux de connexion pour les identités gérées ne contiennent pas d'adresses IP (un domaine d'amélioration connu dans l'aspect de journalisation du service d'identité géré) et cela est très probable car les connexions d'identité gérées sont effectuées par des ressources dont les secrets sont gérés par Azur. Cependant, dans notre cas, nous pourrions utiliser les informations d'identification (certificat et paire de clés) en dehors de la ressource à laquelle l'identité managée a été attribuée.

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.

Pour invalider un certificat et une paire de clés, il faudrait supprimer le CI de l'espace de travail AML. Nous n’avons trouvé aucune documentation sur la façon dont on pourrait alterner le certificat et la paire de clés. Cela peut être dû au fait que le service AML est un service géré et que ces informations d'identification sont gérées par Microsoft. De plus, le certificat serait valable deux ans à compter de la date de création de l'IC.

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:

Chronologie de la divulgationNous avons signalé à Microsoft cette vulnérabilité résultant de différences dans les API proposées par les agents dans les CI AML via la Zero Day Initiative (ZDI) de Trend Micro. Voici le calendrier de divulgation pour le 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 avril 2023 – ZDI a signalé la vulnérabilité au fournisseur. 11 avril 2023 – Le fournisseur a accusé réception du rapport. 13 juillet 2023 – ZDI a demandé une mise à jour. 19 juillet 2023 – Le fournisseur nous a demandé de participer à un appel pour en discuter. le rapport.19 juillet 2023 – ZDI s'est joint à l'appel et a fourni au fournisseur des détails supplémentaires.20 juillet 2023 – Le fournisseur a déclaré qu'il considérait ce bug comme étant de faible gravité et qu'il publierait un correctif dans 30 à 45 jours.Juillet 20 août 2023 – ZDI a informé le fournisseur que le cas devait être réglé le 5 août 2023 et que nous publierions ce cas sous forme d'avis Zero Day le 9 août 2023. Pour Black Hat USA 2023, nous avions prévu de partager cette recherche avec la communauté. Cependant, avant l'enregistrement de la conférence, nous avons constaté que cette vulnérabilité était reproductible et non corrigée. Nous avons contacté Microsoft et ils ont estimé que le bug était de faible gravité. Plus tard, à la demande de Microsoft, nous avons expurgé les détails de ce bug, même s'il dépassait la politique de divulgation de 90 jours de ZDI et était également reproductible.

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 a récemment confirmé que la vulnérabilité avait été corrigée en janvier 2024. Actuellement, le correctif ne permet pas d'utiliser la paire de clés de certificat en dehors du 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.

ConclusionLa gestion des informations d'identification et son cycle de vie jouent un rôle crucial dans la sécurité du cloud. La protection des comptes de stockage dans les espaces de travail AML est d'une importance cruciale puisque les modèles, ensembles de données, scripts et journaux ML, entre autres entités, sont stockés dans des partages de fichiers et des conteneurs blob. Lorsqu'un espace de travail AML est créé, par défaut, le compte de stockage est accessible publiquement à l'aide de la clé d'accès.

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.

Un exemple récent de l'importance cruciale de la protection des comptes de stockage, en particulier dans AML, réside dans la récente atténuation du Microsoft Security Response Center (MSRC) : un jeton de signature d'accès partagé (SAS) trop permissif s'est avéré exposer 38 téraoctets de données sensibles. informations issues de la recherche Microsoft AI. De plus, le jeton SAS permettait l'accès en écriture aux fichiers du compte de stockage (ce qui signifie que toute personne disposant de l'URL pouvait modifier les fichiers du compte de stockage contenant des modèles ML). Cela aurait pu aboutir à une attaque classique de la chaîne d’approvisionnement contre des systèmes dépendant de référentiels fiables.

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

D’après notre analyse de la convention de dénomination des comptes de stockage et des noms de conteneurs, le compte de stockage de la recherche Microsoft AI provenait probablement d’un espace de travail AML. Lorsqu'un espace de travail AML est créé, le compte de stockage porte son nom comme nom de l'espace de travail, suivi de 10 chiffres aléatoires (Figure 18).

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

Figure 18. Convention de dénomination des comptes de stockage observée lors de la création d'un espace de travail 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.

De plus, les noms de conteneur commençant par « azureml » dans le compte de stockage « robustnessws4285631339 » sont spécifiques au service AML (Figure 19). Lors de la création d'un espace de travail AML, des conteneurs portant le même nom sont créés par défaut dans un compte de stockage.

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

Figure 19. Conteneurs Azure ML mentionnés dans le compte de stockage « robustnessws4285631339 »

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.

Les défenseurs peuvent exploiter divers cadres tels que Threat Matrix for Storage Services et Azure Threat Research Matrix, qui peuvent les aider à évaluer l’état de sécurité de leurs environnements. Spécifiquement pour les environnements ML, on peut utiliser le framework MITRE ATLAS, une base de connaissances de tactiques et de techniques adverses basées sur des observations d'attaques réelles et des démonstrations réalistes des équipes rouges d'IA et des groupes de sécurité. Il existe des études de cas spécifiques qui mettent en lumière des attaques réelles ciblant les environnements ML, telles que la confusion des dépendances PyTorch, entre autres.

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:

Les praticiens du cloud doivent également adopter un état d'esprit « supposer une violation » pour rester vigilants face aux cas extrêmes inaperçus, comme nous l'avons détaillé en discutant de la manière dont les informations d'identification sont obtenues sur les ressources cloud. Le respect des meilleures pratiques permet de réduire le risque d’exposition, même lorsque certaines lignes de défense sont violées. Ces pratiques comprennent :

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

Sécuriser les déploiements à l'aide de réseaux virtuels. Utiliser des rôles personnalisés minimaux pour les identités. Suivre des pratiques de défense en profondeur.