If you're running
Windows 10 v21H1 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 v21H1 with 0patch will also
receive our micropatches for "0day" vulnerabilities in
various products.
In order to have our micropatches applied, Windows 10 v21H1 will have to have December 2022 Windows Updates (the last official updates for this version) installed.
We welcome all interested organizations to contact sales@0patch.com
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 sales@0patch.com.
To learn more about 0patch, please visit our Help Center.
With November 2022 Windows Updates, Microsoft fixed a vulnerability in Internet Explorer's JScript9 engine that was found being exploited by North Korean government-backed actors known as APT37. The vulnerability is of a "type confusion" sort, which means that malicious JavaScript code can confuse the JavaScript engine into thinking that a certain object is of one type (in our case, Int32Array) while it's actually of another type (in our case, Object) - and that quickly leads to reading or writing memory addresses that were not supposed to be available to said code. From that point on, arbitrary code execution can be achieved.
Microsoft assigned this issue CVE-2022-41128 and fixed it by removing a code branch that was dependent on a call to function ShouldExpectConventionalArrayIndexValue; in the patched code, this function call is skipped so the code always continues down the same path.
Admittedly, we did not investigate what really went wrong with this vulnerable code and just logically replicated Microsoft's patch as we trust they know what they're doing. Our
micropatch thus only has one instruction that jumps over the now-excluded code:
code_start jmp PIT_0x21581 ; jump over the excluded code block code_end patchlet_end
The micropatch was written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909
Windows 10 v1809
Windows 10 v1803
Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank Benoît Sevens and Clément Lecigne of Google's Threat Analysis Group (TAG) for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
September 2022 Windows Updates brought a fix for a remotely exploitable vulnerability in the Enterprise App Management Service, discovered by security researcher Ceri Coburn of Pen Test Partners. On October 13, they published a blog post describing the vulnerability in detail, and a proof-of-concept.
The Enterprise App Management Service allows Windows admins to centrally perform various installation and application provisioning-related actions on multiple Windows computers in the network. Due to lax permissions, a non-admin attacker could perform the same actions, potentially leading to a malicious application being installed and launched on the target computer.
Microsoft's patch added code for checking whether the requestor has administrative privileges on the computer, and our patches do logically the same.
Our micropatches were written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909
Windows 10 v1809
Windows 10 v1803
Micropatches have already been distributed to all
affected online computers running 0patch Agent with PRO
or Enterprise license. To obtain the relevant micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank Ceri Coburn and Pen Test Partners for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
Update 12/13/2022: Microsoft patched this issue with December 2022 Windows Updates and assigned it CVE-2022-44698. Our patches for this issue were freely available 46 days before the original vendor patch, and now require Pro or Enterprise license.
Update 3/15/2023: The patch Microsoft created for CVE-2022-44698 in December turned out to be flawed and its bypass was found to be exploited in a Magniber ransomware campaign to trick users into launching a malicious MSI file without any security warnings. Microsoft assigned this bypass a separate CVE ID CVE-2023-24880 and patched it with March 2023 updates. Their patch is in the same function as our own patch from last October, and like our patch, makes sure the user is shown the typical Mark-of-the-Web warning for files with a malformed signature but while we decided to show users a typical Mark-of-the-Web security warning for files with a malformed signature, Microsoft decided to silently error out by doing exactly what we considered doing - but decided not to as it would confuse users (see below). As our original patch from October is not affected by this bypass (the user still gets a security warning), we don't need to create an additional patch for CVE-2023-24880. We thank Benoît Sevens of Google TAG for sharing their analysis with the community. As far as this bypass goes, our patches for it were available 137 days before the original vendor patch; 0patch users on end-of-support Windows systems were protected against this since last October.
Nine days ago we issued micropatches for a vulnerability that allows attackers to bypass the warning Windows normally present to users when they try to open a document or executable obtained from an untrusted source (Internet, email, USB key, network drive). That vulnerability, affecting all supported and many legacy Windows versions, still has no official patch from Microsoft so our (free!) patches are the only actual patches in existence as of this writing.
On the very same day we issued these micropatches, Will Dormann - who researched said vulnerability - replied to a tweet by another security researcher, Patrick Schläpfer. Patrick works at HP Wolf Security where they analyzed the Magniber Ransomware and wrote a detailed analysis of its working. Will asked Patrick about the ZIP files used in the malware campaign to see if they were exploiting the same vulnerability or employing some other trick to bypass the "Mark of the Web".
Patrick responded that malicious files extracted from the attacker's ZIP files did have the Mark of the Web but still executed without a security warning. Remember that on Windows 10 and Windows 11, opening any potentially harmful file triggers a SmartScreen inspection of said file, whereby SmartScreen determines if the file is clear to get launched or the user should be warned about it (see image below).
SmartScreen determined that this file could be harmful and warned the user. The user needs to click "More Info" and then press "Run" if they really want to open the file.
When deciding whether to trust the file or not, the Mark of the Web plays an important role: files with this mark are considered unconditionally untrusted as they originated from an untrusted source. So why did these malicious Magniber files not trigger the SmartScreen warning?
Patrick remarked that Authenticode signatures on extracted malicious files must have been causing this behavior because with signatures removed, the warning would (correctly) appear.
Will then noticed that these signatures were not valid at all and should not have been trusted by Windows. In fact, they were malformed such that Windows could not even properly parse them. This, for some peculiar reason, led to Windows trusting them - and letting malicious executables execute without a warning.
And so a new 0day - already exploited in the wild - was revealed.
This information was sufficient for us to start our patch development process. We reproduced the issue using a sample .JS file with various malformed signatures until we reached the flawed execution path that bypassed the SmartScreen warning. We then searched for the cause, and found... well... it's complicated.
The logic behind determining whether to show a security warning to the user, and whether to show the SmartScreen warning or the old "Open File - Security Warning" dialog, is complex and distributed among various executable modules. An application attempting to open a file on user's behalf partly inspects the file itself to decide whether to send it to further inspection by SmartScreen, and if so, sends a DCOM request to SmartScreen.exe, which is another process constantly running on Windows. SmartScreen.exe then does its own inspection and, if networking is available, asks Microsoft's servers for an opinion, displays the warning if needed, then delivers the final verdict back to the requesting process in form of an error code and the information on user's decision ("Run" or "Don't run").
What looked like the most serious flaw to us was the fact that when SmartScreen.exe returns an error, this would be considered identical to the user having pressed "Run." A strange decision, security-wise.
The malformed signature discovered by Patrick and Will caused SmartScreen.exe to throw an exception when the signature could not be parsed, resulting in SmartScreen returning an error. Which we now know means "Run."
Mystery solved. Now let's patch it.
To understand our patch, we need to take a closer look at function DoSafeOpenPromptForShellExec in shdocvw.dll as this is the function that performs the flawed logic. The image below shows the relevant part of its code: register edi is initialized to 0 and is reserved for holding the final decision on whether to run/open the file or not. The function sends a request to SmartScreen and waits for its response, then based on the error code returned takes the left or the right branch. The right branch, executed when there was no error, stores the user's decision to edi; the left branch, executed when SmartScreen returned an error, leaves edi on 0 - which explains why an error equals the user's decision to run/open the file.
The simplest way to fix this would be to simply initialize edi to a value that would mean "Don't run", whereby any error in SmartScreen would lead to the file not being run/opened. However, this approach might confuse users as such files would just silently not run/open without any feedback to the user.
[Update 3/15/2023: Microsoft's patch for CVE-2023-24880, however, does exactly this and silently errors out, leaving the user confused - but secure.]
We therefore decided on a different approach: in the same function, there is a code block that displays the old "Open File - Security Warning" dialog to the user, and in case of a SmartScreen error, we redirect execution to that block. This way, when SmartScreen errors out, the user is presented with the old security warning and can still select whether to run/open the file or not.
While our patch fixes the most obvious flaw, its utility depends on the application opening the file using function DoSafeOpenPromptForShellExec in shdocvw.dll and not some other mechanism. We're not aware of another such mechanism in Windows, but it could technically exist. Our tests with opening files directly from Windows Explorer, from ZIP files opened with Windows Explorer, and directly from most major web browsers and email clients were successful. Except with Google Chrome, which we've long ago decided not to patch because its sandboxing model is causing us problems with injection. And even if we did patch Chrome, there is another weird logic in shdocvw.dll that gets executed in Chrome due to sandboxing which for some reason prevents SmartScreen from returning an error while still not showing the warning. We did not investigate the latter any further.
We did, however, investigate a possibility of patching SmartScreen.exe, which could potentially cover all cases, but that would have to be a much more complex patch. In addition, the SmartScreen code can throw an exception in numerous places in addition to the one triggered by a malformed signature, and each of these could lead to the same warning bypass.
Needless to say, we're very interested in learning how Microsoft will fix this issue. Meanwhile though, our patch probably covers the majority of attack scenarios.
Our Micropatch In Action
You can see the effect of our micropatch in the following video. There are two executable files on the desktop: goodsig.exe and badsig.exe. Both are really just calc.exe and both have the Mark of the Web, but the former has a proper parsable signature while the latter has a malformed, unparsable signature that causes SmartScreen to error out.
Without our micropatch, double-clicking goodsig.exe correctly shows the SmartScreen warning because any executable with Mark of the Web should trigger the warning. Double-clicking badsig.exe, on the other hand, just launches the executable without any warning - demonstrating the vulnerability.
With 0patch enabled and our micropatch applied, double-clicking goodsig.exe behaves the same as before (which is still correct), but double-clicking badsig.exe now triggers the "Open File - Security Warning" dialog, warning the user and allowing them to back out via the "Cancel" button.
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:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows Server 2022
Windows Server 2019
Note that Windows 7 is not affected by this issue, neither are Windows Server 2008 and 2012.
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 Patrick Schläpfer for sharing the details on their Magniber ransomware analysis and Will Dormann for their analysis of this vulnerability that allowed us to reproduce it and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
On September 24, 2022 we were made aware of a POC for a Print Spooler elevation of privilege vulnerability discovered by security researcher luckyu with NSFOCUS TIANYUAN LAB. It turned out to be another symbolic link issue that Print Spooler has quite a history of.
The POC sets up a new printer with a custom spool directory as a non-admin user. This directory is a symbolic link to another directory, which contains a .SHD file that is itself again a symbolic link to some existing file which a non-admin user lacks permissions to delete. Then, by using file locking and performing some operations on the printer, the Print Spooler process (running as Local System) is made to delete said .SHD file, which in fact deletes the file it points to. A non-admin can therefore delete any local file that Local System is able to delete. This can, surprisingly, lead to arbitrary code execution using a trick earlier discovered by another researcher Abdelhamid Naceri and described in this ZDI article.
Microsoft assigned CVE-2022-30206 to this issue and fixed it with July 2022 updates. Not for everyone, of course: we determined that older Windows versions that had stopped receiving updates by then were also affected, and therefore needed our patch.
Having decided to patch this issue, we analyzed it, found the root cause and determined that the best approach would be similar to what we've done with other symbolic link issues in Print Spooler before: add a check in localspl.dll before the DeleteFile call to see if a path to the .SHD file is a symbolic link - and skip the deletion in case it was. This would not break the typical use case without symbolic links, and we doubt that any legitimate use case would involve a .SHD file being a symbolic link.
Having written such micropatch, we started testing it and discovered something peculiar: the linked-to file still got deleted even if our patch properly bypassed the DeleteFile call. What was going on?
It turned out that while we have patched the issue at hand, there was another very similar issue elsewhere in the code that also led to deleting the .SHD file. Interestingly though, this issue was not present on a Windows 10 v1909 updated to its last updates in May 2022. This version of Windows 10 was the last security-adopted Windows version at the time and received Windows updates a bit longer than others - which meant that it must have received a patch for this "newly discovered" issue while others haven't.
To identify this second issue, we tested the POC with our patch on Windows 10 v1909 with different Windows updates starting with May 2022 (the last updates for v1909) and going back in time. This revealed that the issue was fixed with February 2022 updates.
Looking at all vulnerabilities fixed with February 2022 updates, only one fit the description: CVE-2022-21997. It was a "Windows Print Spooler Elevation of Privilege Vulnerability", with the Microsoft advisory stating that "an attacker would only be able to delete targeted files on a system." The issue was reported by Bo Wu, whom we tried to contact for confirmation but unfortunately so far failed to reach.
In any case, it would make no sense to only patch the originally intended CVE-2022-30206, so we also went on to patch this "bonus" issue CVE-2022-21997. We did that with an identical patch, just in another location in localspl.dll. With both patches in place, the POC and the technique it was using no longer worked.
These micropatches were written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909 (CVE-2022-30206 only)
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
Micropatches have already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain these micropatches and have them applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank luckyu for publishing their analysis with a
proof-of-concept that allowed us to reproduce both vulnerabilities and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
September 2022 Windows Updates brought a fix for an elevation of privilege vulnerability in Kerberos protocol, discovered by James Forshaw of Google Project Zero. James published a detailed analysis, and a POC was subsequently added to their Rubeus tool.
Microsoft assigned James' finding two separate CVE IDs, CVE-2022-33647 and CVE-2022-33679, but these really both have the same root cause, namely the fact that Kerberos supported two weak encryption types: RC4-MD4 (type -128) and RC4-HMAC-OLD (type -133).
James demonstrated that downgrading encryption to RC4-MD4 can allow an attacker to extract the Ticket Granting Ticket (TGT) key and use it for requesting a new TGT for the targeted user, which can be used for launching any code on the domain controller as said user.
Microsoft removed support for both weak encryption types from the Kerberos code. Our
micropatch, written only for Windows Server 2008 R2 (the only server that didn't get Microsoft's patch) is logically
equivalent to Microsoft's:
cmp ecx, 0xFFFFFF80 ; is encryption type RC4-MD4? je ERROR ; if so, error out cmp ecx, 0xFFFFFF7B ; is encryption type RC4-HMAC-OLD? jne SKIP ; if so, error out ERROR: mov rax, 0x0 ; rax 0 means "unsupported" retn
SKIP:
code_end patchlet_end
This video demonstrates the effect of our micropatch. With
0patch disabled, launching the POC against a vulnerable Windows 2008 R2 server provides a Ticket Granting Ticket for server's administrator, which then makes it possible to launch a remote terminal session to the server as that user. With 0patch enabled, RC4-MD4 is no longer accepted and the attack fails.
This
micropatch has already been distributed to all
online Windows Server 2008 R2 computers running 0patch Agent with PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank James Forshaw of Google Project Zero for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
Update 11/8/2022: This issue, nicknamed "ZippyReads", got an official fix with November 2022 Windows Updates which assigned it CVE-2022-41049. Our micropatches for it are therefore no longer free and require a PRO or Enterprise license. Details have also been published.
In May, security researcher Will Dormann found a vulnerability in Windows that allows an attacker to prevent Windows from setting the "Mark of the Web" flag on files extracted from a ZIP archive, even if the ZIP archive came from an untrusted source such as Internet, email, or a USB key.
Mark of the Web (MOTW) is an important security mechanism in Windows:
Windows will show a security warning before launching an executable file with MOTW;
Microsoft Office blocks macros on documents with MOTW (source).
Attackers therefore understandably prefer their malicious files not being marked with MOTW; this vulnerability allows them to create a ZIP archive such that extracted malicious files will not be marked.
Will has notified Microsoft about this issue in July, but an official fix has not been provided yet. Meanwhile, the vulnerability is apparently being exploited in the wild.
We're happy to report that we've just issued micropatches for this vulnerability, and are - according to our guidelines - providing it free of charge until Microsoft has issued their official fix.
We will not provide details on the vulnerability at this point.
Our Micropatch In Action
The video below shows our micropatch in action. With 0patch disabled (and the micropatch therefore not applied), an executable file in a ZIP archive that is marked with MOTW executes without a warning, because the file itself is not marked with MOTW upon extraction. With our micropatch in place, the extraction code is corrected and properly applies the MOTW to the extracted file - which results in the security warning being shown to the user.
Similarly, an attacker could deliver Word or Excel files in a downloaded ZIP that would not have their macros blocked due to the absence of the MOTW (depending on Office macro security settings), or would escape the inspection by Smart App Control.
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:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 with or without ESU
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2 with or without ESU
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.
