Site icon Cyberdian Groupe, Cabinet de Conseil en Cybersécurité

NotLegit: la vulnérabilité d’Azure App Service a exposé des centaines de référentiels de codes source

L’équipe de recherche Wiz (Wiz Research Team) a détecté un comportement par défaut non sécurisé dans Azure App Service qui exposait le code source des applications client écrites en PHP, Python, Ruby ou Node et qui étaient déployées à l’aide de « Local Git ». La vulnérabilité baptisée « NotLegit », existe depuis septembre 2017 et a probablement été exploitée à l’état sauvage.

Wiz a signalé cette faille de sécurité à Microsoft le 7 octobre 2021, et elle a maintenant été atténuée. De petits groupes de clients sont toujours potentiellement exposés et devraient prendre certaines mesures auprès d’utilisateur pour protéger leurs applications, comme détaillé dans plusieurs alertes par e-mail que Microsoft a émises entre le 7 et le 15 décembre 2021.

Basique

Basique, simple, simple, basique

Vous n’avez pas les bases, vous n’avez pas les bases

ORELSAN, Septembre 2017

Qu’est-ce qu’Azure App Service ?

Azure App Service (AKA Azure Web Apps) est une plate-forme basée sur le cloud computing pour l’hébergement de sites Web et d’applications Web. Le service est facile à utiliser, et donc très populaire : vous devez d’abord sélectionner le langage de programmation et le système d’exploitation pris en charge. Ensuite, vous déployez le code source ou les artefacts de votre application sur un serveur géré par Azure à l’aide de FTP, SSH ou en extrayant le code source d’un service Git (tel que GitHub ou des référentiels Git privés). Après le déploiement, l’application est accessible à tous sur Internet sous leur domaine *.azurewebsites.net.

Qu’est-ce que « Git local » ?

Azure prend en charge plusieurs méthodes pour déployer le code source et les artefacts sur le service Azure App, dont l’une utilise « Local Git ». Avec « Local Git », vous initiez un référentiel Git local dans le conteneur Azure App Service qui vous permet de pousser votre code directement vers le serveur.

La faille de sécurité : votre dépôt Git local était accessible au public

En tant que meilleure pratique, lorsque vous déployez des référentiels git sur des serveurs Web et des compartiments de stockage, il est toujours important de s’assurer que le dossier .git n’est pas également chargé. Pourquoi? Parce que le dossier .git contient le code source, les e-mails des développeurs et d’autres données sensibles. Cependant, lorsque la méthode de déploiement « Local Git » a été utilisée pour déployer sur Azure App Service, le référentiel git a été créé dans le répertoire accessible au public (/home/site/wwwroot) auquel tout le monde pouvait accéder. C’était une bizarrerie connue de Microsoft. Pour protéger vos fichiers, Microsoft a ajouté un fichier « web.config » au dossier .git du répertoire public qui limitait l’accès public. Cependant, seul le serveur Web IIS de Microsoft gère les fichiers « web.config ». Si vous utilisez C# ou ASP.NET, l’application est déployée avec IIS et cette atténuation convient parfaitement.

Mais que se passe-t-il lorsque vous utilisez PHP, Ruby, Python ou Node ? Ces langages de programmation sont déployés avec différents serveurs Web (Apache, Nginx, Flask, etc.), qui ne gèrent pas les fichiers « web.config », les laissant insensibles à l’atténuation et donc complètement vulnérables. Fondamentalement, tout ce qu’un acteur malveillant avait à faire était de récupérer le répertoire « /.git » de l’application cible et de récupérer son code source.

Fait amusant : le fichier web.config de Microsoft comportait une faute de frappe (la balise de configuration n'était pas fermée correctement) qui rendait le fichier impossible à analyser par IIS. Heureusement, l'erreur soulevée par la faute de frappe a fini par bloquer l'accès à tout le répertoire… On peut donc dire que "web.config" a servi sa proposition après tout 😊

Plus tard, Microsoft a découvert que les utilisateurs qui utilisaient d’autres outils de déploiement Git pouvaient également être exposés : si un fichier a été créé ou modifié dans le conteneur Azure App Service (à l’aide de SFTP, Web Deploy ou SSH) avant tout déploiement Git, le service entre un état de « déploiement en place ». Cet état force tout déploiement futur de Git à être lancé dans le répertoire accessible au public. Pour plus de détails, reportez-vous à Déploiement sur place et sans référentiel.

NotLegit Vulnerability

Qui est concerné ?

Toutes les applications PHP, Node, Ruby et Python qui ont été déployées à l’aide de « Local Git » sur une application par défaut propre dans Azure App Service depuis septembre 2017. Toutes les applications PHP, Node, Ruby et Python qui ont été déployées dans Azure App Service à partir de septembre 2017 à l’aide de n’importe quelle source Git, après la création ou la modification d’un fichier dans le conteneur d’applications. Les seules applications qui n’ont pas été affectées par cette faille de sécurité sont les applications basées sur IIS.

Microsoft a envoyé différentes notifications par e-mail à tous les utilisateurs concernés en fonction de leur configuration entre le 7 et le 15 décembre 2021.

Exploité à l’état sauvage

Pour évaluer le risque d’exposition au problème que WIZ a trouvé, WIZ a déployé une application Azure App Service vulnérable, l’a liée à un domaine inutilisé et ont attendu patiemment de voir si quelqu’un essayait d’accéder aux fichiers .git. Dans les 4 jours suivant le déploiement, WIZ n’a pas été surpris de voir plusieurs demandes pour le dossier .git d’acteurs inconnus.

Cette méthode d’exploitation étant extrêmement simple, courante et activement exploitée, WIZ encourage tous les utilisateurs concernés à consulter le code source de leur application et à évaluer le risque potentiel :

Traduit de l'article de référence de l'équipe de recherche de WIZ https://blog.wiz.io/azure-app-service-source-code-leak/

 

Quitter la version mobile