Friday, February 23, 2024

Micropatches Released for Microsoft Outlook Information Disclosure Vulnerability (CVE-2023-35636)

 


 

In December 2023, still-Supported Microsoft Outlook versions got an official patch for CVE-2023-35636, a vulnerability that allowed an attacker to coerce user's Outlook to authenticate to attacker's remote server, revealing user's NTLM hash in the process.

The vulnerability was discovered by Varonis researcher Dolev Taler, who wrote up a detailed article about it. In summary, a calendar file attached to an email can point to any URL, including a UNC path on a remote computer - and when the user tried to open such file, their computer would connect to the remote network share and, upon request, authenticate to it and reveal user's NTLM hash.

Microsoft's December patch changed Outlook's behavior such that whenever an ICS (calendar) file is opened from a specified location (instead of as an attachment), Outlook would display a security warning alerting the user about the potentially harmful content and asking their approval to continue.

While still-supported Microsoft Office versions have received the official vendor fix for this vulnerability, Office 2010 and 2013 - which we have security-adopted - are also vulnerable. In order to protect our users, we have created our own micropatch for this vulnerability.

Our patch is logically identical to Microsoft's.


Micropatch Availability

The micropatch was written for the following security-adopted versions of Office with all available updates installed:

  1. Microsoft Office 2013
  2. Microsoft Office 2010

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. If you're using Office 2010 or 2013, 0patch will make sure such vulnerabilities won't be exploited on your computers - and you won't even have to know or care about updating.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Dolev Taler for sharing their analysis, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

 

Monday, February 19, 2024

Micropacthes For "OverLog", Remote Denial of Service Vulnerability in Windows Event Log Service (CVE-2022-37981)

 


We recently delivered patches for the "LogCrusher" vulnerability that allows an attacker to remotely crash Windows Event Log service on some older Windows systems that we have security-adopted. Varonis researcher Dolev Taler, who found and reported that issue to Microsoft, also found another related issue they called "OverLog" (described in the same article).

OverLog allows a remote attacker to backup Internet Explorer logs to a chosen location on the remote computer, which can lead to all disk space being consumed.

OverLog was officially patched by Microsoft in October 2022 and assigned CVE-2022-37981.


Analysis

This one was a bit tougher to crack as the flaw is a missing privilege check in the server-side BackupEventLog function. As stated by Varonis and Microsoft in their official documentation, the BackupEventLog function allegedly checks if the calling user possesses the SE_BACKUP_NAME/SeBackupPrivilege privilege, and errors out if they don't. Varonis discovered that these checks in fact did not exist, so any user who could access an event source could call this function and create a horde of files on the target computer.

Although creating files is the intended functionality of the BackupEventLog function (it should allow privileged users the creation of log backups), it contains no failsafe for when the disk space is low. This can allow a remote user to effectively DOS any machine in the same domain that contains a writable location for their account. 

Microsoft patched this by restricting the Internet Explorer log interface access to deny non-admin users from opening it and performing such operations. The following images show the effect of their patch.


Old security descriptor, allowing everyone access to Internet Explorer logs


New security descriptor, only allowing local and domain administrators to access Internet Explorer logs


Our Micropatch

We wanted to patch this in a way that doesn't permanently affect our users' machines and allows the patch to be applied without any restarts. We decided to create a patch that would bring the behavior "into spec" set by Microsoft's documentation on the BackupEventLog function. Our patch is applied directly to this function and checks the calling user's token for the SE_BACKUP_NAME/SeBackupPrivilege privilege. If the user does not possess it, the function errors out and doesn't create the backup file. 

It is also worth noting that even empty logs with incorrect security descriptors are vulnerable to this attack. Our tests showed that a backup of an empty log creates a file with 68KB of data, which can still be used to DOS a machine given some time and patience.

While supported Windows versions got an official patch for OverLog in October 2022, several of our security-adopted versions haven't. We therefore made our own patch for these.

Our patch is logically identical to Microsoft's.


Micropatch Availability

Micropatches were written for: 
  1. Windows 10 v2004 - fully updated
  2. Windows 10 v1909 - fully updated
  3. Windows 10 v1809 - fully updated
  4. Windows 10 v1803 - fully updated
  5. Windows 7 - no ESU, ESU1, ESU2
  6. Windows Server 2008 R2 - no ESU, ESU1, ESU2
 
Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Dolev Taler of Varonis for sharing vulnerability details, which allowed us to reproduce it and create a micropatch. We also encourage all security researchers who want to see their vulnerabilities patched to share them with us or alert us about their publications.

The interesting parts of this post were written by our patching expert Blaz Satler ;)

Friday, February 9, 2024

Micropatches For Another Remote Windows Event Log Denial Of Service ("LogCrusher", no CVE)

 


While recently patching the (still 0day) "EventLogCrasher" vulnerability, we came across another similar vulnerability published in January 2023 by Dolev Taler, a security researcher at Varonis.

Dolev's article details two Windows Event Log-related vulnerabilities they had reported to Microsoft in May 2022: one ("LogCrusher") allowing a remote attacker to crash the Event Log service on any computer in a Windows domain, and the other ("OverLog") allowing for remotely filling up the disk on any domain computer by misusing a log backup function. Both vulnerabilities were targeting the Internet Explorer log that had permissions set such that any domain user could access it remotely.

Dolev's article states that OverLog was officially patched by Microsoft in October 2022 and assigned CVE-2022-37981, while the fate of LogCrusher remained unclear. Interestingly though, the title of Microsoft's advisory was "Windows Event Logging Service Denial of Service Vulnerability", which would match LogCrusher more than OverLog. In addition, it stated "the performance can be interrupted and/or reduced, but the attacker cannot fully deny service," which describes what happens with Event Log service when it crashes (see our EventLogCrasher post for details on that) and doesn't make much sense in the context of OverLog.

And what did the October 2022 patch do exactly? It simply changed the permissions on the Internet Explorer log such that non-administrative domain users could no longer access it. This may explain why, according to Dolev's article, Microsoft "closed “LogCrusher” [and] stated that they rated it as moderate severity because it required an administrator privilege [...] to exploit." Perhaps at that point, they had already decided to close the Internet Explorer log for non-admins, which would also protect the LogCrusher from non-admin exploitation.

That would make sense. But it wouldn't be exactly in line with Microsoft's documentation: the BackupEventLog capability, affected by OverLog, should only be available to users with SE_BACKUP_NAME privilege. Prior to the patch, all domain users had access (which is wrong), but after the patch, only Administrators have access (which is also not aligned with the documentation; non-admin users can be given SE_BACKUP_NAME privilege, too).

In any case, we were still interested in LogCrusher, so we did a quick analysis and learned the following:

  1. LogCrusher is very similar to EventLogCrasher in terms of exploitation: providing a NULL string to the remote Event Log service via RPC results in memory access violation which crashes the service. In addition, attacker's required access is the same in both cases: any domain user can remotely crash Event Log service on all domain computers. The impact of both vulnerabilities is therefore comparable.

  2. LogCrusher got patched with November 2022 Windows updates, one month after CVE-2022-37981. We "diffed" Windows updates and noticed a change to wevtsvc.dll that removed this vulnerability by adding a check for a NULL pointer as shown below. (Which is what our patch for EventLogCrasher does as well, and Microsoft's future patch for it surely will, too.)

  3. Microsoft assigned no CVE to LogCrusher in November 2022 updates, and extended no public acknowledgment to the reporting researcher for it. (See this list of all CVEs patched in November 2022 - nothing related to Event Log service.) We find it likely that Microsoft decided to cover both OverLog and LogCrusher with CVE-2022-37981, although these are two distinct vulnerabilities.

 

Let's look at Microsoft's November 2022 patch for LogCrusher in function PerformClearRequest (wevtsvc.dll): at some point in the code, the pointer to the "Backup file name" string, provided by the remote user, is loaded in register rcx. But the attacker was able to make this a NULL pointer, and before the patch, this pointer was blindly used in a subsequent mov r9, [rcx+8] instruction - which clearly caused an access violation if rcx was NULL. Microsoft's patch added a check for NULL and now puts a NULL into r9 if that happens. Function ClearChannelLogs, which then uses this value, is expecting the possibility of a NULL argument, so all is well.


 

Our Micropatch

While supported Windows versions got an official patch for LogCrusher in November 2022, several of our security-adopted versions haven't. We therefore made our own patch for these.

Our patch is logically identical to Microsoft's.


Micropatch Availability

Micropatches were written for: 
  1. Windows 10 v2004 - fully updated
  2. Windows 10 v1909 - fully updated
  3. Windows 10 v1809 - fully updated
  4. Windows 10 v1803 - fully updated
  5. Windows 7 - no ESU, ESU1, ESU2
  6. Windows Server 2008 R2 - no ESU, ESU1, ESU2
 
Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Dolev Taler of Varonis for sharing vulnerability details, which allowed us to reproduce it and create a micropatch. We also encourage all security researchers who want to see their vulnerabilities patched to share them with us or alert us about their publications.

Update 2/19/2024: Micropatches for OverLog are now also available.

Tuesday, February 6, 2024

Micropatches Released For Microsoft Windows XAML diagnostics API Elevation of Privilege (CVE-2023-36003)

 


December 2023 Windows Updates brought a patch for CVE-2023-36003, a privilege escalation vulnerability in Microsoft Windows XAML diagnostics API. The vulnerability allows a low-privileged Windows process to execute arbitrary code in a higher-privileged process running in the same user session, and is therefore useful for elevating from a non-admin to admin user.

Security researcher Michael Maltsev, who found this vulnerability and reported it to Microsoft in July 2023, wrote a detailed article and published a POC. These allowed us to reproduce the issue and create a micropatch for users of legacy Windows systems, which are no longer receiving security updates from Microsoft.


Our Micropatch

As Michael has already noted, there were two changes in the December version of Windows.UI.Xaml.dll, but only one seems to be related to this issue: namely the one that sets the security descriptor of the process's XAML diagnostics API interface to the current process's integrity level. Consequently, only processes that have at least the same integrity level as the target process will be allowed to utilize the affected functionality (and have arbitrary code executed in the target process).

Our micropatch is functionally identical to Microsoft's.

Let's see our micropatch in action. A local unprivileged user launches the POC, which periodically attempts to locate a privileged process to sent the offensive XAML diagnostics request to. Another process (Windows Magnifier) is then launched as administrator; the POC quickly finds it and requests that it loads a malicious DLL that then spawns a new command window - as Administrator. This demonstrates that arbitrary code could be executed in the privileged process. With 0patch enabled, the POC fails to attack the privileged process as our patch makes sure that only high-integrity processes could send XAML diagnostics requests to the high-integrity process (Magnifier).

Note that in a real attack, the attacker would actually be malware silently running in the background, waiting for the user to launch another process with higher privileges and then attacking that process.



Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows 11 v21H1 - fully updated
  2. Windows 10 v21H1 - fully updated
  3. Windows 10 v20H2 - fully updated
  4. Windows 10 v2004 - fully updated
  5. Windows 10 v1909 - fully updated
  6. Windows 10 v1809 - fully updated
  7. Windows 10 v1803 - fully updated
 
We were unable to reproduce the vulnerability on Windows Server 2012, Windows 7 and Server 2008 R2.
 
Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Michael Maltsev for sharing their analysis, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

 

Wednesday, January 31, 2024

The "EventLogCrasher" 0day For Remotely Disabling Windows Event Log, And a Free Micropatch For It

 


Update 2/14/2024: February Windows Updates did not patch this issue, so it remains a 0day. We did have to re-issue patches for three Windows versions because the updates changed  wevtsvc.dll and patches had to be ported to the new versions.

If you ever troubleshooted anything on Windows or investigated a suspicious event, you know that Windows store various types of events in Windows Event Log. An application crashed and you want to know more about it? Launch the Event Viewer and check the Application log. A service behaving strangely? See the System log. A user account got unexpectedly blocked? The Security log may reveal who or what blocked it.

All these events are getting stored to various logs through the Windows Event Log service. Unsurprisingly, this service's description says: "Stopping this service may compromise security and reliability of the system."

The Windows Event Log service performs many tasks. Not only is it responsible for writing events coming from various source to persistent file-based logs (residing in %SystemRoot%\System32\Winevt\Logs\), it also provides structured access to these stored events through applications like Event Viewer. Furthermore, this service also performs "event forwarding" if you want your events sent to a central log repository like Splunk or Sumo Logic, an intrusion detection system or a SIEM server.

Therefore, Windows Event Log service plays an important role in many organizations' intrusion detection and forensic capabilities. And by extension, their compliance check boxes.



The "EventLogCrasher" 0day

"That's a nice Event Log service you have here.
Would be a shame if something happened to it."

- every attacker


On January 23, 2024, security researcher Florian published details on a vulnerability that allows any authenticated user in a Windows environment (including in Windows domain) to crash Windows Event Log service either locally or on any remote computer (!)

As Florian explained, "according to MSRC, the bug does not meet the bar for servicing and therefore they allowed me to publish a proof of concept." In addition, "they claimed it was a duplicate of another bug from 2022 (coincidence?) that didn't meet the requirements for servicing."

Florian's POC (proof of concept) is remarkably simple: it makes a single call to RegisterEventSourceW, which retrieves a handle to an event log on the specified computer. (This function allows an application on computer A to obtain a handle to, say "Application" log on computer B, by sending a specific request to computer B's Windows Event Log service.) However, before the request is sent to the target computer, the POC modifies its in-memory structure to confuse the receiving Event Log service. It manages to confuse it so much to cause a null-pointer dereference and crash the service. The attack only takes a second and works reliably.

The good news at this point is that Windows Event Log service is set to automatically restart if unexpectedly stopped. The bad news is that it only gets restarted twice, then not anymore. So crashing the Event Log service three times makes it persistently stopped.

Now, what does this mean? With Windows Event Log service stopped, no events can be written to logs, forwarded to other locations, or read from logs using event logging functions. For all practical purposes, logging has gone dark. And indeed, any Application events, and many other event source's events that occur during the service downtime get irrecoverably lost.

Fortunately, Security and System events don't get lost - at least not yet. Someone was smart enough to expect the possibility of a temporarily unavailable Event Log service and implemented an event queue for these important events. If Windows can't report a Security or System event (perhaps some others too, we did not investigate), they put such event in some internal queue that then periodically retries to log all queued events until they finally succeed. We found no useful information about this queue's implementation or configuration; in fact, the only official mention of this queue we could find was Event 4612(S), described as "This event is generated when audit queues are filled and events must be discarded. This most commonly occurs when security events are being generated faster than they are being written to disk."

Our tests have shown that such queue in fact exists: if we left the Event Log service stopped and let some Security and System events occur, these events - of course - could not get logged. But after we started the Event Log service, they quickly got logged. Clearly something was storing them and making a real effort to get them logged. This is not really perfect news for the attacker: while security and system events they might trigger would not be logged while the Event Log service was down, they would get logged if the admin subsequently started the service.

Obviously, our next step was to see if the event queue survives a computer restart. Assuming that every Windows computer eventually gets restarted (at least still-supported ones on every second Tuesday), and that an admin noticing problems with logging may also decide to restart the computer, the question was: would queued events get lost?

And the answer was, they do not get lost. Apparently the event queue, presumably in memory, gets stored to disk when the system is gracefully shut down or restarted, and re-read upon startup. Once the Event Log service is running again, the queue is emptied into appropriate logs, with correct time stamps nonetheless.

What about a non-graceful system shutdown or restart? If the attacker manages to cause a blue screen on the computer where events are being stored in the event queue, these events will actually be irrecoverably lost. So there's an unexpected bonus value in ping of death vulnerabilities.

The final question was, can Windows firewall or access permissions stop this attack? After all, event-collecting apps such as Sumo Logic require enabling remote event log management-related firewall rules (disabled by default) and adding the remote user to the Event Log Readers group (empty by default). Nope, even though such apps do not work and connecting to a remote Event Log with Event Viewer does not work without such firewall and permissions adjustments, the attack at hand works by default. In fact, the attack takes place over a named pipe (i.e., SMB protocol), and unless you can afford to completely disable SMB - no network shares, no printers, no many other things - we don't believe you can configure Windows to prevent this attack from an attacker in your network.

So far we've discovered that a low-privileged attacker can crash the Event Log service both on the local machine and on any other Windows computer in the network they can authenticate to. In a Windows domain, this means all domain computers including domain controllers.

During the service downtime, any detection mechanisms ingesting Windows logs will be blind, allowing the attacker to take time for further attacks - password brute-forcing, exploiting remote services with unreliable exploits that often crash them, or running every attacker's favorite whoami - without being noticed.

Knowing that the "dark times" can soon end when some admin decides to restart machines or start the Event Log service, a clever attacker could simply run the POC in a never-ending loop to make sure that as soon as the Event Log service is back up, it gets crashed again. It would be really difficult for an admin to even know that it was an attacker crashing the service, as we all know computer things often stop working unexpectedly even without malicious assistance.

Keeping the service down long enough could, after some time, reach the point of saturating the event queue to its limit - at least we assume there's a limit or there wouldn't have been a need for Event 4612(S). Having reached this point, attacker's activities would from there on be irrecoverably un-logged.


The Flaw

As Florian noted in the POC document, "the crash occurs in wevtsvc!VerifyUnicodeString when an attacker sends a malformed UNICODE_STRING object to the ElfrRegisterEventSourceW method exposed by the RPC-based EventLog Remoting Protocol."

Indeed, the POC causes the wevtsvc!VerifyUnicodeString function inside the Event Log service to reference a null pointer, which causes an unhandled access violation. This function received a single argument, a pointer to a UNICODE_STRING structure, whereby for some reason, the Buffer element of the structure, which should point to the actual buffer, points to 0. The function doesn't expect that, at least not in the first part of the code, and crashes as shown on the image below. Also on the image, you can see that later in the code there is a check for the pointer being 0 - but too late.



Vulnerable function wevtsvc!VerifyUnicodeString

Our immediate goal was to provide a patch to our users as quickly as possible, so we haven't investigated further how the UNCODE_STRING structure was created with a null pointer. We plan to do that later, as it may reveal other similar flaws.

 

Our Micropatch

Our patch is simple: we just added a test for null pointer where such test was missing in the original code. The patch therefore consists of just two instructions: a compare operation and a conditional jump. The image below shows our patch (green code blocks) inserted in the original code (white blocks and the blue "Trampoline" block).



Our patch inserted in the original code


The following video shows both the POC and our patch in action. On the left side is the target computer, a fully updated Windows Server 2019 acting as domain controller. The firewall rules are in their default configuration, with all three Remote Event Log Management rules disabled, to show that the firewall does not stop the attack. The Event Log service is running and 0patch Agent is initially disabled.

On the right side is the attacker's Windows workstation, whereby the attacker is a regular Domain Users member. The attacker launches the POC against the domain controller and immediately crashes the Event Log service.

The same test is then repeated with 0patch Agent enabled, which applies our in-memory micropatch to the Event Log service process (of course without restarting the computer). This time, the POC fails to crash the service because our patch detects the presence of a null pointer and makes sure it does not cause a memory access violation.






Micropatch Availability

Since this is a "0day" vulnerability with no official vendor fix available, we are providing our micropatches for free until such fix becomes available.

Micropatches were written for: 

  1. Windows 11 v22H2, v23H2 - fully updated
  2. Windows 11 v21H2 - fully updated
  3. Windows 10 v22H2 - fully updated
  4. Windows 10 v21H2 - fully updated
  5. Windows 10 v21H1 - fully updated
  6. Windows 10 v20H2 - fully updated
  7. Windows 10 v2004 - fully updated
  8. Windows 10 v1909 - fully updated
  9. Windows 10 v1809 - fully updated
  10. Windows 10 v1803 - fully updated
  11. Windows 7 - no ESU, ESU1, ESU2, ESU3
  12. Windows Server 2022 - fully updated
  13. Windows Server 2019 - fully updated
  14. Windows Server 2016 - fully updated
  15. Windows Server 2012 - no ESU, ESU1
  16. Windows Server 2012 R2 - no ESU, ESU1
  17. Windows Server 2008 R2 - no ESU, ESU1, ESU2, ESU3, ESU4
 

These micropatches have already been distributed to all online 0patch Agents. If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Florian for sharing vulnerability details, which allowed us to reproduce it and create a micropatch. We also encourage all security researchers who want to see their vulnerabilities patched to privately share them with us.


Frequently Asked Questions

Q: Which Windows versions are affected?

A: Currently, ALL Windows versions are affected, from Windows 7 up to the latest Windows 11 and from Server 2008 R2 to Server 2022

Q: What level of access does the attacker need to exploit this?

A: The attacker needs network connectivity to the target computer, and be able to authenticate to said computer as any kind of  user (even a low-privileged one). Therefore, the attacker can always crash the Event Log service on the local machine, and can crash Event Log service on all Windows computers in the same Windows domain, including on domain controllers.

Q: Can this be exploited remotely by an attacker via the Internet?

A:No, the attacker must be able to send SMB requests to the target computer. Internet-facing Windows computers are unlikely to have SMB connectivity open to the Internet, and Windows computers in local networks even less so. The attacker must therefore already be in the local network.

Q: Is there any way to mitigate this attack with Windows configuration?

A: Short of denying SMB connectivity to the target computer (which would disable file and printer sharing, and various RPC-based mechanisms), we're not aware of any way to mitigate the attack.

Q: Doesn't Windows Firewall block this attack? After all, there are three pre-defined firewall rules for allowing Remote Event Log Management, which need to be manually enabled to allow remote event log management.

A: While these firewall rules indeed need to be enabled to allow remote event log management, this attack works regardless. Again, it works in the default Windows Firewall configuration.

Q: Does this vulnerability affect our IDS/SIEM?

A: It does if your IDS/SIEM is collecting Windows event logs. If the attacker crashes the Event Log service on a computer, that computer won't be able to forward events to such IDS/SIEM. Any alerts that may be triggered based on  Windows events will not be triggered during this time.

Q: Are events occurring during the Event Log service downtime irrecoverably lost?

A: Events generated by sources that don't use event queuing are irrecoverably lost - this includes Application logs (including events about Event Log service crashing). Security and System events are queued in memory and can get stored to the event log later when Event Log service becomes available again. Queued events can get irrecoverably lost in case the computer ungracefully shots down (e.g., due to a blue screen or power-off), or if the queue gets full. Unfortunately we don't know how many events the queue can hold.

Q: What should we do if we suspect someone crashed the Event Log service on one of our computers?

A: We recommend trying to salvage any potentially queued Security and System events by first disconnecting the computer from the network (if possible, to prevent further attacks) and manually starting the Windows Event Log service. As the service remains running, it will collect queued log events and store them to files so that even an ungraceful shutdown will not delete them. You can  observe these events coming in with Event Viewer. When queued events are collected, reconnect the computer to the network to allow IDS/SIEM to collect them as well. If the Event Log service keeps getting stopped/crashed when you start it, it may be under constant attack so you will have to disconnect the computer from the network to keep it running. In this case, you can also inspect network traffic (incoming SMB connections to \pipe\eventlog to see where the attack is coming from.

Q: What do we have to do to use your micropatch for this vulnerability?

A: Create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com. Our micropatch will be downloaded and applied automatically. For information about central management, multi-user role-based support, and other enterprise features, please contact sales@0patch.com

Q: If we use your micropatch, what will happen if/when Microsoft provides their own patch for this issue?

A: 0patch co-exists nicely with official vendor updates because our patches are only applied in memory without changing original executable files. When Microsoft provides their own patch, they will replace various DLLs and EXEs, including the one in which our micropatch is getting applied. This will automatically ensure that our micropatch stops getting applied. In other words, you won't have to do anything in addition to installing Windows Updates to stop using our micropatch and start using Microsoft's patch.

Q: Is 0patch providing any other security patches?

A: Of course! We provide many "legacy Windows" patches and "0day patches" like this one. The former help our users keep unsupported Windows machines from Windows 7 to Windows 11 and from Server 2008 R2 to Server 2012 running securely, and the latter help in cases like this where the vendor doesn't have an official patch available yet, or has decided not to provide patches anymore (e.g. for NTLM hash disclosure issues). To learn more about 0patch, please visit our Help Center or contact sales@0patch.com for a trial or demo.

Friday, November 24, 2023

Free Micropatches For Microsoft Access Forced Authentication Through Firewall (0day)


 

Update 2/14/2024: Either January 30 or February 1 Office update brought a fix for this issue: now, Access warns the user for any ODBC connection to SQL Server. Our patch only shows a warning when such connection is made on non-standard ports 80 or 443, because these would carry user's NTLM hash through a company firewall, so Microsoft's patch might display more - in our view unnecessary - warnings. So what CVE ID did this issue get? Well, it doesn't seem to have gotten one: neither January 30 nor February 1 Office update mention any changes in Access, and February Windows Updates also have no suitable match. So far, this issue seems to have been fixed silently. With official patch available, our patches for this issue are no longer FREE and require a PRO or Enterprise license. Our patch was available 66 days before Microsoft's.

On November 9, 2023, Check Point Research published an article about an "information disclosure" / "forced authentication" vulnerability in Microsoft Access that allows an attacker to obtain the victim's NTLM hash by having them open a Microsoft Office document (docx, rtf, accdb, etc.) with an embedded Access database.

Many similar vulnerabilities have been disclosed in the last few years, all having a common theme of forcing a Windows process to authenticate to attacker's server and thereby disclose credentials of Windows user or a privileged service account to the attacker. Microsoft has patched some of them, but decided not to patch others: DFSCoerce, PrinterBug/SpoolSample and PetitPotam still don't have an official patch today and our micropatches remain the only patches available for these (our customers who can't stop using NTLM really appreciate them). RemotePotato0 was initially experiencing a similar fate but was then silently fixed 9 months after publication. ShadowCoerce was just as silently fixed 6 months after publication. On the other hand, a WordPad vulnerability from this same category, leaking user's NTLM hash to a web share upon opening an RTF document, was openly patched by Microsoft just last month.

It's hard to tell how Microsoft decides whether to patch a forced authentication vulnerability or not - and this one in Microsoft Access just adds to the confusion. Let's see how.


The Vulnerability

As Haifei Li, security researcher at Check Point, describes in their detailed article, a remote SQL Server database link can be inserted to a Microsoft Access database with "Windows NT authentication", which will force such authentication - and leak user's NTLM hash - every time the table with such link is refreshed in Access. So far, this would be a "classic" forced authentication issue, only different from most others in the fact that the connection isn't established on "classic" SMB and RPC ports but on SQL Server's port 1433. Which is expected to be filtered for outbound traffic from internal network towards the Internet.

But as Haifei noted, the database link can override the default port and specify an arbitrary port, including 80 or 443 - which are both typically allowed by firewalls for outbound connections so users in the network can browse the Internet. This makes things more interesting, and impact-wise almost comparable to the previously mentioned WordPad issue. Why "almost"? Because it's not enough just to open a Word document with such Access database embedded: to force a refresh of the database link, the user has to "open" the linked Access table by clicking on it.

To overcome this limitation, Haifei found that the AutoExec macro can be used to automatically open the table and force a refresh. But hey, macros have already been blocked for documents coming from the Internet, so how would this even work?

Well, we first need to understand something Haifei calls "simple Access macros". Admittedly, we did not know that Access macros come in two flavors, and we couldn't find any relevant results on this phrase on the Internet, but that's probably because Haifei usually knows more about the targeted product than the Internet does.

"Simple Access macros" are limited macros that only allow you to perform a set of predefined harmless actions, in contrast to "full-fledged regular macros" (sorry, another unofficial term) that are actual VBScript code capable of doing pretty much anything on the computer, including downloading and executing ransomware. It turned out that simple Access macros are blocked neither by the Access macro policy nor by the Protected View. In addition, if you name such macro AutoExec, it will get executed upon opening the Access database.

Putting two and two together, Haifei created an Access database with a remote SQL Server database link, Windows NT authentication, and an AutoExec macro that opened the linked table - and embedded that in a Word document because users prefer opening Word documents to Access databases. Now, there is no "almost" there anymore: this issue is impact-wise identical to the WordPad issue.

Checkpoint reported this vulnerability to Microsoft in January 2023 and were in July still "unable to obtain conclusive answer because the issue is considered as “low/none severity”, according to the MSRC reply." They did notice, however, that at some point during this period, Access started showing this security dialog when opening their PoC file:

 


So, was this issue silently fixed too? Nope, at least not successfully: while the above dialog is certainly triggered by the presence of the AutoExec macro (it shows even when AutoExec is the only active content), closing this informational dialog either by pressing OK or clicking the X still leads to the AutoExec macro being executed and user's credentials being sent to attacker's server. The only way to block the exploit when this dialog is displayed is to forcefully kill the msaccess.exe process, e.g. using Windows Task Manager.

In summary, we have active content that is detected, user informed about it being blocked, and then still getting executed unless the user kills Access with Task Manager. Not ideal.


Our Analysis

We tried to make sense of all this and here's what we think happened.

We think Microsoft never intended to patch the reported issue due to its "low/none severity" assessment, which we think was wrong because its impact is comparable to the WordPad issue they had patched last month with severity "important".

We think the security dialog that started appearing in Access is part of Microsoft's slow and painful process of gradually restricting malicious macros while not getting hammered by customers whose Office documents they might break along the way. (See here and here for examples.) Microsoft is doing the right but difficult thing here, addressing a very popular attack avenue, and they deserve huge credit for that.

We think that the current macro-blocking logic in Access is flawed: it clearly detects the AutoExec "simple" macro, it tells the user that macros are blocked - but then doesn't block it. Microsoft needs to fix this, but it's not hard to imagine thousands of enterprises using "simple" macros on a daily basis, and thousands of angry calls to the Office PM the next day if they actually start getting blocked. Still, this needs to be fixed this because it's confusing and useless: either don't trip on simple macros, or trip on them and block them.

We expect Microsoft will do something about this all; they will probably fix the macro logic and the dialog, but will they revise the severity of the issue reported by CheckPoint and fix it too?

Maybe they will, maybe they won't - but we did.


Our Micropatch

We pondered on how to address this: shall we fix Microsoft's macro logic so that simple macros will indeed be blocked when the dialog says they would be? If we did, and broke "simple" macros for our users, they would probably blame Microsoft and make angry calls to the surprised Office PM. We don't presume we understand the complex dynamics between a huge software vendor who decades ago made a convenient powerful feature that boosted product usability but has since become a major security risk, and organizations that have this feature embedded in critical processes but can at the same time be seriously harmed because of it.

So we decided on a different approach: we would block database connections from Access to SQL Server on ports 80 and 443. While it is not impossible for some real, legitimate SQL Server to be accessible on port 80/443 and some real, legitimate Access database being linked to it, we think it's realy unlikely. Note that such patch would not block SQL Server connections on port 80/443 from any other client, just Microsoft Access.

"How about other database servers that could be linked to remotely," you ask, "some of them may also support Windows NT authentication and be accessible on arbitrary port?"

Well, the main risk is posed by the ones supported on Windows by default, without a non-default ODBC driver having to be installed on user's computer. And SQL Server is the only one that fits the bill.

This is our micropatch:




MODULE_PATH "..\Affected_Modules\acecore.dll_16.0.16924.20054_64bit_u202311_Office2016_2019_2021_365\acecore.dll"
PATCH_ID 1569
PATCH_FORMAT_VER 2
VULN_ID 7803
PLATFORM win64
       
patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x1955a0
 N_ORIGINALBYTES 5
 JUMPOVERBYTES 0
 PIT msvcrt.dll!wcsstr,msvcrt.dll!_wtoi,acecore.dll!0x195637,shlwapi.dll!StrStrIW

 code_start

  push r15                 ;save the original r15 value
  sub rsp, 0x28            ;create shadowspace
  lea r15, [rbp+0x60]      ;move the connection string pointer to r15
  mov rcx, r15             ;move the connection string pointer to the first argument
  call STR1                ;get the string "SQL Server" to the stack
  db __utf16__('SQL Server'),0,0
 STR1:
  pop rdx                  ;pop the "SQL Server" string pointer from the stack
  call PIT_StrStrIW        ;call case insensetive string search
  cmp rax, 0x0             ;check if SQL Server substring exists
  je SKIP                  ;if not skip the patch
       
 LOOP:                     ;the port searching loop
  mov rcx, r15             ;move the connection string pointer to the first argument
  call STR2                ;load the "," character onto stack
  db __utf16__(','),0,0
 STR2:
  pop rdx                  ;pop the "," character to rdx
  call PIT_wcsstr          ;call wcsstr to search for "," and if found return the addres to rax
  cmp rax, 0x0             ;check if "," was found
  je SKIP                  ;if no matches, we're done
  add rax, 0x2             ;if match was found increment the pointer to string by 1 char
  mov r15, rax             ;move the incremented pointer to r15 for next iteration
  mov rcx, rax             ;move the incremented pointer to the first arg
  call PIT__wtoi           ;convert the string after the "," to a number
  cmp rax, 0x50            ;check if that number is 80 (decimal)
  je BLOCK                 ;if it is, block the connection
  cmp rax, 0x1bb           ;check if that number is 443 (decimal)
  je BLOCK                 ;if it is, block the connection
       
  jmp LOOP                 ;if nothing was found repeat the search
       
 BLOCK:                    ;block the connection
  call PIT_ExploitBlocked  ;popup the Exploit Blocked notification
  add rsp, 0x28            ;clear shadowspace
  pop r15                  ;restore the original r15 value
  jmp PIT_0x195637         ;jump to the error block
       
 SKIP:                     ;skip the patch and continue normal execution
  add rsp, 0x28            ;clear shadowspace
  pop r15                  ;restore the original r15 value

 code_end
    
patchlet_end

 

Let's see our micropatch in action. In the video below we can see attacker's computer on the left and user's computer on the right. The user is running fully updated Office 365. On attacker's computer we can see Wireshark, a network monitoring tool, that is filtered to only show communication with the IP address of user's computer.

First, with 0patch disabled, the user opens a malicious Access file in Microsoft Access, and as described above, a security dialog is displayed informing them that active content in the file has been blocked (we know it wasn't). As the user closes this dialog, the linked database connection is established with attacker's computer on port 80 due to the AutoExec macro being executed.

Next, with 0patch enabled, the user again opens attacker's Access file. This time, as the "blocked active content" security dialog is closed, our patch detects that a connection to a SQL Server is attempted on port 80 and blocks it. It also records an "Exploit blocked" event and shows an alert to the user.



Micropatch Availability

Micropatches were written for the following versions of Microsoft Office with all available Updates installed:

  1. Office 2010*
  2. Office 2013*
  3. Office 2016
  4. Office 2019
  5. Office 2021
  6. Office 365
     
    (* Office 2010 and 2013 were security-adopted by 0patch and are receiving critical security patches from us after their support by Microsoft was terminated.)

    As always, since this is a 0day, our micropatches are part of the 0patch FREE plan, and will remain free until Microsoft has fixed this issue with their official patch.
     
    These micropatches have already been distributed to, and applied on, all online 0patch Agents (unless Enterprise group settings prevented that). 

    Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. If you're using Windows or Office that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers. (By the way, still using Windows Server 2012? 0patch has you covered!)

    If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

    We would like to thank Haifei Li with Check Point for sharing the details of this vulnerability, which made it possible for us to create a micropatch for our users.

    To learn more about 0patch, please visit our Help Center.

     

    Thursday, November 16, 2023

    We Patched CVE-2023-28244 Before It Was Cool

    How Our Patch For CVE-2022-33647 Fixed CVE-2023-28244 Five Months In Advance

    By Blaz Satler of 0patch Team


    The Initial Vulnerability - CVE-2022-33647

    In September 2022, Microsoft released patches for CVE-2022-33647, a Kerberos vulnerability that allows a MITM (Man-In-The-Middle) attacker to hijack a user's Kerberos ticket and achieve domain privilege escalation. James Forshaw of Google Project Zero was attributed with the discovery of this issue, and shortly after the issue was fixed also published a writeup on the official Project Zero bug tracking page. James also forked a branch of GhostPacks Rubeus tool and added a sample POC (Proof-of-Concept) code that demonstrated this issue in action and allowed users to check if their KDC (Key Distribution Center) was affected.

    Testing revealed that this issue affected all Kerberos versions that have not configured any restrictions for the use of old cryptographic algorithms, specifically RC4-MD4. This algorithm is particularly dangerous as it contains multiple known vulnerabilities, such as using only the first 8 key bytes for encryption and only 40 bits of randomness in session keys. Such security deficiencies could make you wonder why the algorithm is even allowed to be used in Kerberos. Nevertheless, Kerberos allowed its use by default and also didn't seem to mind being downgraded from a stronger protocol to RC4-MD4 mid-session, which was why the POC worked.

     

    Microsoft's Patch

    We analyzed Microsoft's patches for CVE-2022-33647 and the exploit's execution flow. All signs seemed to point to a patch in kdcsvc.dll, specifically in the KerbInitPreferredCryptList function. This function executes when the KDC service starts which is with the start of lsass.exe. Its job is to initialize the PrefferedCryptList (yes, we know, it's a typo in the code too) variable and two other lists with cryptographic algorithms that the KDC will prefer. Microsoft patched this by not including RC4-MD4 and RC4_HMAC_OLD to these lists. At the time this fix seemed sufficient with the only apparent flaw being that it would only come into effect after the system that applied the patch had been restarted. 

     

    Our Micropatch

    Our own patch, in contrast, needed to be able to protect the system from the moment that the user decided to apply it, so we needed to find a better way of blocking these protocols. During the analysis, we stumbled upon the KerbGetEncTypeBitmask function which supplies bit masks of all supported encryption algorithms to other parts of the code. It has the ability to refuse unknown encryption types, so we decided to take a closer look. Upon further investigation, we found that it was invoked on every request to the KDC, so it made for a perfect candidate for patching this exploit in real time (without a reboot). Our patch was injected at the start of this function and checked if the passed cryptographic algorithm was one of the two that Microsoft had blocked; if it was, we simply executed the "return 0" command which returns KDC_ERR_ETYPE_NOTSUPP ("type not supported"). This had the effect of completely blocking any use of RC4_MD4 and RC4_HMAC_OLD, and our patches were released in October 2022.


    The New Vulnerability - CVE-2023-28244

    6 months later, Microsoft released a fix for another similar vulnerability CVE-2023-28244, acknowledging John Askew with Terrapin Labs as the discoverer. Subsequently John also published a POC on GitHub which seemed eerily similar to James' POC for CVE-2022-33647. Our tests revealed that this new exploit attacked the same RC4-MD4 encryption algorithm but with a slight modification to the AS-REQ packet. This new exploit included a timestamp encrypted with the user's password inside the AS-REQ, which changed the execution flow in kdcsvc.dll.

    This modification caused the exploit to bypass Microsoft's patch that had caught its predecessor. Microsoft's patch only changed how a few crypt lists were initialized, but left some relevant global variables like KdcGlobalSupportedEnctypes unchanged. Although there were other checks in place for unsupported encryption types that were executed later, none of them used the patched PrefferedCryptList variable that was stripped of RC4-MD4 and RC4_HMAC_OLD. This again resulted in RC4-MD4 being used for encrypting the session and tickets.

     


     

    A Pretty Decent Patch

    The micropatch we had released for CVE-2022-33647, on the other hand, proved to be remarkably robust, effectively neutralizing the new, modified exploit. It was particularly gratifying to find that Microsoft's fix for the new vulnerability targeted the same function as our original patch (KerbGetEncTypeBitmask), and closely resembled our own patch for this vulnerability: it removed the validation for RC4-MD4 and RC4_HMAC_OLD encryption algorithms within the KerbGetEncTypeBitmask function, returning a '0' as the function's result when these algorithms were passed to it. This behavior is logically equivalent to our patch.

    Effectively, our patch for CVE-2022-33647 fixed CVE-2023-28244 entire 157 days before it was patched by Microsoft


    Looking for a way to keep using Windows Server 2012 securely, and don't want to purchase expensive Extended Security Updates? Want to protect your legacy Windows 7, Server 2008 R2 machines and Microsoft Office installations with actual security patches that don't even need a computer restart and can get applied or un-applied in seconds? Not objecting to having occasional vulnerabilities fixed before those running still-supported Windows versions? 0patch has your back!

    Learn more about 0patch on our web site, in our Help Center, or contact us at sales@0patch.com for a free trial or demo.