Microsoft a récemment « atténué » une vulnérabilité de sécurité découverte par Palo Alto Networks, affectant le service d’informatique en nuage sans serveur Azure Container Instances (ACI), et qui permettrait à un utilisateur d’accéder aux informations d’autres utilisateurs du service.
Nous en déduisons que l’éditeur de logiciels n’a pas corrigé à 100 % la vulnérabilité. D’après son enquête, aucun accès non autorisé ne s’est produit.
Par précaution, Microsoft a envoyé une notification aux clients ayant fait tourner des conteneurs sur la même grappe que les chercheurs.
Et leur recommande de révoquer tous certificats à hauts privilèges déployés sur la plateforme avant le 31 août 2021.
Comme dans le cas de la faille de sécurité, potentiellement catastrophique, de CosmosDB, la réponse de Microsoft nous semble particulièrement cavalière : nous recommandons à toute personne ayant jamais utilisé le service ACI de changer tous les certificats liés au service.
Nous sommes pour le moins étonnés que Microsoft ne fournisse aucun détail sur la vulnérabilité.
Quelques précisions sont disponibles sur le blogue de Palo Alto Networks, qui a baptisé cette vulnérabilité « Azurescape », un jeu de mots sur « Azure » et « s’évader ».
Il s’agit en effet de trouver un moyen de contourner la frontière qui entoure toutes les instances d’un même locataire. Pour cela, les chercheurs auraient exploité une erreur de conception des conteneurs Linux qui serait rarement discutée, et qui permet de lire l’environnement d’exécution de l’hôte du conteneur.
Ils ont découvert qu’il s’agissait du standard de l’industrie, RunC. Mais sa version, publiée le 1er octobre 2016, est vulnérable à plusieurs exploits d’échappement.
Ils ont donc recréé un conteneur « malicieux » comme preuve d’existence, qui s’est échappé du conteneur et a même obtenu une interface système inversée avec accès root (le plus privilégié).
Toutefois, ils restaient prisonniers des frontières.
Pour simplifier, les chercheurs ont découvert que le serveur d’api, qui communique de temps en temps avec les Kubelets, était d’une vieille version, vulnérable à la redirection de requêtes vers d’autres Kubelets, et que les trois prérequis nécessaires pour abuser du système étaient disponibles pour la commande az container exec, qui reflète kubectl exec.
Partant de là, ils trouvèrent un moyen de pouvoir exécuter des commandes en tant qu’administrateur de la grappe de conteneurs.