D’après notre cellule de Cyber Threat Intelligence, plus d’un millier d’identifiants d’accès sont rendus publics 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.
