Overlooked Requirements

There are quite a bit of overlooked requirements for this exploit to work, which caused even good PoCs, like the one by lockedbyte, to fail working properly.

Maybe nobody explicitly "released" them to avoid the vulnerability to be exploited more. But now it's patched, so it should not cause a lot of troubles to release the details.

HTML File

As for this tweet by Will Dormann, the HTML should be at least 4096 bytes in size in order to trigger the "Preview" within MS Word.

CAB File

The CAB file needs to be byte-patched to avoid extraction errors and to achieve the ZipSlip:

• filename.inf should become ../filename.inf
• filename.inf should be exactly <12-char>.inf Not really true, the important bit is to modify coffCabStart
• CFFOLDER.typeCompress should be 0 (not compressed)
• CFFOLDER.coffCabStart should be increased by 3 (due to the added '../'')
• CFFOLDER.cCfData should be 2
• CFFILE.cbFile should be greater than the whole CFHEADER.cbCabinet
• CFDATA.csum should be recalculated (or zeroed out) [OPTIONAL]

The reason for these constraints are many, and I didn't spend enough time to deeply understand all of them, but let's see the most important:

• TypeCompress: If the CAB is compressed, the trick to open it within an object file to trigger the INF write will fail False, I managed to achieve the same result with a MSZIP compressed sample
• CoffCabStart: CoffCabStart gives the absolute position of the first CFDATA structure, as we added a '../', we would need to increase this by 3 to point to the file (this is more like a guess)
• cCfData: As there is only 1 file, we should have just 1 CFDATA, I'm not too sure why this has to be set to 2 Indeed, we can leave it as 1
• cbFile: Interestingly, if the CAB extraction concludes without any error, the INF file will be marked for deletion by WORD, ruining the exploit. The only way to prevent this is to make WORD believe the extraction failed. If the cbFile value is defined as greater than the cabinet file itself, the extractor will reach an EOF before reading all the bytes defined in cbFile, raising an extraction error.
• [OPTIONAL] This value seems to not be checked by MS Word. Anyway, to have a correct CAB, the csum value should be recalculated. Luckily, as noted by j00sean and according to MS documentation, this value can be 0

NOTE1: Defender now detects if the CAB file contains a PE by using the _IMAGE_DOS_HEADER.e_magic value as a signature, potentially avoiding PE files to be embedded in the CAB. Can this signature be bypassed? I'm not sure but, as observed before, this is a patched vulnerability, so I'm not planning to invest much more time on this. Up to the curious reader to develop this further.

NOTE2: Microsoft Patch blocks arbitrary URI schemes, apparently using a blacklist approach (this is just a supposition)

DLL Attack

The main attack chain associated with CVE-2021-40444 is the DLL attack loaded via the .cpl URI scheme. In order to exploit that, an attacker needs to generate a specially crafted DLL. If you want to test it out, try my evildll-gen script.

JScript, VBScript, Javaw, MSIexec, ...

As noted by Max Maluin, it is possible to interact with several filetypes abusing IE and the associated file extension based URI. While this is might be a good way to exploit IE, it has limitations.

Indeed, it should be noted that the method used in the exploit to download files is based on ActiveX control updates, and cannot be used to download arbitrary files. As per Microsoft documentation, the codebase tag can point just to a few filetypes: OCX, INF and CAB.

Even if we can directly download an OCX or INF file, we still can't be sure to download the file in the right location within the system. With the cab exploit, it is possible to move the .inf file in a well-known path using the path traversal, but in any other case the file will be stored in a random directory, making it virtually impossible to reference it.

As of today, I didn't find a way to chain download and execution WITHOUT a CAB file.

Note: Talking about IE alone, HTML smuggling could be a possible scenario to exploit the vulnerability.

Cab-less file attack using hybrid RAR file

This technique was firstly disclosed by Eduardo Braun on Twitter and further explained in this paper.

Please note that using this technique, the attack chain is a bit different. This attack requires the user to download a specially crafted RAR file, obtained by chaining a valid WSF script and a valid RAR file. Once opened, the RAR will contain a DOCX with a reference to an HTML, which in turn will try to load the RAR file as a WSF script.

To summarise:

1. Specially crafted RAR file is downloaded (likely Download folder)
2. DOCX extracted and opened
3. Relationship stored in document.xml.rels points to malicious html
4. IE preview is launched to open the HTML link
5. JScript within the HTML contains a script/iframe pointing to the RAR file, prefixed with the ".wsf:" URI scheme
6. As the RAR was designed to be contemporaneously a valid RAR and a valid WSF script, the script is executed

What are the exploits PoC implemented by the tool

The generator utility can currently reproduce the following attacks:

¹The CAB is not downloaded properly in some environments

²The user needs to click on "Save" to download the file on IE

³Not really working on all Windows/MS Word versions

CAB file parser

The utility cab_parser.py can be used to see the headers of the exploit file, but don't consider this a full parser. It's a very quick and dirty CAB header viewer I developed to understand what was going on.

Install

The generator is designed to work on Windows, as it uses the makecab utility. Before usage, be sure to install required dependencies:

• With Virtualenv

• Without Virtualenv

Usage

The generator is trivial to use, and even if it has been tested with a number of different payloads and Windows versions, it is not fail-proof. I'm encountering different behaviours across different Windows builds. As soon as I have more details to share, I'll post them here.

Example

• Generate the original exploit and test it locally

Note: the port is selected by the URL, and the exploit is generated basing on the payload file extension

• Generate the CABless exploit with RAR and test it locally via IE

• Generate the CABless exploit (IE-only) with HTML smuggling and test it locally via IE

• Generate the CABless exploit leveraging MS-MSDT (Follina attack), in both DOCX and RTF docs

Credits

• RET2_pwn for the amazing blog
• j00sean for the good hints
• lockedbyte for the first decent poc
• Max_Mal for the hint on the alternate URI schemes
• wdormann for the hint on the HTML file size restrictions
• Edu_Braun_0day for the cool CAB-less version of the exploit
• Kevin Beaumont for the research on CVE-2022-30190 (Follina)