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 :
Utilisateurs qui ont déployé du code via FTP ou Web Deploy ou Bash/SSH, ce qui a entraîné l’initialisation des fichiers dans l’application Web avant tout déploiement de git.
Utilisateurs ayant activé LocalGit sur l’application Web
Utilisateurs qui clonent/poussent ensuite la séquence Git pour publier des mises à jour
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/
Retrouver la 1ère partie de l’article Retour d’expérience (REX): Comment garantissez-vous l’efficacité des mesures de sécurité de vos équipements de sécurité périmétriques ? – Partie 1 – Cyberdian 3. Le moteur Plusieurs fonctions peuvent être tourner autour du moteur d’un [...]
Pour offrir les meilleures expériences, nous utilisons des technologies telles que les cookies pour stocker et/ou accéder aux informations des appareils. Le fait de consentir à ces technologies nous permettra de traiter des données telles que le comportement de navigation ou les ID uniques sur ce site. Le fait de ne pas consentir ou de retirer son consentement peut avoir un effet négatif sur certaines caractéristiques et fonctions.
Fonctionnel
Toujours activé
L’accès ou le stockage technique est strictement nécessaire dans la finalité d’intérêt légitime de permettre l’utilisation d’un service spécifique explicitement demandé par l’abonné ou l’utilisateur, ou dans le seul but d’effectuer la transmission d’une communication sur un réseau de communications électroniques.
Préférences
L’accès ou le stockage technique est nécessaire dans la finalité d’intérêt légitime de stocker des préférences qui ne sont pas demandées par l’abonné ou l’internaute.
Statistiques
Le stockage ou l’accès technique qui est utilisé exclusivement à des fins statistiques.Le stockage ou l’accès technique qui est utilisé exclusivement dans des finalités statistiques anonymes. En l’absence d’une assignation à comparaître, d’une conformité volontaire de la part de votre fournisseur d’accès à internet ou d’enregistrements supplémentaires provenant d’une tierce partie, les informations stockées ou extraites à cette seule fin ne peuvent généralement pas être utilisées pour vous identifier.
Marketing
L’accès ou le stockage technique est nécessaire pour créer des profils d’internautes afin d’envoyer des publicités, ou pour suivre l’utilisateur sur un site web ou sur plusieurs sites web ayant des finalités marketing similaires.