
Générateur de DOCX malveillant exploitant CVE-2021-40444 (RCE Microsoft Office Word) avec chargement latéral de DLL basé sur CAB et des chaînes d'attaque RAR/WSF sans CAB pour les tests de pénétration.
Générateur de docx malveillant pour exploiter CVE-2021-40444 (Exécution de code à distance dans Microsoft Office Word), fonctionne avec des fichiers DLL arbitraires.
Bien que de nombreux PoC existent déjà sur Internet, j'ai décidé de me lancer dans l'armement de cette vulnérabilité, car ce que j'ai trouvé manquait d'informations précieuses qui méritent d'être partagées, d'autant plus que Microsoft a déjà publié un correctif pour cette vulnérabilité.
Jusqu'à présent, les seules ressources précieuses que j'ai vues pour créer un générateur pleinement fonctionnel sont :
Les ressources ci-dessus décrivent une grande partie des exigences nécessaires pour créer une chaîne complète. Pour éviter de répéter trop d'informations inutiles, je vais simplement résumer les détails pertinents.
Il y a pas mal d'exigences négligées pour que cet exploit fonctionne, ce qui a fait que même de bons PoC, comme celui de lockedbyte, échouent à bien fonctionner.
Peut-être que personne ne les a explicitement "divulgués" pour éviter que la vulnérabilité soit davantage exploitée. Mais maintenant qu'elle est corrigée, la divulgation des détails ne devrait pas poser beaucoup de problèmes.
D'après ce tweet de Will Dormann, le HTML doit avoir une taille d'au moins 4096 octets pour déclencher l'"aperçu" dans MS Word.
Le fichier CAB doit être modifié au niveau des octets pour éviter les erreurs d'extraction et réaliser le ZipSlip :
filename.inf doit devenir ../filename.inffilename.inf coffCabStartCFFOLDER.typeCompress CFFOLDER.coffCabStart doit être augmenté de 3 (à cause du '../' ajouté)CFFOLDER.cCfData CFFILE.cbFile doit être supérieur à CFHEADER.cbCabinet entierCFDATA.csum Les raisons de ces contraintes sont nombreuses, et je n'ai pas passé assez de temps à toutes les comprendre en profondeur, mais voyons les plus importantes :
NOTE1 : Defender détecte désormais si le fichier CAB contient un PE en utilisant la valeur _IMAGE_DOS_HEADER.e_magic comme signature, empêchant potentiellement l'inclusion de fichiers PE dans le CAB. Cette signature peut-elle être contournée ? Je n'en suis pas sûr mais, comme observé précédemment, il s'agit d'une vulnérabilité corrigée, donc je ne prévois pas d'investir plus de temps là-dessus. Au lecteur curieux de développer cela davantage.
NOTE2 : Le correctif Microsoft bloque les schémas d'URI arbitraires, apparemment en utilisant une approche de liste noire (ce n'est qu'une supposition)
La principale chaîne d'attaque associée à CVE-2021-40444 est l'attaque DLL chargée via le schéma d'URI .cpl. Pour l'exploiter, un attaquant doit générer une DLL spécialement conçue. Si vous voulez tester, essayez mon script evildll-gen.
Comme l'a noté Max Maluin, il est possible d'interagir avec plusieurs types de fichiers en abusant d'IE et de l'URI basée sur l'extension de fichier associée. Bien que cela puisse être un bon moyen d'exploiter IE, cela a des limites.
En effet, il faut noter que la méthode utilisée dans l'exploit pour télécharger des fichiers est basée sur les mises à jour des contrôles ActiveX et ne peut pas être utilisée pour télécharger des fichiers arbitraires. Selon la documentation Microsoft, la balise codebase ne peut pointer que vers quelques types de fichiers : OCX, INF et CAB.
Même si nous pouvons télécharger directement un fichier OCX ou INF, nous ne pouvons pas être sûrs de télécharger le fichier au bon endroit dans le système. Avec l'exploit CAB, il est possible de déplacer le fichier .inf dans un chemin bien connu en utilisant la traversée de chemin, mais dans tout autre cas, le fichier sera stocké dans un répertoire aléatoire, le rendant virtuellement impossible à référencer.
À ce jour, je n'ai pas trouvé de moyen d'enchaîner le téléchargement et l'exécution SANS un fichier CAB.
Note : En parlant d'IE seul, la contrebande HTML (HTML smuggling) pourrait être un scénario possible pour exploiter la vulnérabilité.
Cette technique a été divulguée pour la première fois par Eduardo Braun sur Twitter et expliquée plus en détail dans ce document.
Veuillez noter qu'avec cette technique, la chaîne d'attaque est un peu différente. Cette attaque nécessite que l'utilisateur télécharge un fichier RAR spécialement conçu, obtenu en chaînant un script WSF valide et un fichier RAR valide. Une fois ouvert, le RAR contiendra un DOCX avec une référence à un HTML, qui à son tour essaiera de charger le fichier RAR en tant que script WSF.
Pour résumer :