CVE-2022-37981 _ The Logging Dead

You don't have to use Internet Explorer for its legacy to have left you vulnerable to LogCrusher and OverLog, a pair of Windows vulnerabilities discovered by the Varonis Threat Labs team.

Microsoft ended support for Internet Explorer on June 15, 2022. However, IE’s deep integration into the Windows ecosystem impacts the security and stability of current Windows operating systems.

One feature of the IE and Windows integration is an Internet Explorer-specific Event Log that is present on all current Windows operating systems. This IE-specific Event Log has a distinct set of permissions that enable two exploits against Windows systems:

LogCrusher, which allowed any domain user to remotely crash the Event Log application of any Windows machine on the domain.

OverLog, which causes a remote denial-of-service (DoS) attack by filling the hard drive space of any Windows machine on the domain. (CVE-2022-37981)

In this article, we'll explain how both exploits work and detail their respective attack flows. As part of our research, we promptly disclosed these vulnerabilities to Microsoft, which released a partial patch on October 11, 2022. We urge everyone to patch their systems.

These exploits (LogCrusher and OverLog) both use functions of the Microsoft Event Log Remoting Protocol (MS-EVEN), which allows for remote manipulation of a machine's event logs.

From Microsoft:

The Event Log Remoting Protocol is an RPC-based protocol that exposes remote procedure call (RPC) methods for reading events in both live event logs and backup event logs on remote computers.

OpenEventLogW is a Windows API function that allows a user to open a handle for a specific event log on a local or remote machine.

This function is useful for services that can use it to read, write, and clear event logs for remote machines without the need to connect manually to the machines themselves.

The function takes two parameters:

lpUNCServerName — The remote machine name, or NULL for a local connection

lpSourceName — The specific Event Log to get the handle to

By default, low-privilege, non-administrative users cannot get a handle for event logs of other machines. The one exception to this is the legacy “Internet Explorer” log — which exists in every Windows version and has its own security descriptor that overrides the default permissions.

The Internet Explorer Event Log security descriptor can be found under the registry hive: HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Internet Explorer

Parsing the security descriptor string: CustomSD = O:BAG:SYD:(A;;0x07;;;WD)S:(ML;;0x1;;;LW)

Can you see it? The DiscretionaryACL specifies it!

This ACL allows any user to read and write logs to it. An attacker can get a log handle to every Windows machine in the domain from any domain user.

This sets the stage for our two exploits.

ElfClearELFW is an MS-EVEN function that allows administrators to remotely clear and backup event logs.

The function takes two parameters:

LogHandle — Log handle that has an already opened OpenEventLog function.

BackupFileName — a pointer to a Unicode string struct that holds the location for backing up the event log before it is cleared.

Unfortunately, the ElfClearELFW function has an improper input validation bug. It expects that the BackupFileName structure will be initialized with a zero value, but when the pointer to the structure is NULL, the process crashes.

Combining these two functions, it's easy to understand the LogCrusher attack flow. Call the OpenEventLog function for the Internet Explorer Event Log on the victim machine:

Call the ElfClearELFW function with the handle that was returned, and NULL as the BackupFileName parameter:

That's it! Just like that, we crashed the Event Log on the victim's machine.

By default, the Event Log service will try to restart itself two more times. On the third time, it will stay down for 24 hours.

A demonstration of LogCrusher repeatedly crashing the Event Log service until it stops restarting.

The impact lies in the fact that many security controls rely on the normal operation of the Event Log service.

PowerShell verification of the Event Log stopped status.

Another interesting finding was that the bug in ElfClearELFW function was discovered two years ago, and reported to Microsoft by a researcher that goes by the nickname “limbenjamin.”

At the time, it was not possible to exploit the bug from a non-admin normal user account (and Internet Explorer), so the impact was unclear and Microsoft opted not to patch it.

With this attack we were able to use the same methodology and Internet Explorer Event Log handle together with another vulnerability in BackupEventLogW function to cause a permanent DoS for every Windows machine.

According to Microsoft, the BackupEventLogW function:

The bug here is even more simple, and although it says in the documentation that the backup user needs to have SE_BACKUP_NAME privilege, the code does not validate it — so every user can backup files to a remote machine if they have write access to a folder on that machine.

Microsoft has opted not to fully fix the LogCrusher vulnerability on Windows 10 (more recent operating systems are unaffected).

As of Microsoft's Oct. 11, 2022 Patch Tuesday update, the default permissions setting that had allowed non-administrative users access to the Internet Explorer Event Log on remote machines has been restricted to local administrators, greatly reducing the potential for harm.

While this address this particular set of Internet Explorer Event Log exploits, there remains potential for other user-accessible application Event Logs to be similarly leveraged for attacks.

We recommend that all potentially vulnerable systems apply the Microsoft-provided patch and monitor any suspicious activity.

The vulnerabilities report timeline that contains the relevant correspondence: