Microsoft a incorporé des améliorations supplémentaires pour résoudre la vulnérabilité de sécurité SynLapse récemment révélée afin de répondre à toutes les isolement des locataires conditions dans Azure Data Factory et Azure Synapse Pipelines.
Les dernières protections incluent le déplacement des runtimes d’intégration partagés vers des instances éphémères en bac à sable et l’utilisation de jetons étendus pour empêcher les adversaires d’utiliser un certificat client pour accéder aux informations d’autres locataires.
« Cela signifie que si un attaquant pouvait exécuter du code sur le environnement d’exécution d’intégrationil n’est jamais partagé entre deux locataires différents, donc aucune donnée sensible n’est en danger », a déclaré Orca Security dans un rapport technique détaillant le défaut.
Le problème de haute gravité, suivi comme CVE-2022-29972 (score CVSS : 7,8) et divulgué au début du mois dernier, aurait pu permettre à un attaquant d’exécuter une commande à distance et d’accéder à l’environnement cloud d’un autre client Azure.
Initialement signalé par la société de sécurité cloud le 4 janvier 2022, SynLapse n’a été entièrement corrigé que le 15 avril, un peu plus de 120 jours après la divulgation initiale et deux correctifs antérieurs déployés par Microsoft se sont avérés facilement contournables.
« SynLapse a permis aux attaquants d’accéder aux ressources Synapse appartenant à d’autres clients via un serveur d’API Azure interne gérant les runtimes d’intégration », ont déclaré les chercheurs.
En plus de permettre à un attaquant d’obtenir des informations d’identification sur d’autres comptes clients Azure Synapse, la faille a permis de contourner la séparation des locataires et d’exécuter du code sur les machines client ciblées ainsi que de contrôler Espaces de travail Synapse et divulguer des données sensibles à d’autres sources externes.
À la base, la question porte sur un cas de injection de commande trouvé dans le Magnitude Simba Amazon Redshift Connecteur ODBC utilisé dans Azure Synapse Pipelines qui pourrait être exploité pour obtenir l’exécution de code sur le runtime d’intégration d’un utilisateur ou sur le runtime d’intégration partagé.
Avec ces capacités en main, un attaquant aurait pu vider la mémoire du processus qui gère les connexions externes, divulguant ainsi les informations d’identification aux bases de données, serveurs et autres services Azure.
Plus inquiétant encore, un certificat client contenu dans le runtime d’intégration partagé et utilisé pour l’authentification auprès d’un serveur de gestion interne pourrait être utilisé comme arme pour accéder aux informations relatives à d’autres comptes clients.
En reliant le bogue d’exécution de code à distance et l’accès au certificat du serveur de contrôle, le problème a effectivement ouvert la porte à l’exécution de code sur n’importe quel runtime d’intégration sans rien connaître d’autre que le nom d’un espace de travail Synapse.
« Il convient de noter que la principale faille de sécurité n’était pas tant la capacité d’exécuter du code dans un environnement partagé que les implications d’une telle exécution de code », ont noté les chercheurs.
« Plus précisément, le fait qu’un RCE sur le runtime d’intégration partagé nous permette d’utiliser un certificat client donnant accès à un puissant serveur d’API interne. Cela a permis à un attaquant de compromettre le service et d’accéder aux ressources d’autres clients. »