Free Micropatches For Bypassing MotW Security Warning with Invalid Signature (0day)

by Mitja Kolsek, the 0patch Team

 

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.

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: 

1. Windows 11 v21H2
   
2. Windows 10 v21H2
   
3. Windows 10 v21H1
   
4. Windows 10 v20H2
   
5. Windows 10 v2004
6. Windows 10 v1909
7. Windows 10 v1903
8. Windows 10 v1809
9. Windows 10 v1803
10. Windows Server 2022
11. 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.

Micropatches for two Windows Print Spooler Elevation of Privilege issues (CVE-2022-30206, CVE-2022-21997)

 

by Mitja Kolsek, the 0patch Team

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:

1. Windows 10 v2004
2. Windows 10 v1909 (CVE-2022-30206 only)
   
3. Windows 10 v1903
   
4. Windows 10 v1809
   
5. Windows 10 v1803
6. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
7. 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.

Micropatches for Kerberos Elevation of Privilege (CVE-2022-33647, CVE-2022-33679)

by Mitja Kolsek, the 0patch Team

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:

MODULE_PATH "..\Affected_Modules\kdcsvc.dll_6.1.7601.24499_Srv2008R2_64-bit_NoESU\kdcsvc.dll"
PATCH_ID 1139
PATCH_FORMAT_VER 2
VULN_ID 7509
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x413a8
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    
    code_start
       
        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.

 

Free Micropatches For Bypassing "Mark of the Web" on Unzipped Files ("ZippyReads" / CVE-2022-41049)

 

by Mitja Kolsek, the 0patch Team

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;
• Smart App Control only works on files with MOTW (source);
• 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: 

1. Windows 11 v21H2
   
2. Windows 10 v21H2
   
3. Windows 10 v21H1
   
4. Windows 10 v20H2
   
5. Windows 10 v2004
6. Windows 10 v1909
7. Windows 10 v1903
8. Windows 10 v1809
9. Windows 10 v1803
10. Windows 7 with or without ESU
    
11. Windows Server 2022
12. Windows Server 2019 
13. Windows Server 2016
14. Windows Server 2012
15. Windows Server 2012 R2
16. 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. 

Two More Years of Critical Security Patches for Windows 7 and Windows Server 2008 R2

Extended Security Updates about to be terminated? Don't worry, we have your back.

by Mitja Kolsek, the 0patch Team

 

 

Is your organization still using Windows 7 or Windows Server 2008 R2? We understand: these are good stable Windows versions that just work, do not force you to perform unneeded upgrades that change your user interface, don't distract users with ads and news they never wanted to see, don't send tons of telemetry data to Microsoft and most of all, reliably support your work processes.

Perhaps you've kept using these Windows versions without any security updates when free updates were terminated in January 2020 (narrator: "That's a bit risky."). Or you may have purchased Extended Security Updates (ESU) to keep receiving official security fixes from Microsoft (narrator: "That's a bit expensive."). Or, you may have been using 0patch to keep running Windows 7 and Server 2008 R2 securely by receiving our security micropatches for the most-likely-to-be-exploited critical vulnerabilities.

If you chose the Extended Security Updates path, you have a big decision ahead of you, as these updates are about to be terminated soon: Windows 7 and Windows Server 2008 R2 (on-prem) will receive their last ESU update in January 2023.

After that, no new security patches for these two Windows versions will exist.

... is what could be said if it weren't for 0patch.

We have decided to keep providing security patches for Windows 7 and Windows Server 2008 R2 for critical vulnerabilities that are likely to get exploited, and will be happy to keep you secured for a fraction of what you had paid for ESU so far. And you won't have to restart your computer even once, because our patches are applied directly in the memory of running processes instead of changing your executable files!

If you're using ESU and want to continue with 0patch, just keep applying all remaining ESU updates, including the last one in January 2023. Then install 0patch Agent on all your Windows 7 and Server 2008 R2 computers, and register them to your 0patch account holding a suitable amount of licenses. 

That's it. No really, that's it.

I mean, that's it if you want to "set and forget" 0patch, which many of our users actually do. Otherwise you can use 0patch Central to decide which of our micropatches shall be applied on which computers by organizing computers in groups and setting group-specific patching policies. (Enterprise licenses are needed for that.)

Of course it would be a good idea to test 0patch in your environment first instead of waiting until January. We'll be happy to set you up with a trial so you can see how 0patch works and how it co-exists with other components in your environment. Just email sales@0patch.com and you'll be quickly on your way.

Frequently Asked Questions

Q: How long do you plan to provide critical security patches for Windows Server 2008 R2 and Windows 7 after January 2023?

A: For at least two more years - until January 2025. Depending on the demand, we'll consider a further 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 52 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: We haven't been using Extended Security Updates and have had no security patches since January 2020. Can we still use 0patch to get up to speed with critical security patches?

A: Of course. Just make sure you have January 2020 updates installed on your Windows 7 and Server 2008 R2 computers and start using 0patch; it will apply all micropatches that other users without Extended Security Updates have been receiving since 2020.

Q: We have been using Extended Security Updates but only for one or two years. Can we still use 0patch to get up to speed with critical security patches?

A: Absolutely. All micropatches for Windows 7 and Server 2008 R2 we have ever issued were ported written for fully updated computers (1) without ESU, (2) with only the first year of ESU, and (3) with only the second year of ESU. We'll keep doing this, and will - starting with February 2023 - also port new patches to fully updated computers (4) with the the third year of ESU, so anyone can join in and get all our patches.

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: What is the main difference between 0patch patches and original vendor patches?

A: These are the main differences:

1. Our patches are applied in memory only and don't modify executable files.
   
2. Due to the above, applying or un-applying our patches does not require you to even relaunch patched applications, much less restart the entire computer.
3. Our patches are really tiny, usually just a couple of CPU instructions; by modifying only the tiniest possible fraction of original code we also minimize the possibility of introducing new flaws in the code.
4. We don't provide patches for all security issues, only for those that are sufficiently severe and likely to be exploited.
   

Q: Are you also going to security-adopt Windows Server 2012 when it reaches end of support next year?

A: Yes we are.

Q: We'd like to see a demo.

A: Send an email to sales@0patch.com 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 sales@0patch.com 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 sales@0patch.com.

Micropatches for Windows IKE Extension Remote Code Execution (CVE-2022-34721)

by Mitja Kolsek, the 0patch Team

September 2022 Windows Updates brought a fix for a remote code execution vulnerability in Windows IKE Extension discovered by Yuki Chen with Cyber KunLun. Soon after that, researchers from 78ResearchLab published an analysis and POC for this vulnerability. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.

The vulnerability is in the code responsible for handling IKEv1 (Internet Key Exchange version 1) key exchange protocol, which is deprecated but still supported for legacy reasons. It is a memory corruption issue, with the POC causing the svchost.exe process hosting the IKEEXT service to crash by attempting to read data beyond an allocated buffer. The crash only occurs with page heap (a debugging accessory) enabled for the process, while in a typical production configuration, the vulnerability could potentially be used for arbitrary code execution (as confirmed by Microsoft's advisory).

Microsoft assigned this issue CVE-2022-34721 and fixed it by adding a check for the length of incoming data, and bypassing the processing of such data if the length is too small. Our micropatch is logically equivalent to Microsoft's:

MODULE_PATH ".\ikeext.dll"
PATCH_ID 1000009
PATCH_FORMAT_VER 2
VULN_ID 1000010
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2d131
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT ikeext!0xaafd8,ikeext!0x2d1c0,ikeext!0x2d14f
    ; 0xaafd8 -> IkeCopyIncomingData
    ; 0x2d1c0 -> first WfpMemFree block
    ; 0x2d14f -> jump to NtohHeader in same block as patch
    
    code_start
       
        mov r8d, 1Ch        ; number of characters to copy; for memcpy in IkeCopyIncomingData
        lea rcx, [rbp-30h]  ; new buffer; for memcpy in IkeCopyIncomingData        mov rdx, r14           ; buffer to copy from; for memcpy in IkeCopyIncomingData
        call PIT_0xaafd8    ; call IkeCopyIncomingData
        mov rbx, rax        ; save return from IkeCopyIncomingData
        test rax, rax       ; check if return from IkeCopyIncomingData is non-zero
        jnz PIT_0x2d1c0     ; jump to WfpMemFree block if non-zero
       
        lea rcx, [rbp-30h]  ; buffer with copied data
        jmp PIT_0x2d14f     ; jmp to NtohHeader in same block as patch
       
    code_end
patchlet_end

 

This video demonstrates the effect of our micropatch. With 0patch disabled, launching the POC against a vulnerable computer causes a svchost.exe process to crash due to memory access violation. With 0patch enabled, the vulnerability is no longer there, the malformed IKEv1 packet is blocked, and the service doesn't crash.

 

The micropatch was written for the following Versions of Windows with all available Windows Updates installed:

1. Windows 10 v2004
2. Windows 10 v1909
3. Windows 10 v1903
4. Windows 10 v1809
5. Windows 10 v1803 
6. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
7. 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 Yuki Chen for finding this issue, and 78ResearchLab researchers 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.

Micropatches for Windows Kerberos Elevation of Privilege (CVE-2022-35756)

 

by Mitja Kolsek, the 0patch Team

August 2022 Windows Updates brought a fix for a local privilege escalation in Windows Kerberos, discovered by Nick Landers (@monoxgas) of NetSPI. Nick and James Forshaw (@tiraniddo) presented this vulnerability at the BlackHat USA 2022 conference and subsequently published proof-of-concept scripts. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.

The vulnerability allows an attacker to bypass an integrity check for a security buffer of a PAC structure sent inside attacker's AP-REQ request. The flawed integrity check improperly inspects the security buffer type by comparing it to constant SECBUFFER_TOKEN while ignoring that its value can also include two bit flags in the upper byte. Nick's and James' proof-of-concept adds one such flag to the value, bypassing the integrity check, and can therefore arbitrarily modify the PAC structure - for instance, to claim the requestor is not the actual low-privileged user but a local administrator. According to Microsoft's advisory, "a domain user could use this vulnerability to elevate privileges to a domain admin."

Microsoft assigned this issue CVE-2022-35756 and fixed it by removing the execution branch that led to the bypass. Our micropatch is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\kerberos.dll_6.1.7601.24545_Win7_32-bit_NoESU\kerberos.dll"
PATCH_ID 1053
PATCH_FORMAT_VER 2
VULN_ID 7492
PLATFORM win32

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0xe856
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    
    code_start
       
        push eax                  ;save the original rax value
        mov eax, [ebp-0x14]       ;get the flag location pointer +0x8 for the previous push
        bt dword[eax+0x28], 0x19  ;test the 0x19-th bit
        pop eax                   ;restore original rax value
        jb SKIP                   ;if bit is set, keep the old rcx value
        mov eax, 1                ;if bit is not set, mov 1 into rcx
    SKIP:
        ; the value of rax here will be stored to rcx and serve as an argument
        ; in a call to KerbCreateTokenFromTicketEx      

    code_end
patchlet_end

 

The micropatch was written for the following Versions of Windows with all available Windows Updates installed:

1. Windows 10 v2004
2. Windows 10 v1909
3. Windows 10 v1903
   
4. Windows 10 v1809
   
5. Windows 10 v1803
6. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
7. 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 Nick Landers (@monoxgas) and James Forshaw (@tiraniddo) for publishing their analysis with 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.

Micropatch For Memory Corruption in Microsoft Outlook (CVE-2022-35742)

 

by Mitja Kolsek, the 0patch Team

 

August 2022 Windows Updates brought a fix for a memory corruption vulnerability in Microsoft Outlook, discovered by security researcher insu of 78ResearchLab. The vulnerability exploits a flaw in Outlook's processing of multiple Content-Type headers in a multipart/signed email, whereby a malicious email can lead to free'ing an unallocated memory address and crashing Outlook as such email is downloaded (even before one can view it). Once such email is in user's Inbox, Outlook crashes whenever the user clicks on it or it gets displayed in the Preview pane.

While Microsoft categorized this flaw as "denial of service", it seems possible it could be exploited for arbitrary code execution.

0patch has security-adopted Office 2010 in November 2020 when its support was officially terminated, but Microsoft kept providing security updates for it until April 2021. After that date, we analyzed every published vulnerability affecting still-supported versions of Office to see if Office 2010 was affected, and until now, have not confirmed any. This is the first case where we could reproduce a publicly detailed, potentially critical issue in an Office 2010 component.

Thankfully, the researcher published an analysis and a POC for this vulnerability. This made it possible for us to create a patch for Outlook 2010 that no longer receives official fixes from Microsoft.

Microsoft assigned this issue CVE-2022-35742 and fixed it by properly preserving the flag (bit) that denotes whether a Content-Type buffer needs to be free'd or not. Our micropatch is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\OUTLMIME.DLL_14.0.7268.5000_Office-2010_64bit_202104\outlmime.dll"
PATCH_ID 1025
PATCH_FORMAT_VER 2
VULN_ID 7481
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x27d72
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT outlmime!0x27db9,outlmime!0x27d7d,outlmime!0x272ac
    
    code_start
       
        mov r15, 0              ; default r15 for setz command
        call PIT_0x272ac        ; rewrite original code for patch placement
        mov ebp, eax            ; rewrite original code for patch placement
        test eax, eax           ; rewrite original code for patch placement
        js PIT_0x27db9          ; rewrite original code for patch placement
       
        mov eax, [rdi+100h]     ; get flag from memory
        and al, 2               ; check flag state
        cmp al, 2               ; check flag state
        setz r15b               ; set r15 accordingly to flag
        jmp PIT_0x27d7d         ; jump to block where memory is copied
       
    code_end
patchlet_end

patchlet_start
    PATCHLET_ID 2
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x27db3
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 6
    PIT outlmime!0x27db9
    
    code_start
       
        mov [rdi+12Ch], eax     ; rewrite original code for patch placement
        mov rax, [rbx+0F8h]     ; read value from memory
        test byte[rax+10h], 4   ; check if read memory+10h contains 4
        jnz PIT_0x27db9         ; if memory+10h contains 4 then check flags
                                ; else jump to function return block
       
        test r15d, r15d         ; check if flag is set
        jz AND_BLOCK            ; if set jump to AND_BLOCK
       
        or dword[rdi+100h], 2   ; if flag not set then set it
        jmp PIT_0x27db9         ; jump to function return block
       
    AND_BLOCK:
        and dword[rdi+100h], 0FFFFFFFDh    ; reset flag
                                ; continue normal execution
    code_end
patchlet_end

 

This video demonstrates the effect of our micropatch. With 0patch disabled, downloading the malicious email in Outlook 2010 crashes Outlook, and restarting Outlook leads to the same result, effectively disabling user's email; with 0patch enabled, the malicious email gets downloaded and while it can't be displayed due to malformed content, it sits there doing no harm.

 

The micropatch was written for 32-bit and 64-bit versions of Outlook 2010, fully updated with its latest free updates from April 2021.

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. 

We'd like to thank insu of 78ResearchLab 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.

Micropatches for Windows IKE Extension Remote Code Execution (CVE-2022-21849)

 

by Mitja Kolsek, the 0patch Team

January 2022 Windows Updates brought a fix for a remote code execution vulnerability in Windows IKE Extension discovered by Polar Bear. Ten days ago (as of this writing), researchers from 78ResearchLab published an analysis and a POC for this vulnerability. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.

The vulnerability allows a remote attacker to cause memory (heap) corruption on the target computer by sending a malformed ISAKMP packet using the IKE protocol, whereby the VendorID payload is longer than the expected 10h characters. The vulnerable code namely prepares a 10-character buffer on the stack for storing this value, and in case a longer value is provided, the memcpy (memory copy) operation results in memory locations beyond the end of buffer being overwritten with attacker-chosen content. In the absence of a negative proof, such vulnerabilities are assumed to be exploitable for arbitrary code execution (although the POC at hand only results in crashing the process.)

Microsoft assigned this issue CVE-2022-21849 and fixed it by adding a check for the length of the VendorID value: if the length isn't exactly 10h (if the size of the entire payload including the 10h-byte prologue isn't exactly 20h), it ignores this value. Our micropatch with just two CPU instructions is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\ikeext.dll_10.0.17134.254_Win10-1803_64-bit_u202105\ikeext.dll"
PATCH_ID 1018
PATCH_FORMAT_VER 2
VULN_ID 7502
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2d93f
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT IKEEXT.DLL!0x1fb64
    
    code_start
       
        cmp r13d, 20h     ; is the size of the VendorID payload equal to 20h?
        jne PIT_0x1fb64   ; if not, ignore the value
       
    code_end
patchlet_end

 

The micropatch was written for the following Versions of Windows with all available Windows Updates installed:

1. Windows 10 v2004
2. Windows 10 v1903
3. Windows 10 v1803

Note that Windows 7 and Server 2008 R2 are not affected by this issue, and Windows 10 v1909 was still receiving official updates in January 2022. 

 

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. 

We'd like to thank Polar Bear for finding this issue, and 78ResearchLab researchers 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.

Micropatches for Local Privilege Escalation in LSASS (CVE-2022-30166)

 

 

by Mitja Kolsek, the 0patch Team

Update 9/1/2022: Micropatches for Local Privilege Escalation in LSASS (CVE-2022-30166) that were issued yesterday were reported to cause authentication problems with SharePoint and Remote Desktop Gateway Service. After successfully reproducing the issue these patches have just just revoked, and will be automatically disabled on all systems within 60 minutes. No action is needed on 0patch users' and administrator' end while we're working on issuing corrected patches.

Update 9/20/2022: After reproducing functional problems caused by our original micropatches we have now issued new ones. We'd like to thank all customers who promptly reported problems and helped us reproduce them. No action is needed on 0patch users' and administrator' end to have the new patches applied.

 

June 2022 Windows Updates brought a fix for a local privilege escalation in Local Security Authority Subsystem Service (LSASS), discovered by James Forshaw of Google Project Zero. James published details and a POC on July 14.

The vulnerability allows a local non-admin attacker to use a certain type of impersonation (specifically, impersonating a token at identification level) to get the service running as Local System to enumerate the ticket cache not only for the requesting user but also for the Local System account. With this information, the attacker could elevate their privileges on the local system.

Microsoft assigned this issue CVE-2022-30166 and fixed it by creating an "anonymous" impersonation when the original attempt at impersonation fails; as a result, a malicious request ends up returning only requesting user's ticket cache.

Our micropatch with 18 CPU instructions is logically equivalent to Microsoft's:

MODULE_PATH "..\AffectedModules\lsasrv.dll_10.0.19041.1415_Win10-2004_64-bit_u202112\lsasrv.dll"
PATCH_ID 1017
PATCH_FORMAT_VER 2
VULN_ID 7441
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2e302
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    PIT lsasrv!0x145f0,ntdll!NtClose
    
    code_start
    
        mov byte[rdi+0x11], 1     ;original overwritten code
        mov [rdi+0x14], eax       ;original overwritten code
    
        cmp eax, 1                ;check current tokens impersonation level. 1 == ANONYMOUS
        jne END                   ;if it is ANONYMOUS nothing needs to be done and we
                                  ;skip the patch
               
        mov rcx, [rbx+0x0c0]      ;move current token handle to rcx so we can close it
        sub rsp, 0x20             ;create shadowspace with additional 0x8 bytes to
                                  ;align the stack
        call PIT_NtClose          ;close the token handle
        add rsp, 0x20             ;delete the created shadowspace
        mov qword[rbx+0x0c0], 0x0 ;overwrite the old handle with 0x0
       
        mov rcx, rdi              ;move SECPKG_CLIENT_INFO_EX to rcx
        lea rdx, [rbx+0x0c0]      ;move new handle pointer to rdx for output
        mov qword[rcx], 0x3e6     ;move LsapAnonymousLogonId to rcx pointer
        push 0x000003e6           ;push LsapAnonymousLogonId to stack so we can use the
                                  ;pointer
        lea rcx, [rsp]            ;move the pointer to LsapAnonymousLogonId into rcx
       
        sub rsp, 0x28             ;create shadowsapce
        call PIT_0x145f0          ;call LsapOpenTokenByLogonId to get a new anonymous
                                  ;token
        add rsp, 0x30             ;clear shadowspace and account for the push
        mov rax, 1                ;move 1 to eax as some versions of this dll need it
                                  ;and we don't need the return value
    END:
       
    code_end
patchlet_end

 

This video demonstrates the effect of our micropatch. With 0patch disabled, the POC obtains and displays the token cache of both the current user and Local System; with 0patch enabled, only user's token cache is accessible to the local non-admin user.

 

The micropatch was written for the following Versions of Windows with all available Windows Updates installed:

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

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. 

We'd like to thank James Forshaw 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.