mirror of
https://github.com/klezVirus/CVE-2021-40444.git
synced 2024-11-21 13:00:48 +00:00
Updated README
This commit is contained in:
parent
53af9514ef
commit
37e282beb9
1 changed files with 17 additions and 14 deletions
31
README.md
31
README.md
|
@ -12,7 +12,8 @@ So far, the only valuable resources I've seen to create a fully working generato
|
|||
* [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. As I do not desire
|
||||
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
|
||||
|
@ -36,33 +37,35 @@ 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)
|
||||
* `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 '../',
|
||||
* **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
|
||||
* **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)
|
||||
* 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
|
||||
|
||||
NOTE: Defender now detects the CAB file using the `_IMAGE_DOS_HEADER.e_magic` value as a signature, potentially avoiding
|
||||
**NOTE1**: Defender now detects the CAB file 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? As observed before, this is a patched vulnerability,
|
||||
so I'm not planning to release anything more complex than 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
|
||||
|
|
Loading…
Reference in a new issue