CVE-2021-40444 entièrement armé

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.

Contexte

Bien que de nombreux PoC soient déjà disponibles sur Internet, j'ai décidé de tenter de transformer cette vulnérabilité en arme, car ce que j'ai trouvé disponible 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 entièrement fonctionnel sont :

• Blog de Ret2Pwn
• Tweet de j00sean

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.

Chaîne d'exploitation

1. Le docx est ouvert
2. La relation stockée dans document.xml.rels pointe vers un html malveillant
3. L'aperçu d'IE est lancé pour ouvrir le lien HTML
4. Le JScript dans le HTML contient un objet pointant vers un fichier CAB, et une iframe pointant vers un fichier INF, préfixé avec la directive ".cpl:"
5. Le fichier cab est ouvert, le fichier INF est stocké dans le répertoire %TEMP%\Low
6. En raison d'une vulnérabilité de traversée de chemin (ZipSlip) dans le CAB, il est possible de stocker l'INF dans %TEMP%
7. Ensuite, le fichier INF est ouvert avec la directive ".cpl:", ce qui provoque le chargement latéral du fichier INF via rundll32 (s'il s'agit d'une DLL)

Exigences négligées

Il y a pas mal d'exigences négligées pour que cet exploit fonctionne, ce qui a fait échouer même de bons PoCs, comme celui de lockedbyte, à fonctionner correctement.

Peut-être que personne ne les a explicitement « publiées » pour éviter que la vulnérabilité soit davantage exploitée. Mais maintenant qu'elle est corrigée, cela ne devrait pas poser trop de problèmes de publier les détails.

Fichier HTML

Comme le dit 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.

Fichier CAB

Le fichier CAB doit être patché au niveau octet pour éviter les erreurs d'extraction et pour réaliser le ZipSlip :

• filename.inf devrait devenir ../filename.inf
• filename.inf devrait être exactement <12-char>.inf Pas tout à fait vrai, l'important est de modifier coffCabStart
• CFFOLDER.typeCompress devrait être 0 (non compressé)
• CFFOLDER.coffCabStart devrait être augmenté de 3 (en raison de l'ajout de '../')
• CFFOLDER.cCfData devrait être 2
• CFFILE.cbFile devrait être supérieur à l'intégralité de CFHEADER.cbCabinet
• CFDATA.csum devrait être recalculé (ou mis à zéro) [OPTIONNEL]

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 :

• TypeCompress : Si le CAB est compressé, l'astuce pour l'ouvrir dans un fichier objet afin de déclencher l'écriture de l'INF échouera Faux, j'ai réussi à obtenir le même résultat avec un échantillon compressé MSZIP.
• CoffCabStart : CoffCabStart donne la position absolue de la première structure CFDATA ; comme nous avons ajouté un '../', nous devrions augmenter cette valeur de 3 pour pointer vers le fichier (c'est plus une supposition).
• cCfData : Comme il n'y a qu'un seul fichier, nous devrions avoir un seul CFDATA, je ne suis pas trop sûr de la raison pour laquelle cela doit être réglé sur 2 En effet, nous pouvons le laisser à 1.
• cbFile : Fait intéressant, si l'extraction du CAB se termine sans erreur, le fichier INF sera marqué pour suppression par WORD, ce qui ruine l'exploit. La seule façon de l'empêcher est de faire croire à WORD que l'extraction a échoué. Si la valeur de cbFile est définie comme supérieure au fichier cabinet lui-même, l'extracteur atteindra une fin de fichier (EOF) avant de lire tous les octets définis dans cbFile, ce qui déclenchera une erreur d'extraction.
• [OPTIONNEL] Cette valeur ne semble pas être vérifiée par MS Word. Quoi qu'il en soit, pour avoir un CAB correct, la valeur csum devrait être recalculée. Heureusement, comme l'a noté j00sean et selon la documentation MS, cette valeur peut être 0.

NOTE1 : Defender détecte désormais si le fichier CAB contient un PE en utilisant la valeur _IMAGE_DOS_HEADER.e_magic comme signature, ce qui peut empêcher l'intégration 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'y investir beaucoup plus de temps. 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).

Attaque par DLL

La principale chaîne d'attaque associée à CVE-2021-40444 est l'attaque par DLL chargée via le schéma d'URI .cpl. Pour exploiter cela, un attaquant doit générer une DLL spécialement conçue. Si vous voulez la tester, essayez mon script evildll-gen.

JScript, VBScript, Javaw, MSIexec, ...

Comme l'a noté Max Maluin, il est possible d'interagir avec plusieurs types de fichiers en abusant d'IE et de l'URI associée basée sur l'extension de fichier. Bien que cela puisse être un bon moyen d'exploiter IE, cela a des limites.

En effet, il convient de noter que la méthode utilisée dans l'exploit pour télécharger des fichiers est basée sur les mises à jour de 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 toujours 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, ce qui rend son référencement pratiquement impossible.

À ce jour, je n'ai pas trouvé de moyen d'enchaîner téléchargement et exécution SANS fichier CAB.

Remarque : En parlant d'IE seul, le HTML smuggling pourrait être un scénario possible pour exploiter la vulnérabilité.

Attaque sans fichier CAB utilisant un fichier RAR hybride

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 oblige l'utilisateur à télécharger 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 :