Injection CSV dans les logs Azure

Avec la migration mondiale vers le site cloud, les entreprises ont dû repenser la manière dont elles traquent les activités malveillantes dans leurs environnements. Certains des anciens mécanismes de surveillance (tels que la capture de paquets) ne sont plus disponibles, et les journaux d'événements ont acquis une nouvelle importance. Souvent, ils sont le seul outil dont vous disposez pour suivre ce qui se passe dans votre infrastructure.

Cloud ont connu des difficultés de croissance lorsqu'il s'est agi de mettre en œuvre la fonctionnalité de journalisation. Azure, en particulier, a été confronté à de nombreux problèmes de qualité des journaux. Les journaux constituent également une cible de reconnaissance juteuse pour les attaquants qui cherchent à cartographier votre environnement, et des informations sensibles peuventy être divulguées.

Aussi graves que puissent être ces problèmes, ils sont "passifs" - la divulgation d'informations est le pire qui puisse arriver. Cependant, les journaux peuvent parfois devenir le support d'attaques contre l'entreprise. Nous décrirons un tel exploit dans ce blog.

Injection de journaux et injection de fichiers CSV

Une injection de journal est une attaque par laquelle un adversaire peut influencer le contenu d'un journal en y ajoutant une charge utile malveillante spécialement conçue. En effet, les actions des utilisateurs entraînent souvent l'ajout de nouveaux enregistrements dans les journaux, et ces enregistrements contiennent souvent des données sur lesquelles l'utilisateur a le contrôle : identifiants, adresses électroniques, sujets des messages, etc. Lorsque ces données sont élaborées de manière malveillante, l'application qui traite les journaux peut être amenée à exécuter une attaque. Par exemple, une personne pourrait soumettre une fausse adresse électronique contenant une charge utile XSS (Cross-Site Scripting) dans un formulaire d'inscription à un compte. L'administrateur de l'application qui ouvre ce journal dans un navigateur peut être victime d'une attaque XSS.

Les journaux dans Azure peuvent être téléchargés sous forme de fichiers CSV (Comma-Separated Values), qui sont vulnérables à une technique d'injection CSV. Dans ce type d'attaque, si un fichier CSV contient une formule Excel (commençant généralement par un signe égal - '='), celle-ci est exécutée par Excel lorsqu'il ouvre le fichier. Certaines formules peuvent être malveillantes et entraîner l'exécution de commandes du système d'exploitation ou d'autres exploits. Cela peut être dangereux non seulement parce que des commandes arbitraires peuvent être exécutées, mais aussi parce que les utilisateurs ne le savent généralement pas, pensant que les fichiers CSV ne sont que des fichiers texte simples qui ne peuvent pas causer de dommages. 

Nous avons trouvé une nouvelle instance de Log Injection combinée avec CSV Injection dans Azure, qui peut être utilisée pour attaquer les administrateurs Azure. De telles vulnérabilités ont étésignalées dans le passé, mais cette instance est plus dangereuse car elle peut être exécutéesans authentification, c'est-à-dire que vous n'avez pas besoin d'avoir un compte dans l'environnement cloud .

Scénario d'attaque

L'attaque se déroule en deux étapes :

1. Polluer les journaux Azure

2. Inciter un administrateur victime à ouvrir les journaux sous la forme d'un fichier CSV.

*Notez que l'attaque ne fonctionnera pas sur une instance de MS Excel entièrement mise à jour (nous y reviendrons plus tard).

Pollution des journaux Azure par un agent utilisateur malveillant

Pour polluer les journaux avec une commande malveillante, vous n'avez pas besoin d'autorisations spéciales ni même d'un compte sur le système de la victime. Vous avez simplement besoin du nom d'utilisateur d'un utilisateur existant.

Nous commençons par soumettre la charge utile de l'injection sous la forme d'une chaîne de caractères de l'agent utilisateur :

1. Démarrez Microsoft Edge (n'importe quel navigateur fonctionnera tant que vous pouvez manipuler l'agent utilisateur comme indiqué ci-dessous, de même que n'importe quel proxy d'attaque comme Burp ou ZAP).

2. OuvrezDeveloper Tools (Ctrl+Shift+I), cliquez sur le menu en haut à droite et sélectionnez Run Command(Ctrl+Shift+P) :

3. Tapez"network conditions" et appuyez sur Entrée :

4. Dans le tiroir qui s'ouvre, décochez la case"Utiliser le navigateur par défaut" et collez la chaîne suivante dans le champ inférieur :

=msexcel|'\NWindows\NSystem32\Ncmd.exe /c calc.exe'!'A1'

Cet exemple de formule Excel utilise le protocole Dynamic Data Exchange (DDE) pour lancer Calculator. Dans la réalité, la charge utile sera plus destructrice (par exemple, une commande PowerShell qui télécharge l'étape suivante de l'infection).

5. Sans fermer le tiroir, allez surhttps://portal.azure.comet entrez l'e-mail d'un compte existant dans votre système cible.

6. Lorsque l'on vous demande un mot de passe, entrez n'importe quelle chaîne de caractères(notre objectif n'est pas de réussir à vous connecter !):
   
    

Obtenir de la victime qu'elle ouvre les journaux

Les journaux de connexion dans le locataire Azure cible contiennent maintenant l'enregistrement de journal empoisonné (cela peut prendre quelques minutes pour le livrer).

Maintenant, vous pouvez utiliser l'ingénierie sociale pour amener l'administrateur cible à ouvrir les logs. Il y a deux services dans le portail où cela peut être fait : Log Analytics et Microsoft Entra ID. Nous allons décrire le premier.

Tout utilisateur disposant d'un accès en lecture à Azure Log Analytics suffit, il n'est donc pas nécessaire qu'il s'agisse d'un administrateur disposant de privilèges de premier niveau. 

Plusieurs prétextes sont possibles. Par exemple, un"ingénieur du support technique Azure" peut contacter l'administrateur pour lui demander de l'aider à enquêter sur des"tentatives de connexion suspectes".

Les étapes sont les suivantes :  

1. Demander à la cible d'ouvrirAzure Log Analyticset de charger la tableSigninLogsdans la fenêtre de requête (double-cliquer dessus). Cliquez sur le boutonRun (Exécuter)pour exécuter la requête par défaut :
   
   

2. Le journal se chargera, et l'une des entrées contiendra notre charge utile :

3. Indiquer à la cible de charger le journal sous forme de fichier CSV dans Excel pour"faciliter l'analyse" :
   
   

4. Les journaux se chargeront dans Excel. Un message d'avertissement apparaît, que la cible doit ignorer :
   
   

5. Un autre message d'avertissement apparaît, que la cible doit également ignorer. Notez que l'application dont il se plaint est "MSEXCEL.EXE", ce qui est moins suspect que quelque chose comme "CMD.EXE" :  
   

6. L'instance de la calculatrice s'affichera (comme notre charge utile le prévoyait) :
   
   

Vous pouvez voir l'attaque en action dans cette vidéo:

Gestion de la protection DDE d'Excel

Cette vulnérabilité ne se déclenche pas d'emblée dans la dernière version mise à jour de MS Excel. Microsoft a mis en œuvre des mesures d'atténuation pour empêcher le serveur DDE de se lancer à partir de formules Excel par défaut. Pour que la charge utile fonctionne correctement, la cible doit utiliser une ancienne version d'Excel ou avoir activé lelancement du serveur DDEdans la dernière version d'Excel (par exemple, sur instruction de l'attaquant dans le cadre de la phase d'ingénierie sociale).

Pour désactiver cette protection dans Excel, allez dansFichier > Options > Centre de confiance > Paramètres du centre de confiance... > Contenu externe et cochez l'option Activer le lancement dynamique du serveur d'échange de données : non recommandé.> Contenu externeet cochez la caseActiver le lancement du serveur d'échange dynamique de données (non recommandé) :

Au-delà du DDE

La restriction des appels DDE peut sembler protéger les utilisateurs, mais cette sécurité est trompeuse. Plusieurs autres formules dangereuses ne nécessitant pas d'appel DDE peuvent être injectées. En voici quelques exemples (la plupart généreront un message d'avertissement à l'ouverture du fichier) :

Divulgation

Nous avons divulgué cette vulnérabilité à Microsoft de manière responsable :

2022-09-13 - Rapporté au CSEM
2022-09-21 - Le CSEM a répondu : "...la vulnérabilité existe réellement dans la façon dont Microsoft Excel ouvre les fichiers. Elle nécessite également de cliquer sur un avertissement dans Microsoft Excel. Nous pourrions envisager de bloquer les charges utiles d'injection CSV en tant que précaution DND comme correctif dans les versions suivantes."

Microsoft n'a pas semblé s'engager à apporter des modifications pour empêcher les charges utiles d'injection CSV, et la vulnérabilité existe encore aujourd'hui. 

Atténuation

Bien que Microsoft ait eu raison de déclarer que les mises à jour de sécurité dans Excel empêchent le déclenchement des charges utiles DDE, il y a plusieurs autres facteurs à prendre en compte :

• La victime peut avoir installé une ancienne version non corrigée d'Excel ou avoir fait l'objet d'une ingénierie sociale qui l'a amenée à abandonner ses défenses. Nous avons présenté un scénario à ce sujet ci-dessus.

• Il existe des formules non DDE dans Excel qui peuvent être dangereuses. Nous en avons donné plusieurs exemples. En outre, Microsoft ajoute de nouvellesfonctionnalités Python aux formules Excel, et l'invocation de code Python par injection peut avoir des conséquences nouvelles et inattendues.  

• D'autres applications pourraient ouvrir des fichiers CSV, ce qui pourrait donner lieu à de nouveaux exploits. Par exemple, sous Linux, LibreOffice est une suite bureautique populaire qui sera utilisée pour ouvrir les fichiers CSV. Elle exécute les formules Excel et prend également en charge DDE.

• Enfin, il est important de pratiquer la "défense en profondeur". Il serait conforme à cette pratique non seulement de s'appuyer sur un correctif Excel, mais aussi d'éliminer la possibilité d'injection de formules à la source dans les CSV générés par Azure.

We believe that the right course of action is for Microsoft to sanitize values in CSV file cells that begin with "=" (and some others cells that start with "+", "-", "@", and some other characters can also be interpreted as formulas). The original values do not have to be removed (after all, they may be important to the defender). Prefixing them with some string that clarifies the intent (e.g. "<INSERTED TO MITIGATE POSSIBLE CSV INJECTION>") will be sufficient.

En attendant, il est conseillé aux utilisateurs d'Azure de mettre à jour tous les outils qu'ils utilisent pour ouvrir des fichiers CSV et de former leur personnel informatique aux dangers des charges utiles malveillantes dans les journaux Azure et aux attaques d'ingénierie sociale qui peuvent tenter de les exploiter.

Discutez directement avec nous de cet article de blog et d'autres sujets dans la communauté Reddit. Vectra AI communauté Reddit.