Normal view

There are new articles available, click to refresh the page.
Before yesterday0patch Blog

Micropatches for the "File Extension" URL Scheme (CVE-2021-40444)

27 September 2021 at 13:21

 


 

by Mitja Kolsek, the 0patch Team

September 2021 Windows Updates brought a fix for CVE-2021-40444, a critical vulnerability in Windows that allowed a malicious Office document to download a remote executable file and execute it locally upon opening such document. This vulnerability was found under exploitation in the wild.

 

The Vulnerability

Unfortunately, CVE-2021-40444 does not cover just one flaw but two; this can lead to some confusion:

  1. Path traversal in CAB file extraction: The exploit was utilizing this flaw to place a malicious executable file in a known location instead of a randomly-named subfolder, where it would originally be extracted.

  2. "File extension" URL scheme: For some reason, Windows ShellExecute function, a very complex function capable of launching local applications in various ways including via URLs, supported an undocumented URL scheme mapped to registered file extensions on the computer. The exploit was utilizing this "feature" to launch the previously downloaded executable file with the Control Panel application and have it executed via URL ".cpl:../../../../../Temp/championship.cpl". In this case, ".cpl" was considered a URL scheme, and since .cpl extension is associated with control.exe, this app would get launched and given the provided path as an argument.

The second flaw is the more critical one, as there may exist various other ways to get a malicious file on user's computer (e.g., via the Downloads folder) and still exploit this second flaw to execute such file.

 

Microsoft's Patch

What Microsoft's patch did was add a check before calling ShellExecute on the provided URL to block URL schemes beginning with a non-alphanumeric character - blocking schemes beginning with a dot such as ".cpl" -, and further limiting the allowed set of characters for the remaining string.

Note that ShellExecute function itself was not patched, and you can still launch a DLL via the Control Panel app by clicking the Windows Start button and typing in a ".cpl:/..." URL. Effectively, therefore, support for the "File extension" URL scheme was not eliminated across entire Windows, just made inaccessible from applications utilizing Internet Explorer components for opening URLs. Hopefully remotely delivered content can't find some other way towards ShellExecute that bypasses this new security check.


Our Micropatch

Microsoft's update fixed both flaws, but we decided to only patch the "File extension" URL scheme flaw until someone demonstrates the first flaw to be exploitable by itself.

The "File extension" URL scheme flaw was actually present in two places, in mshtml.dll (reachable from Office documents) and in ieframe.dll (reachable from Internet Explorer), so we had to patch both these executables.

Since an official vendor fix is available, it was our goal to provide patches for affected Windows versions that we have "security-adopted", as they're not receiving official vendor patches anymore. Among these, our tests have shown that only Windows 10 v1803 and v1809 were affected; the File Extension URL scheme "feature" was apparently added in Windows 8.1.

We expect many Windows 10 v1903 machines out there may also be affected, so we decided to port the micropatch to this version as well.

Our CVE-2021-40444 micropatches are therefore available for: 

  1. Windows 10 v1803 32bit or 64bit (updated with May 2021 Updates - latest before end of support)
  2. Windows 10 v1809 32bit or 64bit (updated with May 2021 Updates - latest before end of support) 
  3. Windows 10 v1903 32bit or 64bit (updated with December 2020 Updates - latest before end of support) 


Below is a video of our patch in action. Notice that with 0patch disabled, Calculator is launched both upon opening the Word document and upon previewing the RTF document in Windows Explorer Preview. In both cases, Process Monitor shows that control.exe gets launched, which loads the "malicious" executable, in our case spawning Calculator. With 0patch enabled, control.exe does not get launched, and therefore neither does Calculator.




In line with our guidelines, these patches require a PRO license. To obtain them and have them applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account, then purchase 0patch PRO.
For a free trial, contact [email protected].
 
Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatches.

We'd like to thank Will Dormann for an in-depth public analysis of this vulnerability, which helped us create a micropatch and protect our users.

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

Free Micropatches For "Follina" Microsoft Diagnostic Tool Remote Code Execution 0day (CVE-2022-30190)

1 June 2022 at 13:58

 


by Mitja Kolsek, the 0patch Team

 

[Update 6/2/2022: Additional patches were issued for Windows Servers]

[Update 15/6/2022: Microsoft issued an official patch for this vulnerability. They implemented functionally the same security check in msdt.exe as we had in sdiagnhost.exe, namely checking for the presence of "$(" in the user-provided path. With official patches being available, our micropatches for this vulnerability are no longer free but require PRO or Enterprise license.] 

It was a quiet Sunday evening with a promise of enjoying a few chapters of The End of Everything by Katie Mack (an excellent book if long-term planning is your thing) when a tweet from Kevin Beaumont came by, opening with "This is a nice find." Knowing Kevin - at lest on Twitter - this often translates to "It's going to be a long night."

The tweet quoted by Kevin was actually from Friday, where nao_sec stated that an "Interesting maldoc was submitted from Belarus. It uses Word's external link to load the HTML and then uses the "ms-msdt" scheme to execute PowerShell code."

A remote code execution vulnerability was obviously spotted getting exploited in the wild. The vulnerability, quickly confirmed by many researchers using various versions of fully updated Microsoft Office, allowed a Word document to execute arbitrary PowerShell commands on the computer with little user interaction. It utilized the "ms-msdt:" URL scheme registered by default on all modern Windows versions to execute the Diagnostic Tool msdt.exe with malicious arguments.

It all looked very similar to CVE-2021-40444, where a malicious Word document would load a remote HTML template, which in turn opened a special type of URL to launch attacker's executable. But it was even "better" because no malicious executable needed to be dropped on victim's computer to be subsequently executed, as PowerShell commands have all the power the attacker ever needs.

For more details about the context, see Kevin's article which keeps getting updated as new data becomes available. Kevin is an unofficial authority for naming 0days and he dubbed this one "Follina"; Microsoft subsequently assigned it CVE-2022-30190 after having rejected a submission by researcher CrazymanArmy as "not a security-related issue."


The Vulnerability

This issue is widely considered a vulnerability in Office, due to Office documents being an efficient vehicle for delivering a "ms-msdt:" URL and having it rendered without restrictions with user's identity. However, we believe the actual problem to be the PowerShell command injection accessible via the IT_BrowseForFile argument of msdt.exe application, as first noted by Alec Wiese. While allowing an Office document to launch an application via special URL scheme may be providing an unneeded attack surface (which may lead to additional similar 0days being discovered in the future), this would all have been a non-issue without the command execution.

So where does the PowerShell command execution come from? A minimized POC triggering the vulnerability contains this parameter for msdt.exe:

IT_BrowseForFile=/../../$(calc).exe

The IT_BrowseForFile value contains a PowerShell subexpression "$(calc)", which results in executing the "calc" command in PowerShell, and that launches the Calculator app. Now why does this get executed at all? To find the answer, we need to see where the data passed to msdt.exe travels. One could use Process Monitor and debugger to find out, but we decided to use Tetrane REVEN, a powerful tool for reverse engineering which often saves us a lot of time with vulnerability analyses.

 

Tetrane REVEN during our analysis of this vulnerability, making it easy to trace data, inspect memory and find a good location for patching

Using REVEN, we could see the value in question traveling:

  1. from msdt.exe via an ALPC call to
  2. DCOM Server Process Launcher (hosted inside a svchost.exe), which launches
  3. sdiagnhost.exe that receives the data from msdt.exe, and passes it on to a RunScript call to execute
  4. PowerShell script TS_ProgramCompatibilityWizard.ps1 (in folder C:\Windows\diagnostics\system\PCW), which - inadvertently - gets the attacker's PowerShell subexpression executed by putting it in an Invoke-Expression call.

 

Note that TS_ProgramCompatibilityWizard.ps1 seems to be very much aware of the possibility of a "PowerShell subexpression injection" and dutifully sanitizes user-provided data in many places by replacing all occurrences of "$" with "`$", for example:

$appName = $choice["Name"].Replace("$", "`$")

Unfortunately, the one in IT_BrowseForFile argument slips by and still gets executed.

 

Our Micropatch

It would be by far the simplest for us to just disable msdt.exe by patching it with a TerminateProcess() call. However, that would render Windows diagnostic wizardry inoperable, even for non-Office applications. Another option was to codify Microsoft's recommendation into a patch, effectively disabling the ms-msdt: URL protocol handler.

But when possible, we want to minimize our impact outside of removing the vulnerability, so we decided to place our patch in sdiagnhost.exe before the RunScript call and check if the user-provided path contains a "$(" sequence - which is necessary for injecting a PowerShell subexpression. If one is detected, we make sure the RunScript call is bypassed while the Diagnostic Tool keeps running.

In IDA, our patch looks like this (green blocks are our code, blue block is original code relocated to a trampoline, value of rdx is used to emulate an error):



And a video of our patch in action. Since this vulnerability can be triggered via different vectors (not just Office documents), the video demonstrates how 0patch blocks an attack via msdt.exe, regardless of how msdt.exe got launched.



Note that sdiagnhost.exe, which is where our patch resides, has been last modified in Dec 2019 or even earlier on all patched Windows versions (except Windows 11, where it's naturally younger). This means our patch will be applied even if you have skipped many Windows Update cycles.

Also Note that it doesn't matter which version of Office you have installed, or if you have Office installed at all: the vulnerability could also be exploited through other attack vectors. That is why we also patched Windows 7, where the ms-msdt: URL handler is not registered at all.


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
  11. Windows Server 2008 R2
  12. Windows Server 2012
  13. Windows Server 2012 R2
  14. Windows Server 2016
  15. Windows Server 2019 
 

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 nao_sec for publishing exploitation details, which allowed us to reproduce the vulnerability and create a micropatch, and all other security researchers who have shared their findings with public or privately with us. We also encourage security researchers to privately share their analyses with us for micropatching.

 

Microsoft Diagnostic Tool "DogWalk" Package Path Traversal Gets Free Micropatches (CVE-2022-34713)

7 June 2022 at 13:39


by Mitja Kolsek, the 0patch Team

 

Update 8/10/2022: August 2022 Windows Updates brought an official fix for this vulnerability with assigned CVE-2022-34713. Our users were therefore protected from this issue whole 63 days before an official fix got available, and remain protected until they install August Windows Updates. These micropatches from now on require a PRO or Enterprise license.

 

With the "Follina" / CVE-2022-30190 0day still hot, i.e., still waiting for an official fix while apparently already getting exploited by nation-backed attackers, another related unfixed vulnerability in Microsoft's Diagnostic Tool (MSDT) bubbled to the surface.

In January 2020, security researcher Imre Rad published an article titled "The trouble with Microsoft’s Troubleshooters," describing a method for having a malicious executable file being saved to user's Startup folder, where it would subsequently get executed upon user's next login. What the user has to do for this to happen is open a "diagcab" file, an archive in the Cabinet (CAB) file format that contains a diagnostics configuration file.

According to Imre's article, this issue was reported to Microsoft but their position was that it was not a security issue worth fixing. This was their response:

"There are a number of file types that can execute code in such a way but aren’t technically “executables”. And a number of these are considered unsafe for users to download/receive in email, even .diagcab is blocked by default in Outlook on the web and other places. This is noted a number of places online by Microsoft.

The issue is that to make use of this attack an attacker needs to create what amounts to a virus, convince a user to download the virus, and then run it. Yes, it doesn’t end in .exe, but these days most viruses don’t. Some protections are already put into place, such as standard files extensions to be blocked, of which this is one. We are also always seeking to improve these protections. But as written this wouldn’t be considered a vulnerability. No security boundaries are being bypassed, the PoC doesn’t escalate permissions in any way, or do anything the user couldn’t do already."

The above does not sound unreasonable. The victim is supposed to open a file provided by the attacker, and then something bad happens. It's true (as it was back in 2020 when this was written) that most viruses aren't delivered to victims as .exe files or other typical executables, and that files with .diagcab extension would be marked as dangerous by Outlook. However, Outlook is not the only delivery vehicle: such file is cheerfully downloaded by all major browsers including Microsoft Edge by simply visiting(!) a web site, and it only takes a single click (or mis-click) in the browser's downloads list to have it opened. No warning is shown in the process, in contrast to downloading and opening any other known file capable of executing attacker's code. From attacker's perspective, therefore, this is a nicely exploitable vulnerability with all Windows versions affected back to Windows 7 and Server 2008.

In any case, the issue was found, reported, deemed unworthy, and largely forgotten. Until security researcher j00sean found it again and brought attention to it last week, as Microsoft Diagnostic Tool was under the spotlight because of Follina.

We decided this issue is exploitable enough to warrant a micropatch, and with the cat out of the bag (having presumably stayed in the bag since 2020) the likelihood of its exploitation is now higher.

Oh, and where did the DogWalk name come from? I asked Kevin Beaumont to name this vulnerability before publishing the blog post, and Kevin agreed with Kili's suggestion. The whole story is in the Twitter thread.

 

The Vulnerability

The vulnerability lies in the Microsoft Diagnostic Tool's sdiageng.dll library, which takes the attacker-supplied folder path from the package configuration XML file inside the diagcab archive, and copies all files from that folder to a local temporary folder. During this process, it enumerates files in attacker's folder, gets the file name for each of them, then glues together the local temporary path and that file name to generate the local path on the computer where the file is to be created. For instance, if attacker's folder were C:\temp\ and it contained a single file test.txt, the affected code would find that file, determine its name to be "test.txt", concatenate the previously created temporary folder name with this file name to get something like "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca\test.txt" and finally create such file with the content of the original C:\temp\test.txt file.

Now, the source folder can be on a remote share, not only a local folder such as C:\temp. Furthermore, it can reside on a WebDAV share on the Internet because by default, Windows workstations happily use WebDAV to access network shares, and WebDAV goes through most firewalls as it is just basically outbound HTTP. But none of these is the vulnerability yet.

The vulnerability is in the fact that the code assumes the filename to be a valid Windows filename. You know, not containing those characters you see Windows complaining about when you try to rename a file to something with ":" or "|".

 Or, more specifically, that a file name can't be something like "\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".

Wait, can a file name actually look like that? Not if you try to create it with Windows Explorer or "regular tools", but there is nothing to prevent a WebDAV server from saying, "Here's the file, its name is whatever I want it to be, deal with it." Should Windows accept suchmalformed file names? Probably not - but they do, and they pass them on to applications using their APIs. Which is the case with the vulnerability at hand; let's see what happens:


  1. The diagcab archive contains package configuration XML file pointing to a folder on a remote WebDAV server.
  2. This folder hosts a file named "\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
  3. Vulnerable MSDT creates a local temporary folder such as "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca".
  4. It then appends the remote file name to this folder name and gets: "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
  5. Which in fact means "C:\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
  6. It finally copies the content of the remote weirdly-named file to malicious.exe in computer's Startup folder, where it will be executed the next time anyone logs in. 

 

Okay, but who would download and open a silly diagcab file? Well, the download can happen automatically in a drive-by-download fashion, as demonstrated by Imre's POC (click this link and see the file downloaded to your browser). Then you see it listed in browser's Downloads list and if you click on it - intentionally or not - it's game over.

How about Mark of the Web? Aren't all downloaded files and files received via email marked with this flag that tells Windows to warn the user if they want to open it?

They are indeed, and the downloaded diagcab file is marked as well. But it is up to the application processing the file to check this mark and warn the user. Many applications do that; MSDT, unfortunately, does not.

 

Our Micropatch

Clearly, this is a path traversal vulnerability, and these vulnerabilities are all addressed in the same way: by searching for occurrences of "..\" in attacker-supplied file name or path and blocking the operation in case any are found. This is exactly what we did here. Our patch adds code that searches the source file name for "..\"; if found, it reports an "Exploit blocked" event and emulates an error on the file copy operation as shown on the video below.



Source code of the micropatch:



MODULE_PATH "..\Affected_Modules\sdiageng.dll_10.0.18362.1_Win10-1909_64-bit_u202205\sdiageng.dll"
PATCH_ID 893
PATCH_FORMAT_VER 2
VULN_ID 7418
PLATFORM win64

patchlet_start

    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x20e86
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msvcrt!wcsstr,sdiageng!0x20f30
    code_start

        call VAR                    ; push "..\" to stack and use it as a variable
        dw __utf16__('..\'),0

    VAR:
        pop rdx                     ; get VAR from stack - substring
        lea rcx, [rsp+5Ch]          ; mov data pointer to rcx - path
        sub rsp, 20h                ; shadow space
        call PIT_wcsstr             ; search substring("..\") in a string(path)
        add rsp, 20h
        cmp rax, 0                  ; check wcsstr return. 0 if the string does
                                    ; not contain the substring
                                    ; else returns a pointer to the first
                                    ; occurrence of substring in string
       
        je CONTINUE
        call PIT_ExploitBlocked     ; exploit blocked popup
        jmp PIT_0x20f30             ; jmp to existing error block

    CONTINUE:                       ; normal code flow
       
    code_end

patchlet_end

 

This is how our patch (green code blocks) is integrated in the original vulnerable code (white and blue code blocks) to add the missing security check:



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
  11. Windows Server 2008 R2
  12. Windows Server 2012
  13. Windows Server 2012 R2
  14. Windows Server 2016
  15. Windows Server 2019 
  16. Windows Server 2022 
 

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.

We don't know whether this vulnerability has ever been exploited in the wild, or whether it will ever be. But as former attackers, we know it's the kind of issue one could realistically use, and our micropatches make sure that 0patch users don't have to care either way.

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

We'd like to thank Imre Rad for publishing vulnerability details and a POC, which allowed us to reproduce the vulnerability and create a micropatch, j00sean for digging this thing up and shedding light on it, and all other security researchers who have shared their findings with public or privately with us. We also encourage security researchers to privately share their analyses with us for micropatching.







Micropatching the "PrinterBug/SpoolSample" - Another Forced Authentication Issue in Windows

27 June 2022 at 15:11

 

by Mitja Kolsek, the 0patch Team


Forced authentication issues (including NTLM relaying and Kerberos relaying) are a silent elephant in the room in Windows networks, where an attacker inside the network can force a chosen computer in the same network to perform authentication over the network such that the attacker can intercept its request. In the process, the attacker obtains some user's or computer account's credentials and can then use these to perform actions with the "borrowed" identity.

In case of PetitPotam, for instance, the attacker forces a Windows server to authenticate to a computer of their choice using the computer account - which can lead to arbitrary code execution on the server. With RemotePotato0, an attacker already logged in to a Windows computer (e.g., a Terminal Server) can force the computer to reveal credentials of any other user also logged in to the same computer.

For a great primer on relaying attacks in Windows, check out the article "I’m bringing relaying back: A comprehensive guide on relaying anno 2022" by Jean-François Maes of TrustedSec. Dirk-jan Mollema of Outsider Security also wrote several excellent pieces: "The worst of both worlds: Combining NTLM Relaying and Kerberos delegation", "Exploiting CVE-2019-1040 - Combining relay vulnerabilities for RCE and Domain Admin" and "NTLM relaying to AD CS - On certificates, printers and a little hippo."

Alas, Microsoft's position seems to be not to fix forced authentication issues unless an attack can be mounted anonymously; their fix for PetitPotam confirms that - they only addressed the anonymous attack vector. In other words:

If any domain user in a typical enterprise network should decide to become domain administrator, no official patch will be made available to prevent them from doing so.

Microsoft does suggest (here, here) various countermeasures to mitigate such attacks, including disabling NTLM, enabling EPA for Certificate Authority, or requesting LDAP signing and channel binding. These mitigations, however, are often a no-go for large organizations as they would break existing processes. It therefore isn't surprising that many of our large customers ask us for micropatches to address these issues in their networks.

Consequently, at 0patch we've decided to address all  known forced authentication issues in Windows exploitable by either anonymous or low-privileged attackers.


The Vulnerability

The vulnerability we micropatched this time has two names - PrinterBug and SpoolSample - but no CVE ID as it is considered a "won't fix" by the vendor. Its first public reference is this 2018 Derbycon presentation "The Unintended Risks of Trusting Active Directory" by
Will Schroeder, Lee Christensen, and Matt Nelson of SpecterOps, where authors describe how the MS-RPRN RPC interface can be used to force a remote computer to initiate authentication to attacker's computer.

Will Schroeder's subsequent paper "Not A Security Boundary: Breaking Forest Trusts" explains how this bug can be used for breaking the forest trust relationships; with March 2019 Windows Updates, Microsoft provided a related fix for CVE-2019-0683, addressing only the forest trust issue.

Today, four-plus years later, the PrinterBug/SpoolSample still works on all Windows systems for forcing a Windows computer running Print Spooler service to authenticate to attacker's computer, provided the attacker knows any domain user's credentials. As such, it is comparable to PetitPotam, which also still works for a low-privileged attacker (Microsoft only fixed the anonymous attack), and the recently disclosed DFSCoerce issue - which we're also preparing a micropatch for.

The vulnerability can be triggered by making a remote procedure call to a Windows computer (e.g., domain controller) running Print Spooler Service, specifically calling function RpcRemoteFindFirstPrinterChangeNotification(Ex) and providing the address of attacker's computer in the pszLocalMachine argument. Upon receiving such request, Print Spooler Service establishes an RPC channel back to attacker's computer - authenticating as the local computer account! This is enough for the attacker to relay received credentials to a certificate service in the network and obtain a privileged certificate.

When RpcRemoteFindFirstPrinterChangeNotification(Ex) is called, it impersonates the client via the YImpersonateClient function - which is good. The execution then continues towards the vulnerability by calling RemoteFindFirstPrinterChangeNotification. This function then calls SetupReplyNotification, which in turn calls OpenReplyRemote: this function reverts the impersonation (!) before calling RpcReplyOpenPrinter, where an RPC request to the attacker-specified host is made using the computer account.

We're not sure why developers decided to revert impersonation of the caller before making that RPC call, but suspect it was to ensure the call would have sufficient permissions to succeed regardless of the caller's identity. In any case, this allow the attacker to effectively exchange low-privileged credentials for high-privileged ones.


Our Micropatch

When patching an NTLM relaying issue, we have a number of options, for instance:

 

  • using client impersonation, so the attacker only receives their own credentials instead of server's,
  • adding an access check to see if the calling user has sufficient permissions for the call at all, or
  • outright cutting off the vulnerable functionality, when it seems hard to fix or unlikely to be used.

 

This particular bug fell into the latter category, as we could not find a single product actually using the affected functionality, and Windows are also not using it in their printer-related products. If it turns out our assessment was incorrect, we can easily revoke this patch and replace it with one that performs impersonation.

Our micropatch is very simple: it simulates an "access denied" (error code 5) response from the RpcReplyOpenPrinter function without letting it make the "leaking" RPC call. This also blocks the same attack that might be launched via other functions that call RpcReplyOpenPrinter.

Source code of the micropatch has just two CPU instructions:



MODULE_PATH "..\Affected_Modules\spoolsv.exe_10.0.17763.2803_Srv2019_64-bit_u202205\spoolsv.exe"
PATCH_ID 908
PATCH_FORMAT_VER 2
VULN_ID 7419
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x576cc
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT spoolsv.exe!0x577df
    ; 0x577df -> return block

    code_start

        mov ebx, 5
        jmp PIT_0x577df

    code_end

patchlet_end

 


Micropatch Availability

While this vulnerability has no official patch and could be considered a "0day", Microsoft seems determined not to fix relaying issues such as this one; therefore, this micropatch is not provided in the FREE plan but requires a PRO or Enterprise license.

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

  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 (no ESU, ESU year 1, ESU year 2)
  11. Windows Server 2008 R2 (no ESU, ESU year 1, ESU year 2)
  12. Windows Server 2012
  13. Windows Server 2012 R2
  14. Windows Server 2016
  15. Windows Server 2019 
  16. Windows Server 2022 
 

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

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 Schroeder, Lee Christensen, and Matt Nelson of SpecterOps for sharing details about this vulnerability, and Dirk-jan Mollema of Outsider Security for excellent articles on relaying attacks and exploiting PrinterBug/SpoolSample in particular. We also encourage security researchers to privately share their analyses with us for micropatching.



Micropatching the "DFSCoerce" Forced Authentication Issue (No CVE)

1 July 2022 at 09:49

 


by Mitja Kolsek, the 0patch Team


"DFSCoerce" is another forced authentication issue in Windows that can be used by a low-privileged domain user to take over a Windows server, potentially becoming a domain admin within minutes. The issue was discovered by security researcher Filip Dragovic, who also published a POC.

Filip's tweet indicated this issue can be used even if you have disabled or filtered services that other currently known forced authentication issues such as PrinterBug/SpoolSample, PetitPotam, ShadowCoerce and RemotePotato0 are exploiting: "Spooler service disabled, RPC filters installed to prevent PetitPotam and File Server VSS Agent Service not installed but you still want to relay DC authentication to ADCS? Don't worry MS-DFSNM have your back ;)"

A quick reminder: Microsoft does not fix forced authentication issues unless an attack can be mounted anonymously. Our customers unfortunately can't all disable relevant services or implement mitigations without breaking production, so it is on us to provide them with such patches.


The Vulnerability

The vulnerability lies in the Distributed File System (DFS) service. Any authenticated user can make a remote procedure call to this service and execute functions NetrDfsAddStdRoot or NetrDfsremoveStdRoot, providing them with host name or IP address of attacker's computer. These functions both properly perform a permissions check using a call to AccessImpersonateCheckRpcClient, which returns error code 5 ("access denied") for users who aren't allowed to do any changes to DFS. If access is denied, they block the adding or removing of a stand-alone namespace - but they both still perform a credentials-leaking request to the specified host name or IP address.

Such leaked credentials - belonging to server's computer account - can be relayed to some other service in the network such as LDAP or Certificate Service to perform privileged operations leading to further unauthorized access. Unsurprisingly, attackers and red teams like such things.


Our Micropatch

Since a proper access check was already in place, just not reacted to entirely properly, we decided to use its result and correct the logic in both vulnerable functions.

The image below shows our patch (green code blocks) injected in function NetrDfsremoveStdRoot. As you can see, a call to AccessImpersonateCheckRpcClient is made in the original code, which returns 5 ("access denied") when the caller has insufficient permissions. This information is then stored as one bit into register r8b, and copied to local variable arg_18 (sounds like an argument, but compilers use so-called "home space" for local variables when it suits them). Our patch code takes the return value of AccessImpersonateCheckRpcClient and compares it to 5; if equal, we sabotage attacker's attempts by placing a zero at the beginning of their ServerName string pointed to by rcx, effectively turning it into an empty string. This approach allows us to minimize the amount of code and complexity of the patch, which is always our goal. Function DfsDeleteStandaloneRoot, which causes the forced authentication to attacker's host, is then called from the original code (moved to a blue trampoline code block) but it gets an empty string for the host name - and returns an error. A blocked attack therefore behaves as if a request was made by an unprivileged user with an illegal ServerName. We decided not to log this as an attempted exploit to avoid possible false positives in case a regular user without malicious intent might somehow trigger this code via Windows user interface.



 

Source code of the micropatch shows two identical patchlets, one for function NetrDfsAddStdRoot and one for NetrDfsremoveStdRoot:



MODULE_PATH "..\Affected_Modules\dfssvc.exe_10.0.17763.2028_Srv2019_64-bit_u202206\dfssvc.exe"
PATCH_ID 952
PATCH_FORMAT_VER 2
VULN_ID 7442
PLATFORM win64

patchlet_start
    PATCHLET_ID 1                ; NetrDfsAddStdRoot
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x183e
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    code_start
        neg eax                  ; get original return value from AccessImpersonateCheckRpcClient
        cmp eax, 5               ; check if access denied(5) was returned
        jne CONTINUE_1           ; return value is not 5, continue with
                                 ; normal code execution
        mov word[rcx], 0         ; else set ServerHost to NULL. Result: DFSNM
                                 ; SessionError: code: 0x57 - ERROR_INVALID_PARAMETER
                                 ; continue with original code
    CONTINUE_1:
       
    code_end
patchlet_end

patchlet_start
    PATCHLET_ID 2                ; NetrDfsremoveStdRoot
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x1c96
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    code_start
        neg eax                 
; get original return value from AccessImpersonateCheckRpcClient
        cmp eax, 5              
; check if access denied(5) was returned
        jne CONTINUE_2          
; return value is not 5, continue with
                                 ; normal code execution
        mov word[rcx], 0        
; else set ServerHost to NULL. Result: DFSNM
                                 ; SessionError: code: 0x57 -
ERROR_INVALID_PARAMETER
                                 ; continue with original code
    CONTINUE_2:
       
    code_end
patchlet_end

 


Micropatch Availability

While this vulnerability has no official patch and could be considered a "0day", Microsoft seems determined not to fix relaying issues such as this one; therefore, this micropatch is not provided in the FREE plan but requires a PRO or Enterprise license.

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

  1. Windows Server 2008 R2
  2. Windows Server 2012
  3. Windows Server 2012 R2
  4. Windows Server 2016
  5. Windows Server 2019 
  6. Windows Server 2022 
 
Note that only servers are affected as the DSS Service does not exist on workstations.

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). 

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  Filip Dragovic for sharing details about this vulnerability, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.

 

Changes in 0patch Pricing For New Subscriptions Coming in August

27 July 2022 at 09:21

Over the years, 0patch has evolved from a simple proof-of-concept into a production-grade security service protecting computers around the World. We've been adding features and improving reliability, we have developed tools and processes to speed up vulnerability analysis and patch development, and we still have many ideas and plans to implement.

What was initially met with various skeptical remarks has now become a standard for protecting Windows computers in our customers' organizations who use 0patch both for keeping their legacy systems secure from old and new exploits, and for blocking 0day attacks while others are still waiting for original vendor fixes. We're happy to see our customers expanding their 0patch deployments and spreading the word to their peers.

To reflect the increased value and support further innovation and growth of our team, we're announcing our first price increase since our launch in 2019. This change, having been advertised on our pricing page for months, will go into effect on August 1, 2022, and will only apply to new subscriptions that get created on or after August 1, 2022; any existing subscriptions (including trials) will remain on the old pricing as long as they're renewed in time.

0patch PRO: Price of a PRO license will be increased for 2 EUR/year to 24,95 EUR/year (increase of 0,20 EUR/month).

0patch Enterprise: Price of an Enterprise license will be increased for 12 EUR/year to 34,95 EUR/year (increase of 1,20 EUR/month). We have until now offered Enterprise features for no extra charge but it's time to detach Enterprise pricing from PRO pricing to reflect the added value of Enterprise features.


Our mission has always been to help our users neutralize critical vulnerabilities in a low-effort, low-risk and affordable way before attackers start exploiting them. We remain committed to this mission and attentive to users' feedback when prioritizing new features that will make their work easier and their environments more secure.


Frequently Asked Questions


Is our current subscription going to be affected by this change?
No, existing subscriptions will remain on the old rates as long as they're renewed. Only newly created subscriptions will fall under the new price list.

Can we still change the number of licenses in our subscription while staying on the old rates?
Yes, you can do that - just make sure to keep the "Legacy" plan selected when modifying the subscription instead of selecting "PRO" or "Enterprise" plan, which use the new rates. 

As your existing partner - reseller or MSP - do we keep the old rates for existing customers' subscriptions?
Absolutely, as long as their subscriptions get renewed in time.

Can we just create a single-license subscription before August 1, and then increase license quantity later as needed to stay on the old prices?
Yes you can, you clever rascal, but hurry up!

Micropatches For "KrbRelay" Local Privilege Escalation Vulnerability (Wontfix/0day)

10 August 2022 at 15:42


 

by Mitja Kolsek, the 0patch Team


Update 10/21/2022: Microsoft silently fixed this issue with October 2022 Updates. No CVE ID was assigned.

"KrbRelay" is a tool for forced authentication issue in Windows that can be used by a low-privileged domain user to take over a Windows computer, potentially becoming a local or domain admin within minutes. The tool, based on James Forshaw's research, was developed by security researcher cube0x0, and was later wrapped by Mor Davidovich into another tool called "KrbRelayUp" that further automated attack steps for escalating privileges.

KrbRelay provides various options to launch different versions of attack; some of these options were already known under the name RemotePotato0, for which we already had patches before. What was new for us with KrbRelay was its capability to launch a local service (running in session 0) via RPC and exploit it for leaking Local System credentials through forced authentication. In order to be exploitable, a service must allow authentication over the network, and just two such services were identified on affected Windows versions:

  1. ActiveX Installer Service, identified by CLSID 90f18417-f0f1-484e-9d3c-59dceee5dbd8; and
  2. RemoteAppLifetimeManager.exe, identified by CLSID 0bae55fc-479f-45c2-972e-e951be72c0c1.


Microsoft does not fix forced authentication issues unless an attack can be mounted anonymously. Our customers unfortunately can't all disable relevant services or implement mitigations without breaking production, so it is on us to provide them with such patches.

For the purpose of identifying vulnerabilities we decided to name the vulnerability exposing the above services "KrbRelay", as other attack vectors provided by the tool were already blocked by our existing patches for RemotePotato0. We decided to inject our patch logic at the point where a local unprivileged attacker launches the exploitable service, because such patch would be fairly simple - and we like it simple: it's harder to make mistakes.

Our patch, source code shown below, resides in rpcss.dll and checks whether someone is trying to launch one of the above services via RPC; in such case, if the requestor's token is elevated, we allow it, otherwise not. This is the same approach as we used with patching RemotePotato0.



MODULE_PATH "..\Affected_Modules\rpcss.dll_10.0.17763.3113_Srv2019_64-bit_u202207\rpcss.dll"
PATCH_ID 992
PATCH_FORMAT_VER 2
VULN_ID 7416
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x6674
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT Advapi32.dll!GetTokenInformation,ntdll!_strnicmp,rpcss.dll!0x68ccd
    ; memory representation:    17 84 f1 90 f1 f0 4e 48 9d 3c 59 dc ee e5 db d8
    ; clsid:                    90f18417-f0f1-484e-9d3c-59dceee5dbd8

    code_start
        call VAR                       
        dd 0x90f18417                 ; CIeAxiInstallerService Class
        dw 0xf0f1, 0x484e
        db 0x9d, 0x3c, 0x59, 0xdc, 0xee, 0xe5, 0xdb, 0xd8
    VAR:
        pop rcx                       ; rcx => clsid in memory respresentation
        mov rdx, [rbx]                ; ClientToken hadle
        mov r8, 16                    ; length to compare
        call PIT__strnicmp            ; Compares the specified number of characters
                                      ; of two strings without regard to case
        cmp rax, 0                    ; rax == 0 string are equal
        jne CONTINUE                  ; if rax != 0 continue normal code flow

        mov rdx, [rbx+8]
        mov rdx, [rdx]
        mov rcx, [rdx+40h]            ; current session token, TokenHandle
        mov rdx, 14h                  ; TokenInformationClass, TokenElevation
        sub rsp, 30h                  ; home space + vars
        lea r8, [rsp+30h]             ; TokenInformation
        mov qword[rsp+30h], 0         ; memset
        mov r9, 4                     ; TokenInformationLength
        lea rax, [rsp+28h]            ; ReturnLength address
        mov [rsp+20h], rax            ; pointer to address
        call PIT_GetTokenInformation  ; The GetTokenInformation function retrieves a
                                      ; specified type of information about an access token
        add rsp, 30h                  ; restore stack pointer
        cmp byte[rsp], 0              ; token elevated?
        je PIT_0x68ccd                ; if elevated(1) continue normal code flow

    CONTINUE:
       
    code_end
patchlet_end


 

Micropatch Availability

While this vulnerability has no official vendor patch and could be considered a "0day", Microsoft seems determined not to fix relaying issues such as this one; therefore, this micropatch is not provided in the FREE plan but requires a PRO or Enterprise license.

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

  1. Windows 10 v21H2
  2. Windows 10 v21H1
  3. Windows 10 v20H2
  4. Windows 10 v2004
  5. Windows 10 v1909
  6. Windows 10 v1903
  7. Windows 10 v1809
  8. Windows 10 v1803
  9. Windows 7 (no ESU, ESU year 1, ESU year 2)
  10. Windows Server 2008 R2 (no ESU, ESU year 1, ESU year 2)
  11. Windows Server 2012
  12. Windows Server 2012 R2
  13. Windows Server 2016
  14. Windows Server 2019 
  15. Windows Server 2022 
 
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). 

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 and cube0x0 for sharing details about this vulnerability and sharing a tool, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.

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

31 August 2022 at 15:51

 


 

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.

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

8 September 2022 at 13:05

 

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.

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

14 September 2022 at 13:21

 

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 Kerberos Elevation of Privilege (CVE-2022-35756)

30 September 2022 at 11:14

 


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

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.


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

5 October 2022 at 12:45

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

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.


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

12 October 2022 at 11:50

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 it 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 [email protected] 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: How can I keep using Windows 7 or Server 2008 R2 when all major browsers will stop receiving security fixes in January 2023?

A: We will security-adopt 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. 

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

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

17 October 2022 at 13:44

 

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








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

25 October 2022 at 22:02


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

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.



 

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

26 October 2022 at 19:28

 

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

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.

Free Micropatches For Bypassing MotW Security Warning with Invalid Signature (0day, now CVE-2022-44698 and CVE-2023-24880)

28 October 2022 at 19:52

by Mitja Kolsek, the 0patch Team

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: 

  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 Remote Code Execution in Windows Enterprise App Management Service (CVE-2022-35841)

1 December 2022 at 17:21


 

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.

Microsoft assigned this vulnerability CVE-2022-35841.

Our micropatches were written for the following 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
 
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 [email protected].

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.



 

Micropatches for Type Confusion in Internet Explorer's JScript9 Engine (0day, now CVE-2022-41128)

19 December 2022 at 17:45


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.

Benoît Sevens and Clément Lecigne of Google's Threat Analysis Group (TAG) have written a very good analysis of this vulnerability including a minimized proof of concept. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.

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:



MODULE_PATH "..\Affected_Modules\jscript9.dll_11.0.9600.19597_Win7_64-bit_NoESU\jscript9.dll"
PATCH_ID 1192
PATCH_FORMAT_VER 2
VULN_ID 7598
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2156e
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT jscript9.dll!0x21581
    
    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:

  1. Windows 10 v2004
  2. Windows 10 v1909
  3. Windows 10 v1809
  4. Windows 10 v1803 
  5. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
  6. 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 [email protected].

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.



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

21 December 2022 at 13:35

 

 

This month brought the last security updates for Windows 10 version 21H1. 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, and subsequently Windows 10 v2004 and v1909. Now it wouldn't be fair if we didn't also security-adopt version 21H1.

So we have.

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 [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.

0patch Security-Adopts Microsoft Edge on Windows 7, Server 2008 and Server 2012

5 January 2023 at 22:22

 


As we announced two more years of critical security patches for Windows 7 and Server 2008 R2, users started asking how they could keep browsing web sites securely given that all major browsers (Chrome, Firefox*, Edge, Brave, Vivaldi) would lose support on these Windows versions in January 2023. In addition, even on Windows Server 2012, Edge will stop getting official security updates from Microsoft in January, although the server itself is still supported until October this year - which came as quite a surprise to many organizations. **

(* Anonymous reader correctly noted that Mozilla has not yet made a formal statement on ending Firefox support on these Windows versions.)

(** Sometime between January 17 and 19, Microsoft updated their documentation with "Microsoft Edge version 109 will receive critical security fixes and fixes for known exploit bugs until October 10, 2023 [on Windows Server 2012]")

Microsoft Edge version 109, deployed in the week of January 12, will therefore remain the last Edge version on all these Windows systems, and it will not get any security patches anymore.

... security patches from Microsoft, that is.

We at 0patch have decided to security-adopt Edge version 109 and provide critical security patches for it so you can keep using Windows 7, Server 2008 R2 with Edge in a secure way. With 0patch, you'll also be able to keep using Windows Server 2012 (non-R2 or R2) with Edge securely until their end of official support by Microsoft in October 2023... which is when we'll also security-adopt this server version and you'll be able to keep using it securely even longer.

To have Edge patched by 0patch, do the following:

  1. Let Edge update to version 109 - which should happen automatically as you restart the browser. Make sure your Edge update settings allow updates and to be sure, manually check that you have version 109. (The version will likely be shown as 109.x.xxxx.xx so make sure you see 109 at the beginning.)
  2. Keep the "Download and install updates automatically" setting enabled in case Microsoft decides to provide further updates for some reason. If they do, we will migrate our support to the then-latest version of Edge on these Windows versions without you having to do anything else.
  3. Finally, unless you already have it, install 0patch Agent on all your affected Windows computers and register it to your 0patch account holding a suitable amount of licenses. 

Edge security patches will be part of Pro and Enterprise license, so if you're already using 0patch on your computers, Edge patches will be automatically included for no extra cost.

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 [email protected] and you'll be quickly on your way.

P.S.: We'll also try to remove that "To get future Microsoft Edge updates, you'll need Windows 10 or later." notification that keeps getting displayed in Edge when you launch it. [Update 3/8/2023: Done]


Frequently Asked Questions


Q: How long do you plan to provide critical security patches for Edge?

A: Initially for two more years - until January 2025 -, to match our support for Windows 7 and Server 2008 R2. Depending on the demand, we'll consider a further extension.

Q: Will you patch all vulnerabilities in Edge version 109 that Microsoft patches in the current Edge version?

A:No, just the critical ones that we have sufficient details on. Fortunately, these are the exact vulnerabilities attackers are interested in exploiting.

Q: Will you also keep patching Internet Explorer on all these Windows versions?

A: Yes. Internet Explorer components are a part of Windows operating system and even if Internet Explorer is not being used, its components are often used by other products, for instance Microsoft Office. We will keep considering Internet Explorer as part of Windows and provide critical security patches for all its components.

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].


Micropatching Arbitrary File Delete Vulnerability in Windows Backup Service (CVE-2023-21752)

31 January 2023 at 16:40

 

January 2023 Windows Updates brought a fix for a local privilege escalation vulnerability in Windows Backup Service, discovered and reported by Filip Dragovic. The vulnerability allows a non-admin user on the machine to execute arbitrary code as Local System and thereby take over the computer.

 

The Backup Service

The intended use of the Backup Service is through local user interface of the legacy "Backup and Restore (Windows 7)" component, still existing on all Windows 10 and Windows 11 computers. A privileged user launches Backup and Restore, selects the backup destination and what they want to backup, and starts or schedules a backup. The destination can either be a local drive or a network path, and in the latter case, network credentials have to be supplied as well. The Backup Service uses these credentials for accessing the network share.


The Vulnerability

The vulnerability lies in the way Windows Backup Service tries to determine whether the user whose credentials were supplied has write access on the chosen destination or not. Specifically, the service attempts to create a temporary, randomly-named file on the destination path using these credentials; if this fails, the path is considered non-writable and the backup procedure can't continue, but if temporary file creation succeeds, the file is immediately deleted and the backup procedure can continue as the path is confirmed to be writable.

Now, the process of creating and deleting this temporary file is vulnerable to a TOCTOU symbolic link attack. As Filip has demonstrated, a local low-privileged attacker can trigger the backup process with some path under their control, catch the temporary file which the Backup Service creates (and hold it locked), replace it with a symbolic link to some system file they could not otherwise delete, and let the Backup Service continue with deleting said system file. This results in the service deleting a chosen file, which can be exploited for 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. Filip's POC makes use of the latter.

But, one could reasonably ask, why does the Backup Service use its own Local System identity instead of user-supplied credentials for creating and deleting the temporary file? Well, it turns out that user-supplied credentials are indeed used for network paths pointing to other computers - but when a share on the same computer is used (such as \\127.0.0.1\C$, the computer's administrative share), the service keeps using its own identity, i.e. Local System.


Microsoft's Patch

Microsoft's patch for this vulnerability introduced a completely redesigned test for path writability, whereby a temporary file is created using the FILE_FLAG_DELETE_ON_CLOSE flag. This flag makes sure that the file, if created, would get automatically deleted when closed - making this entire test an atomic operation from the perspective of TOCTOU shenanigans.


Our Micropatch

Our micropatch is logically identical to Microsoft's, but to minimize its complexity and code size we opted for a simpler naming of the temporary file: we start with creating a file 0patchTMP_A.tmp, then failing that continue with 0patchTMP_B.tmp, and so on until 0patchTMP_Z.tmp. If any of these files can be created, the path is considered writable, otherwise it is considered unwritable.

This is to accommodate multiple backup processes using the same path at the same time, which is unlikely but not impossible. One might think that an attacker could create files 0patchTMP_A.tmp through 0patchTMP_Z.tmp on the backup path to trick our patch into thinking the path was unwritable, but then again, if the attacker has write access to your backup location, no patch is going to save you.

Let's see our micropatch in action. With 0patch disabled, Filip's POC can delete a file on the root of C: drive by exploiting the described vulnerability. With 0patch enabled and our micropatch in place, the vulnerability is no longer there and the same file does not get deleted.




Micropatch Availability

The micropatch was written for the following 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 (no ESU, ESU years 1 and 2)
  7. Windows Server 2008 R2 (no ESU, ESU years 1 and 2)
 
Note that Windows 7 and Server 2008 R2 with ESU year 3 have received Microsoft's patch with January Updates.

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). 

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  Filip Dragovic for sharing details about this vulnerability, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.

 

Micropatching the "LocalPotato" NTLM Elevation of Privilege (CVE-2023-21746)

9 February 2023 at 17:38

 

January 2023 Windows Updates brought a fix for CVE-2023-21746, a local privilege escalation vulnerability in Windows, called "LocalPotato" by its discoverers  Andrea Pierini and Antonio Cocomazzi. Its name is in reference to many other "potato" vulnerabilities that have been discovered in Windows since 2014 when James Forshaw of Google Project Zero published their analysis of Local WebDAV NTLM Reflection.

The potato vulnerability at hand, "LocalPotato", was reported to Microsoft by Andrea and Antonio and will, now that the official fix has been available for a month, soon be published at https://www.localpotato.com/.

While still-supported Windows systems have already received the official vendor fix for this vulnerability (assuming admins have applied the January 2023 Windows Update), there are many 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.

Let's see our micropatch in action. With 0patch disabled, the POC launched by a low-privileged user creates a file localpotato.exe in C:\Windows folder. (Of course this means that any other file could have been created, including a DLL that some high-privileged process would gladly load and run code from.) With 0patch enabled, the attack is blocked and no file is created.




Micropatch Availability

The micropatch was written for the following 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 (no ESU, ESU years 1 and 2)
  7. Windows Server 2008 R2 (no ESU, ESU years 1 and 2)
 
Note that Windows 7 and Server 2008 R2 with ESU year 3 have received Microsoft's patch with January Updates.

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 Andrea Pierini and Antonio Cocomazzi for sharing their POC with us which allowed us to create a micropatch before details were released to the public. We also encourage other 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.

 

 

 

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.

 

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.

 

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 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.

 

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.

 

❌
❌