# Fully Weaponized CVE-2021-40444 Malicious docx generator to exploit CVE-2021-40444 (Microsoft Office Word Remote Code Execution), works with arbitrary DLL files. # Background Although many PoC are already around the internet, I guessed to give myself a run to weaponizing this vulnerability, as what I found available lacked valuable information that it's worth sharing, also considering Microsoft already released a patch for this vulnerability. So far, the only valuable resources I've seen to create a fully working generator are: * [Blog by Ret2Pwn](https://xret2pwn.github.io//CVE-2021-40444-Analysis-and-Exploit/) * [Twit by j00sean](https://twitter.com/j00sean/status/1437390861499838466) The above resources outline a lot of the requirements needed to create a full chain. To avoid repeating too much unnecessary information, I'll just summarize the relevant details. ### Exploit Chain 1. Docx opened 2. Relationship stored in document.xml.rels points to malicious html 3. IE preview is launched to open the HTML link 4. JScript within the HTML contains an object pointing to a CAB file, and an iframe pointing to an INF file, prefixed with the ".cpl:" directive 5. The cab file is opened, the INF file stored in the %TEMP%\Low directory 6. Due to a Path traversal (ZipSlip) vulnerability in the CAB, it's possible to store the INF in %TEMP% 7. Then, the INF file is opened with the ".cpl:" directive, causing the side-loading of the INF file via rundll32 (if this is a DLL) ### 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](https://github.com/lockedbyte/CVE-2021-40444), 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. #### 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` * `CFFOLDER.typeCompress` should be 0 (not compressed) * `CFFOLDER.coffCabStart` should be increased by 3 * `CFFOLDER.cCfData` should be 2 * `CFFILE.cbFile` should be greater than the whole `CFHEADER.cbCabinet` * `CFDATA.csum` should be recalculated (or zeroed out) 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 * **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 * **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. * Last but not least, the **csum** value should be recalculated. Luckily, as noted by [j00sean](https://twitter.com/j00sean) and according to [MS documentation](http://download.microsoft.com/download/4/d/a/4da14f27-b4ef-4170-a6e6-5b1ef85b1baa/[ms-cab].pdf), 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) # 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 ``` git clone https://github.com/klezVirus/CVE-2021-40444 cd CVE-2021-40444 pip install virtualenv python -m virtualenv venv venv\Scripts\activate.bat pip install -r requirements ``` * Without Virtualenv ``` git clone https://github.com/klezVirus/CVE-2021-40444 cd CVE-2021-40444 pip install -r requirements ``` # Usage The generator is trivial to use, and has been tested with a number of different DLL payloads. ``` usage: generator.py [-h] -P PAYLOAD -u URL [-o OUTPUT] [--host] [-p LPORT] [-c COPY_TO] [%] CVE-2021-40444 - MS Office Word RCE Exploit [%] optional arguments: -h, --help show this help message and exit -P PAYLOAD, --payload PAYLOAD DLL payload to use for the exploit -u URL, --url URL Server URL for malicious references (CAB->INF) -o OUTPUT, --output OUTPUT Output files basename (no extension) --host If set, will host the payload after creation -p LPORT, --lport LPORT Port to use when hosting malicious payload -c COPY_TO, --copy-to COPY_TO Copy payload to an alternate path ``` # Credits * [RET2_pwn](https://twitter.com/RET2_pwn) for the amazing blog * [j00sean](https://twitter.com/j00sean) for the good hints * [lockedbyte](https://github.com/lockedbyte/CVE-2021-40444) for the first decent poc