Windows CLFS and five exploits used by ransomware operators (Exploit #3 – October 2022)

This is part four of our study about the Common Log File System (CLFS) and five vulnerabilities in this Windows OS component that have been used in ransomware attacks throughout the year. Please read the previous parts first if you haven’t already.

You can skip to the other parts using this table of contents or using the link at the end of this part.

• Part 1 – Windows CLFS and five exploits of ransomware operators
• Part 2 – Windows CLFS and five exploits of ransomware operators (Exploit #1 – CVE-2022-24521)
• Part 3 – Windows CLFS and five exploits of ransomware operators (Exploit #2 – September 2022)
• Part 4 – Windows CLFS and five exploits of ransomware operators (Exploit #3 – October 2022)
• Part 5 – Windows CLFS and five exploits of ransomware operators (Exploit #4 – CVE-2023-23376)
• Part 6 – Windows CLFS and five exploits of ransomware operators (Exploit #5 – CVE-2023-28252)

Exploit #3 – October 2022

Microsoft’s Security Update Guide for October 2022 does not mention any CLFS vulnerabilities, but the driver has been rewritten and new CClfsBaseFile::Validate* functions have been added.

CLFS driver in September 2022 vs. October 2022

The exploit we discovered was developed by the same author who created the zero-day CVE-2022-37969. It works with the September patch and does not work with the October patch, but we only started seeing it in attacks after the October patch was released. We suspect that this exploit may have been a zero-day, but attackers tried to use it more carefully when it was a zero-day, and began using it openly when it was patched.

The exploit creates a new BLF file and patches just six values in it. These patches are shown in the image below.

Patches made to BLF file by exploit #3

The first patch changes the value of the CLFS_BASE_RECORD_HEADER->cbSymbolZone field in the GENERAL block. The other patches build a “fake” CLFS_CONTAINER_CONTEXT structure.

As mentioned in part one of our study that discussed CLFS internals, the cbSymbolZone field is used as the next free offset where a new symbol can be created. The vulnerability is that the cbSymbolZone offset now points to the middle of an existing CLFS_CLIENT_CONTEXT structure and this is not checked. This is what it leads to:

When opening a BLF file, the driver will cache some of the values from CLFS_CLIENT_CONTEXT (just like with exploit #1 – CVE-2022-24521).

The exploit will call the AddLogContainer function and the driver will create a new CLFS_CONTAINER_CONTEXT symbol that will be written to the patched cbSymbolZone

Now CLFS_CLIENT_CONTEXT and CLFS_CONTAINER_CONTEXT overlap (just like with exploit #1 – CVE-2022-24521).

The CClfsLogFcbPhysical::FlushMetadata function will restore cached values for the client and overwrite the CClfsContainer class pointer.

Overlap of new CLFS_CONTAINER_CONTEXT with existing CLFS_CLIENT_CONTEXT

As you can see, this exploit is almost identical to exploit #1 (CVE-2022-24521). The same goes for the rest of the exploit process.

Use the following link to read the next part:

• Part 5 – Windows CLFS and five exploits of ransomware operators (Exploit #4 – CVE-2023-23376)

Source:: Securelist