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.

Enter MS-EVEN

Microsoft Event Log Remoting Protocol

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.

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.

Internet Explorer log handle

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.

LogCrusher

An ElfClearELFW logic bug

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.

Attack flow

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:

Handle = OpenEventLog(<Victim Machine>, "internet explorer")

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

ElfClearELFW(Handle, NULL)

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.

That's cool. Where's the impact?

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

1. Without logs, security controls are blind.
2. Security control products, in some cases, attach themselves to the service! This means that when it crashes for good, the product will also crash and burn alongside it.
3. This in turn could allow an attacker to use any type of usually detected exploit or attack with impunity as many alerts won't trigger.

PowerShell verification of the Event Log stopped status.

Déjà vu?

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.

OverLog

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:

Saves the specified event log to a backup file. The function does not clear the event log. ...The BackupEventLog function fails with the ERROR_PRIVILEGE_NOT_HELD error if the user does not have the SE_BACKUP_NAME privilege.

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.

Attack flow

1. Get a handle to the Internet Explorer Event Log on the victim machine (same as before).
2. Write some arbitrary logs to the Event Log (random strings; different lengths).
3. Backup the log to a writeable folder on the machine (example: “c:\windows\tasks”) that every domain user has write permission to by default.
4. Repeat the backup process until the hard drive is full and the computer ceases operation.
5. Victim machine is unable to write “pagefile” (virtual memory), rendering it unusable.

Microsoft response and recommendations

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.

Timeline

The vulnerabilities report timeline that contains the relevant correspondence:

• 5/24/2022 - “OverLog” and “LogCrusher” vulnerabilities were submitted to Microsoft Security Response Center (MSRC).
• 6/2/2022 MSRC confirmed “OverLog” and its status was changed to “develop”
• 7/25/2022 MSRC closed “LogCrusher”. They stated that they rated it as moderate severity because it required an administrator privilege and manual interaction to exploit.
• 7/26/2022 We sent an email back to MSRC, specifically mentioning that the initial report says the vulnerability can be exploited from domain user in default Windows configuration. We did not receive a response back from MSRC.
• 10/11/2022 Patch Tuesday — the OverLog vulnerability was assigned CVE-2022-37981 and patched.
• 10/25/2022 Blog post published.