[Azure] Pratique de développement non sécurisée : exposition d’identifiants d’accès

Read the english version

À l’occasion de récents tests d’intrusion, nous avons identifié une pratique de développement exposant des identifiants d’accès à la plateforme Microsoft Azure Web Sites – service permettant de développer et héberger des applications web dans le cloud. Cette pratique peut conduire à la compromission du serveur FTP associé et, par voie de conséquence, permettre un accès illégitime en lecture et en écriture au code source, aux fichiers de journalisation et au système d’exploitation sous-jacent.

D’après notre cellule de Cyber Threat Intelligence, plus d’un millier d’identifiants d’accès sont rendus publiques sur GitHub, Pastebin et autres services d’hébergement de code ou de fichiers.

Contexte

Le service Microsoft Azure Web Sites permet de générer et d’exporter un fichier de configuration PublishSettings ayant vocation à être importé dans PowerShell ou Visual Studio, pour faciliter l’administration de l’application dans une logique de développement continu. Ce fichier , qui permet à ces applications d’effectuer des requêtes sur l’API Azure sans s’encombrer de procédures manuelles, est particulièrement sensible en cela qu’il contient les identifiants et mots de passe d’accès aux serveurs FTP et de déploiement MSDeploy.

Obtention du fichier

Le téléchargement du fichier en question peut être effectué depuis la page de la ressource correspondant à l’application Web sur le portail Azure :

Figure 1 : Obtention du profil de publication

 

Nous obtenons alors un fichier nommé $nomDuSite.PublishSettings dans lequel sont renseignés des identifiants et mots de passe permettant d’accéder au serveur de déploiement MSDeploy (en vert) et au serveur FTP (en bleu) :

Figure 2 : Fichier poc-eval-****.PublishSettings

 

Compromission

La pratique que nous évoquions est la suivante : souvent, le fichier PublishSettings est adjoint au code source du projet. Le fichier parvient alors aux différents intervenants de la chaîne de développement (équipes de développement, auditeurs sécurité, ingénieurs qualité, etc.). et, dans les cas les plus critiques, il est publié sur des services en ligne tels que GitHub ou dans le répertoire du site web (bien qu’Azure bloque par défaut l’accès à ce type de fichiers depuis le navigateur), offrant ainsi la possibilité à un attaquant d’y accéder et d’utiliser les informations sensibles qui y sont stockées.

Supposons en effet que nous avons obtenu le fichier PublishSettings présenté dans la partie précédente. Il nous suffit alors de suivre les liens publishUrl et de renseigner les identifiants et mots de passe indiqués.

Par exemple, nous pouvons nous connecter au serveur FTP et accéder au code source :

Figure 3 : Connexion au serveur FTP

 

Nous pouvons également ajouter ou supprimer des fichiers. Ci-dessous, nous avons supprimé index.html et ajouté poc_ftp.html :

Figure 4 : Édition du contenu du serveur FTP

 

 

Notre fichier poc_ftp.html est effectivement accessible sur l’application Web :

Figure 5 : Accès à poc_ftp.html

 

Il est notamment possible d’exécuter des commandes système en déposant un webshell :

Figure 6 : Exécution de commandes système Windows

 

Enfin, nous pouvons accéder aux journaux de l’application :

Figure 7 : Accès aux journaux de l’application

 

 

Ce fichier de journalisation contient les requêtes effectuées auprès du serveur Web. Nous y retrouvons la requête GET que nous avons effectuée auprès du serveur pour accéder au fichier poc_eval.html :

Figure 8 : Journal d’accès du serveur web

 

 

De nombreux autres fichiers de journalisation sont accessibles sur le serveur FTP : des journaux système qui contiennent des informations relatives au système d’exploitation, des journaux applicatifs dans lesquels sont stockées les sorties des fonctions de debug, ou encore des journaux d’extension indiquant le nom et la version des extensions ajoutées à l’application.

Recommandations

Le contenu de ce fichier étant particulièrement sensible et non chiffré, il convient de porter une attention toute particulière aux permissions qui lui sont appliquées et aux opportunités de lecture par un tiers illégitime.

Intrinsec recommande les pratiques suivantes :

  • Ne pas enregistrer le fichier PublishSettings dans le répertoire du projet ;
  • Supprimer le fichier une fois qu’il a été importé ;
  • Mettre en place des tests unitaires dans la chaîne d’intégration continue pour vérifier l’absence de fichier PublishSettings dans les répertoires publiés ;
  • Inclure la vérification dans les tests effectués par vos scanners de vulnérabilité ;
  • Envisager un cas d’usage spécifique dans les stratégies de détection pour les différents intervenants de la chaîne de développement ;
  • Mettre en surveillance la fuite ou l’exposition de ce type de documents ;
  • Communiquer auprès des équipes de développement sur les bonnes pratiques exposées ci-dessus.