Ransomware Attackers Abuse Multiple Windows CLFS Driver Zero-Days

In the last year and a half, attackers have exploited at least five vulnerabilities — including four zero-days — in a sensitive, kernel-level Windows driver.

A series of reports published by Kaspersky's Securelist this week lays out not just a handful of bugs, but a larger, more systemic issue in the current implementation of the Windows Common Log File System (CLFS).

CLFS is a high-performance, general-purpose logging system available for user- or kernel-mode software clients. Its kernel access makes it eminently useful for hackers seeking low-level system privileges, and its performance-oriented design has left a series of security holes in its wake in recent years, which ransomware actors in particular have pounced on.

"Kernel drivers should be very careful when handling files, because if a vulnerability is discovered, attackers can exploit it and gain system privileges," Boris Larin, principal security researcher at Kaspersky's Global Research and Analysis Team, tells Dark Reading. Unfortunately, "design decisions in Windows CLFS have made it nearly impossible to securely parse these CLFS files, which led to the emergence of a huge number of similar vulnerabilities."

The Problem With Windows CLFS

Win32k-level zero-days aren't entirely uncommon, Larin conceded in his research. However, he wrote, "we had never seen so many CLFS driver exploits being used in active attacks before, and then suddenly there are so many of them captured in just one year. Is there something seriously wrong with the CLFS driver?"

Nothing in particular changed about the CLFS driver this year. Rather, attackers seem to have just now identified what was wrong with it this whole time: It leans too far left in that inescapable, eternal balance between performance and security.

"CLFS is perhaps way too 'optimized for performance,'" Larin wrote, detailing all of the various ways the driver prioritizes it over protection. "It would be better to have a reasonable file format instead of a dump of kernel structures written to a file. All the work with these kernel structures (with pointers) happens right there in the blocks read from disk. Because changes are made to the blocks and kernel structures stored there, and those changes need to be flushed to disk, the code parses the blocks over and over again every time it needs to access something."

He added, "All this parsing is done using relative offsets, which can point to any location within a block. If one of these offsets becomes corrupted in memory during execution, the consequences can be catastrophic. But perhaps worst of all, offsets in the BLF file on disk can be manipulated in such a way that different structures overlap, leading to unforeseen consequences."

The sum of all of these design choices is effective data and event logging, but also plenty of easily exploitable bugs. In 2023 alone there were CVE-2022-24521, CVE-2022-37969, CVE-2023-23376, CVE-2023-28252 — all high-severity, 7.8-rated on the CVSS scale — used as zero-days, as well as a fifth vulnerability that was patched before any associated malicious activity was observed in the wild. All of these were leveraged by attackers, Kaspersky found — including, for example, the Nokoyawa ransomware group's exploitation of CVE-2023-28252.

Without some sort of redesign, CLFS may well continue to offer escalation opportunities for hackers. To prepare for that, Larin suggests, "organizations should focus on implementing the best security practices: always install security updates on time, install security products on all endpoints, restrict access to their servers and pay huge attention to anti-virus detections coming from the servers, train employees so that they do not become victims of spear-phishing."