by Mitja Kolsek, the 0patch Team

May 2021 Windows Updates brought a fix for an "Exploitation More Likely" memory corruption vulnerability in Scripting Engine (CVE-2021-26419) discovered by Ivan Fratric of Google Project Zero. Ivan published details and a proof-of-concept the next day, and we took these to reproduce the vulnerability in our lab and create a micropatch for it.

Since Microsoft's patch was available, we reviewed it and found they only changed function ByteCodeGenerator::LoadCachedHeapArguments such that instead of calling ByteCodeGenerator::EmitPropStore, it now calls ByteCodeGenerator::EmitLocalPropInit.These are undocumented and largely unknown functions but their names imply the vulnerability resides in just-in-time compiler's code generation logic, where the generated code gets an improper level of access to the arguments object.

Our micropatch is logically identical to Microsoft's:

See the micropatch in action:

by Mitja Kolsek, the 0patch Team

June 2021 Windows Updates brought a fix for another "Exploitation More Likely" memory corruption vulnerability in Scripting Engine (CVE-2021-26419) discovered by Ivan Fratric of Google Project Zero, very similar to this vulnerability discovered also discovered by Ivan and patched in May.

Ivan published details and a proof-of-concept three days ago and we took these to reproduce the vulnerability in our lab and create a micropatch for it.

Since Microsoft's patch was available, we reviewed it and found their patch for it in function ByteCodeGenerator::EmitScopeObjectInit, which Ivan also identified as the source of the flaw. An initialization loop was added to this function to initialize all members of the PropertyID array.

Our micropatch is logically identical to Microsoft's:

See the micropatch in action:

by Mitja Kolsek, the 0patch Team

Update 8/11/2021: August 2021 Windows Updates brought a fix for PrintNightmare that has the same default effect as our micropatch, although with a different implementation; therefore our micropatch is no longer free but available with a 0patch PRO license.

Update 7/16/2021: We've ported and issued our PrintNightmare patches for Windows computers that have July 2021 Windows Updates installed (which we do recommend). Our patches prevent exploitation of PrintNightmare even if computer settings render Microsoft's patch ineffective, as described by Will Dormann's diagram. These patches remain free for now.

Update 7/15/2021: July Patch Tuesday patches included the same PrintNightmare fix as the July 6 out-of-band Windows Update, with Microsoft stating that it properly resolves the vulnerability. As this diagram shows, two configuration options that aren't inherently security-related can make the system vulnerable to at least local - but likely also remote - attack, so we're going to port our patches to at least July Windows Updates while we continue to assess the situation. Since July Windows Updates also brought fixes for various other vulnerabilities, we recommend applying them to keep your computers fully up-to-date.

Update 7/7/2021: Microsoft has issued an out-of-band update for the PrintNightmare vulnerability, but the next day this update was found to be ineffective for both local and remote attack vectors. The update does, however, modify localspl.dll on the computer, which means that our existing patches stop getting applied to this module if the update is installed. In other words, if you used 0patch to protect your computers against PrintNightmare, applying the July 6 update from Microsoft makes you vulnerable again. Since we expect Microsoft to issue another modification to localspl.dll next week on Patch Tuesday, we decided not to port our patches to the July 6 version of localspl.dll but rather wait and see what happens next week. Consequently, we recommend NOT INSTALLING the July 6 Windows update if you're using 0patch.

Update 7/5/2021: Security researcher cube0x0 discovered another attack vector for this vulnerability, which significantly expands the set of affected machines. While the original attack vector was Print System Remote Protocol [MS-RPRN], the same attack delivered via Print System Asynchronous Remote Protocol [MS-PAR] does not require Windows server to be a domain controller, or Windows 10 machine to have UAC User Account Control disabled or PointAndPrint NoWarningNoElevationOnInstall enabled. Note that our patches for Servers 2019, 2016, 2012 R2 and 2008 R2 issued on 7/2/2021 are effective against this new attack vector and don't need to be updated.

Introduction

June 2021 Windows Updates brought a fix for a vulnerability CVE-2021-1675 originally titled "Windows Print Spooler Local Code Execution Vulnerability". As usual, Microsoft's advisory provided very little information about the vulnerability, and very few probably noticed that about two weeks later, the advisory was updated to change "Local Code Execution" to "Remote Code Execution".

This CVE ID would probably remain one of the boring ones without a surprise publication of a proof-of-concept for a remote code execution vulnerability called PrintNightmare, indicating that it was  CVE-2021-1675. Security researchers Zhiniang Peng and Xuefeng Li, who published this POC, believed that their vulnerability was already fixed by Microsoft, and saw other researchers slowly leaking details, so they decided to publish their work as well.

It turned out that PrintNightmare was not, in fact, CVE-2021-1675 - and the published details and POC were for a yet unpatched vulnerability that turned out to allow remote code execution on all Windows Servers from version 2019 back to at least version 2008, especially if they were configured as domain controllers.

The security community went scrambling to clear the confusion, identify conditions for exploitability, and find workarounds in absence of an official fix from Microsoft. Meanwhile, PrintNightmare started getting actively exploited, Microsoft has confirmed it to be a separate vulnerability to CVE-2021-1675, assigned it CVE-2021-34527, and recommended that affected users either disable the Print Spooler service or disable inbound remote printing.

In addition to Microsoft's recommendations, workarounds gathered from the community included removing Authenticated Users from the "Pre-Windows 2000 Compatible Access" group, and setting permissions on print spooler folders to prevent the attack.

All these mitigations can have unwanted and unexpected side effects that can break functionalities in production (1, 2, 3), some including those unrelated to printing.

Patching the Nightmare

Long story short, our team at 0patch has analyzed the vulnerability and created micropatches for different affected Windows versions, starting with those most critical and most widely used:

1. Windows Server 2019 (updated with June 2021 Updates)
2. Windows Server 2016 (updated with June 2021 Updates)
3. Windows Server 2012 R2 (updated with June 2021 Updates)
4. Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates) 
5. Windows 10 v21H1 (updated with June 2021 Updates)
6. Windows 10 v20H2 (updated with June 2021 Updates)
7. Windows 10 v2004 (updated with June 2021 Updates) 
8. Windows 10 v1909 (updated with June 2021 Updates) 
9. Windows 10 v1903 (updated with December 2020 Updates - latest before end of support)
10. Windows 10 v1809 (updated with May 2021 Updates - latest before end of support)
11. Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)
12. Windows 10 v1709 (updated with October 2020 Updates - latest before end of support)
13. Windows 7 (updated with January 2020 Updates, no Extended Security Updates) 
    

[Note: Additional patches will be released as needed based on exploitability on different Windows platforms.]

Our micropatches prevent the APD_INSTALL_WARNED_DRIVER flag in dwFileCopyFlags of function AddPrinterDriverEx from bypassing the object access check, which allowed the attack to succeed. We believe that "install warned drivers" functionality is not a very often used one, and breaking it in exchange for securing Windows machines from trivial remote exploitation is a good trade-off.

Our PrintNightmare patch only contains one single instruction, setting the rbx register to 1 and thus forcing the execution towards the code block that performs said object access check.

MODULE_PATH "..\Affected_Modules\localspl.dll_10.0.19041.1052_64bit_Win10-20H2-u202106\localspl.dll"
PATCH_ID 622
PATCH_FORMAT_VER 2
VULN_ID 7153
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x8f5da
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 8
    
    code_start
        mov ebx, 1       
    code_end
patchlet_end
   

Or as we see it in IDA Pro (green code block is injected by 0patch, grey is the original code that had to be moved in order to inject a jmp instruction in its place to jump to the patch).

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're still offering a free upgrade to Enterprise so any PRO user can request Enterprise features by contacting [email protected].

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

Release Notes

• "Hash caching" was introduced to significantly reduce the amount of CPU and disk I/O operations when calculating cryptographic hashes of executable modules as these are loaded in running processes. Before, hash calculation was causing performance problems for some users on Citrix and Terminal Servers.
• Huge log files are a thing of the past. We have implemented a mechanism to keep log sizes limited, with these limits configurable via registry.
• 0patch Agent used to have the default Windows API behavior when it comes to using SSL/TLS versions, which was causing problems for users requiring TLS 1.1 or 1.2 on older Windows systems and required manual configuration. The new agent supports TLS 1.1 and 1.2 even on older systems such as Windows 7 or  Server 2008 R2 by default.
  
• 0patch Console no longer crashes if launched while another instance of 0patch Console is already running. Now, launching a second 0patch Console puts the already running console in the foreground.
• 0patch Console's registration form had "SIGN UP FOR A FREE ACCOUNT" and "FORGOT PASSWORD" links swapped. This has been corrected.
• With 0patch FREE, some notifications occasionally failed to get closed and were left hovering indefinitely, making it impossible for users to reach the screen area behind them. This has been corrected.

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 various anti-virus products seem to detect the new agent as malicious and block its installation or execution. Specifically, Kaspersky detects the MSI installer package as malicious (preventing installation and update), while Avast and AVG detect 0patchServicex64.exe as malicious (preventing proper functioning of the agent). We recommend marking these as false positives, restoring quarantined files and making an exception for these files if affected.

by Mitja Kolsek, the 0patch Team

[Update 9/15/2021: September 2021 Windows Updates fixed this vulnerability in effectively the same way our micropatch did. The issue was assigned CVE-2021-36958]

[Update 8/11/2021: August 2021 Windows Updates did not fix this vulnerability. We're therefore porting our micropatch to the August versions of executables.]

With PrintNightmare vulnerability still echoing (and still without a complete official fix, in our view), another printing-related issue was found by security researcher Benjamin Delpy that allows a local unprivileged user on a Windows machine to execute arbitrary code as System by installing a malicious printer driver.

In essence, the attacker sets up a printer with a modified driver on a machine they control, and then installs this printer using Point and Print on another Windows computer, gaining full control of said computer. While generally considered a local privilege escalation, this issue could also be used in conjunction with some social engineering to get a remote attacker's code executed on user's machine.

The issue is nicely described in this CERT/CC vulnerability note written by Will Dormann. While Windows have been requiring printer driver packages installed via Point and Print to be signed by a trusted source since 2016, Benjamin discovered that additional executable files can be included in such installation outside the signed package, and these would then be automatically loaded (and their code executed) by the Print Spooler service running as System.

How To Fix This?

In contrast to, say, memory corruption bugs or numeric overflows, this is not a trivial issue to fix; adding signature requirement to queue-specific files would require a lot of code and would be incompatible with the "micro" in micropatching. Disabling the transfer of queue-specific files could do the trick, but might result in confused users when installed printers would suddenly behave differently than before without any notification or warning.

We therefore decided to implement the group policy-based workaround as a micropatch, blocking Point and Print printer driver installation from untrusted servers. This workaround employs Group Policy settings: the "Only use Package Point and Print" first requires every printer driver is in form of a signed package, while the "Package Point and print - Approved servers" limits the set of servers from which printer driver packages are allowed to be installed.

These settings are configurable via registry. Our patch modifies function DoesPolicyAllowPrinterConnectionsToServer in win32spl.dll such that it believes that PackagePointAndPrintOnly and PackagePointAndPrintServerList values exist and are set to 1, which enables both policies and keeps the list of approved servers empty.

Of course, if one has not previously configured Point and Print-related group policy settings, our patch breaks Point and Print driver installation because no servers are approved. On the other hand, on computers which already have these policies enabled, our patch has no effect. The reasoning behind our approach was that many Windows users and admins don't even know they're affected by this issue and just having 0patch installed will automatically resolve this vulnerability for them.

Our micropatch has four tiny patchlets:

And the video of our patch in action:

This micropatch was written for:

1. Windows Server 2019 (updated with July 2021 Updates)
2. Windows Server 2016 (updated with July 2021 Updates)
3. Windows Server 2012 R2 (updated with July 2021 Updates)
4. Windows Server 2012 (updated with July 2021 Updates)
5. Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates) 
6. Windows Server 2008 R2 (updated with January 2021 Updates, first year of Extended Security Updates only) 
7. Windows Server 2008 R2 (updated with July 2021 Updates, second year of Extended Security Updates) 
8. Windows 10 v21H1 (updated with July Updates)
9. Windows 10 v20H2 (updated with July Updates)
10. Windows 10 v2004 (updated with July Updates) 
11. Windows 10 v1909 (updated with July Updates) 
12. Windows 10 v1903 (updated with December 2020 Updates - latest before end of support)
13. Windows 10 v1809 (updated with May 2021 Updates - latest before end of support) 
16. Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)
    
17. Windows 10 v1709 (updated with October 2020 Updates - latest before end of support)
18. Windows 7 (updated with January 2020 Updates, no Extended Security Updates)
19. Windows 7 (updated with January 2021 Updates, first year of Extended Security Updates only)
20. Windows 7 (updated with July 2021 Updates, second year of Extended Security Updates)
    

Micropatches for this vulnerability will be free until Microsoft has issued an official fix. If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.

Compatibility note: Some Windows 10 and Server systems exhibit occasional timeouts in the Software Protection Platform Service (sppsvc.exe) on a system running 0patch Agent. This looks like a bug in Windows Code Integrity mitigation that prevents a 0patch component to be injected in the service (which is okay) but sometimes also does a lot of seemingly meaningless processing that causes process startup to time out. As a result, various licensing-related errors can occur. The issue, should it occur, can be resolved by excluding sppsvc.exe from 0patch injection as described in this article.

What to do if the patch breaks printing?

If printing in your network utilizes Point and Print, our patch can cause problems such as users being unable to print to their printers or even seeing them on a network share. If this happens, we recommend adding servers hosting your printers to the approved server list as follows:

1. Launch mmc.exe as administrator
2. Select File -> Add/Remove Snap-in
3. Add "Group Policy Object Editor"
4. Under Computer Configuration -> Administrative Templates -> Printers, open the "Package Point and print - Approved servers" policy
5. Enable the policy, click the "Show" button, and add the servers your printers are on to the list

Credits

We'd like to thank Benjamin Delpy for sharing details about this vulnerability, and Will Dormann and Kevin Beaumont for sharing lots of useful insights and context that helped us create this micropatch and protect 0patch users.

Please revisit this blog post for updates or follow 0patch on Twitter.

by Mitja Kolsek, the 0patch Team

Update 8/11/2021-A: August 2021 Windows Updates brought a fix for PetitPotam, which, in contrast to our patch that fixes an impersonation issue and keeps EfsRpcOpenFileRaw request functional, disables the EfsRpcOpenFileRaw request. CVE-2021-36942 was assigned to this vulnerability. More details below in the Microsoft's Patch section.

Update 8/11/2021-B: Neither Microsoft's August fix nor our micropatch seem to have covered all PetitPotam affected code. Both fixed the anonymous attack vector but we're investigating additional authenticated paths now and looking for the best way to patch that too. The most effective PetitPotam mitigation currently remains this RPC filter on all Domain Controllers, although it may be an overly broad measure and could break something, so proceed with caution.  

Update 8/19/2021: After further analysis of additional PetitPotam attack vectors, we created additional micropatches that block all these vectors. Today's PetitPotam patches are written for executables from August 2021 Windows Updates, which means you have to have these updates installed (i.e., fully updated Windows as of this writing) in order to have them applied. 

Update 9/15/2021: September 2021 Windows Updates did not bring any changes regarding the new PetitPotam attack vectors, so our micropatches remain free.

Update 12/21/2021: Microsoft provided an official fix for this issue on December 14, which addresses the remaining attack vectors. Our associated micropatches thus ceased being free and now require a PRO license.

Update 6/27/2022: While Microsoft only fixed the anonymous attack vector, we decided to also address the authenticated attack vector. We therefore ported our patches for this issue to current versions of supported Windows platforms. Given that Microsoft does not plan to patch authenticated credentials relaying issues, these patches are now available only to PRO and Enterprise accounts.

Wow, we're busy these days. Just yesterday we issued micropatches for the "Malicious Printer Driver" 0day, and today we're fixing a critical remote code execution issue that allows an anonymous attacker to take over a Windows Domain Controller: the infamous "PetitPotam" bug.

PetitPotam was discovered by security researcher topotam, who published their proof-of-concept on Github on July 20, 2021. There is no official vendor patch for it at the time of this writing; in fact, Microsoft's support article implies they do not consider this a vulnerability but rather a mis-configuration, and provides some generic mitigations that do not address the root issue.

As usually, CERT/CC vulnerability note by Will Dormann nicely explains the vulnerability and an exploit chain leading to a complete domain takeover. The main problem is that any user - even anonymous - can force a domain controller to send NTLM credentials of its computer account to attacker's server, where these can be received and then relayed to another service in the domain to make a malicious privileged request.

Analysis

We took a look at what goes on in the code when an EfsRpcOpenFileRaw request is received by the server. It is function  EfsRpcOpenFileRaw_Downlevel in efslsaext.dll that processes this request. This function has most of its code enclosed in an impersonation block between a call to RpcImpersonateClient and a call to RpcRevertToSelf. Code inside this block is being executed under the identity of the requesting entity (in our case, attacker), while code outside executes as Local System, i.e., the computer account.

Unfortunately, function EfsRpcOpenFileRaw_Downlevel, outside the impersonation block, makes a call to EfsGetLocalFileName, which tries to open the attacker-supplied UNC path. By doing so, it sends local computer's NTLM credentials inside the SMB request to the remote network share. If the attacker is waiting on the other end, they get these credentials.

Let's take a look at relevant parts of function EfsRpcOpenFileRaw_Downlevel:

Beginning of function EfsRpcOpenFileRaw_Downlevel, with the call to EfsGetLocalFilename being called without impersonation

Continuation of function EfsRpcOpenFileRaw_Downlevel

Note that only this call to EfsGetLocalFileName is non-impersonated, while core EFSRPC functionality executes under requester's identity. This means that anonymous or unprivileged user cannot remotely execute EFSRPC functions such as reading or creating arbitrary network files.

Micropatch

Our micropatch extends the impersonation block such that it now encloses the previously un-impersonated call to EfsGetLocalFileName; as a result, the SMB request which this function triggers contains attacker's NTLM credentials instead of computer account's. Therefore, in case of an anonymous request the attacker gets credentials of the ANONYMOUS LOGON user (which are of no use), and if they use credentials of a Windows domain user, the acquired NTLM credentials will be of that same user (which they already have).

The patch contains two patchlets, one starting impersonation by calling RpcImpersonateClient,  and another stopping impersonation by calling RpcRevertToSelf.

Let's look at the difference between running the PetitPotam tool against a fully updated Windows Server without and with 0patch.

Without 0patch

Let's see which user executes the call to EfsGetLocalFileName:

As expected, it's Local System. And the PetitPotam tool, chained with Active Directory Certificate Server produces domain controller's certificate:

With 0patch

Let's see which user executes the call to EfsGetLocalFileName this time:

Good, it's the Anonymous Logon user, which is useless to the attacker. Consequently, the PetitPotam attack doesn't work anymore:

Patch Availability

This micropatch was written for:

1. Windows Server 2019 (updated with July 2021 Updates)
2. Windows Server 2016 (updated with July 2021 Updates)
3. Windows Server 2012 R2 (updated with July 2021 Updates)
4. Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates) 
   

Our tests indicate that Windows Server 2012 (non R2), Windows Server 2008 (non R2) and Windows Server 2003 are not affected by this issue.

Micropatches for this vulnerability are, as always, automatically downloaded and applied to all affected computers (unless your policy prevents that), and will be free until Microsoft has issued an official fix. If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.

Compatibility note: Some Windows 10 and Server systems exhibit occasional timeouts in the Software Protection Platform Service (sppsvc.exe) on a system running 0patch Agent. This looks like a bug in Windows Code Integrity mitigation that prevents a 0patch component to be injected in the service (which is okay) but sometimes also does a lot of seemingly meaningless processing that causes process startup to time out. As a result, various licensing-related errors can occur. The issue, should it occur, can be resolved by excluding sppsvc.exe from 0patch injection as described in this article.

Update 8/19/2021: Microsoft's August 2021 updates brought a functionally similar fix as our micropatch, but since other attack vectors were subsequently discovered, we have issued additional micropatches that apply on top of August 2021 Windows executables. In order to use them, you have to have August 2021 Windows Updates applied. In addition, we have found Windows Server 2012 to be affected to these additional vectors and have also covered this Windows version with our new micropatches.

[Update 8/11/2021: added section Microsoft's Patch]

Microsoft's Patch

August 2021 Windows Updates brought Microsoft's official fix for this issue. The associated documentation states: "The EFS API OpenEncryptedFileRaw(A/W), often used in backup software, continues to work in all versions of Windows (local and remote), except when backing up to or from a system running Windows Server 2008 SP2. OpenEncryptedFileRaw will no longer work on Windows Server 2008 SP2. Note: If you are unable to use backup software on Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1 and later, after installing the updates that address this CVE, contact the manufacturer of your backup software for updates and support."

 Let's take a look at this fix.

Microsoft's fix is in the same function as our micropatch ( EfsRpcOpenFileRaw_Downlevel in efslsaext.dll), but it sabotages the function so it doesn't work anymore. We actually also sometimes sabotage an entire function if it seems that could affect such a small amount of users that the benefits would outweigh the risk. In fact, we were initially inclined to do it here too as we were unable to find any backup product or mechanism that would be using this function - but then decided to rather fix the obvious bug we had noticed, and keep the function "alive".

Note that Microsoft's fix also includes a hidden undocumented feature: instead of outright sabotaging OpenEncryptedFileRaw, the fix checks an undocumented registry value AllowOpenRawDL (DWORD) under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EFS; if this value exists and is equal to 1, OpenEncryptedFileRaw works as before. Therefore, if Microsoft's fix broke your backup, you can disable it using this value, but doing so will make you vulnerable to the PetitPotam attack.

We find this Microsoft's fix to be appropriate and therefore do not plan to port our PetitPotam micropatch to the August 2021 version of efslsaext.dll unless 0patch users come complaining the fix broke their backup. We also invite any Windows users whose backup got broken by August 2021 Windows Update to contact us at [email protected].

Update 8/11/2021: Neither Microsoft's August fix nor our micropatch seem to have covered all PetitPotam affected code. Both fixed the anonymous attack vector but we're investigating additional authenticated paths now and looking for the best way to patch that too. 

Update 8/19/2021: Our new micropatches released today address these additional attack vectors.

Credits

We'd like to thank topotam for sharing details about this vulnerability, and Will Dormann, Benjamin Delpy and Kevin Beaumont for sharing lots of useful insights and context that helped us understand this vulnerability and create this micropatch to protect users.

Please revisit this blog post for updates or follow 0patch on Twitter.

by Mitja Kolsek, the 0patch Team

June 2021 Windows Updates brought a fix for CVE-2021-33742, a remote code execution in the MSHTML component, exploitable via Microsoft browsers and potentially other applications using this component, e.g. via a malicious Microsoft Word document. Discovery of this issue was attributed to Clément Lecigne of Google’s Threat Analysis Group, while Google's security researcher Maddie Stone wrote a detailed analysis. A short proof-of-concept (see Maddie's article) that causes access violation in the browser was written by Ivan Fratric of Google Project Zero.

Our tests showed that out of the Windows versions that we have "security adopted", we were only able to reproduce the vulnerability on Windows 10 v1803 and v1809, so these were the ones we wanted to create a micropatch for.

After reproducing the vulnerability, we looked at Microsoft's patch to see if we could do something similar for the two affected Windows 10 versions that haven't received the official vendor fix.

As seen on the above image, Microsoft has just added a check to see if the user-influenced value (size of TextData element) that caused memory corruption was greater than 0x1FFFFFFF. If so, it triggers an assertion and effectively crashes the process without trying to resolve the situation. This is a bit unusual as it implies that either (a) Microsoft found it extremely difficult to fix this issue at some root level, issue a JavaScript exception and keep the process running, or (b) they wanted to get this over with quickly because Internet Explorer is hardly supported anymore and MSHTML, while still being used by other applications such as Microsoft Word, is not a critical component for their most important customers.

Be it as it may, our micropatch does the same as looking for a better fix could take us down a rabbit hole for a long time. However, it also records an "Exploit Blocked" event to the local 0patch log so an attack will leave a trace.

Source code of our micropatch:

And the video of our patch in action. Note that in contrast to a typical micropatch that prevents the process from crashing, this micropatch - doing exactly the same as Microsoft's fix - lets the process crash in a controlled, unexploitable way in case an overly long string is encountered.

This micropatch was written for: 

1. Windows 10 v1809 (updated with May 2021 Updates - latest before end of support) 
2. Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)

Dear 0patch users,

We've listened to you, and now we're delivering some of the features and changes you told us would make your use of 0patch easier. Among them are subscription, billing and payment method management, monthly subscriptions, registering agents directly into groups, faster syncing, no more computer duplicates upon agent re-registration and much more. A detailed list will be published after the server has been updated.

The update will take place on Wednesday, October 20, starting at 8 AM CET and will last for up to 4 hours.

During this time period, the following will apply:

• 0patch Agents will not be able to sync, but will keep applying all patches that have previously been downloaded. The 0patch icon will turn yellow.
• 0patch Central will not be available. Instead, a maintenance page will be shown at https://central.0patch.com, with embedded 0patch Twitter feed with latest announcements.
  
• Registration of new 0patch accounts will not be possible.
• Any purchases made via https://0patch.com web site will result in created subscriptions but notification emails (such as account activation email) will be delayed until the server is back up.
  

Thank you for understanding,

your 0patch Team

[Update: server update was successful, all systems are running normally.]

Last week we updated 0patch Server and 0patch Central, which brought several new features and capabilities. Let's take a quick look at them:

• Subscription management: Users can now manage their subscriptions in 0patch Central, including turning auto-renewal on or off, changing the number of licenses in a subscription, switching between annual and monthly payments, and canceling a subscription. Managed service providers can use the "Renew of one term" feature for renewing a license once their customer has committed to another term.
  
  
• Monthly licenses: Before, 0patch was only available as an annual subscription service. From now on, we also support monthly subscriptions, allowing customers to up-scale and down-scale their license count on a monthly basis according to their needs. (A minimum of 20 licenses is required for a monthly subscription.)
  
  
• Changing billing and payment information: Users can change their billing and payment information in 0patch Central now.
  
  
• Registering agents directly to a group: Enterprise users will like this one; before, all deployed agents appeared in the root All Computers group and had to be manually moved to appropriate groups. Now, each group has its own key which can be used for auto-registration via MSI command-line arguments, allowing admins to bulk-deploy 0patch agent to all computers in some existing group in their central management system, and registered these agents directly to an appropriate group in 0patch Central.
  
  
• Computer comments: Each computer now has a comment field that can be used to provide additional details.
  
  
• License comments: Each license now has a comment field that can be used to provide additional details, a feature most requested from managed service providers and resellers.
  
  
• No more duplicate agents: Before, a re-registration of 0patch Agent on the same computer resulted in a duplicate computer in the Computers list. This is now resolved.

We hope you'll like the new 0patch Central and 0patch user experience. If you run into any issues, please report them to [email protected].

Your 0patch Team

by Mitja Kolsek, the 0patch Team

Update 12/21/2021: December Windows Updates did not bring a fix for this 0day. Our associated micropatches thus remain free.

Update 1/12/2022: January 2022 Windows Updates brought a fix for this issue. Our associated micropatches are now part of the PRO plan.

August 2021 Windows Updates brought a fix for CVE-2021-34484, found and reported by security researcher Abdelhamid Naceri. This vulnerability was considered by Microsoft to be an "arbitrary directory deletion" bug, allowing a locally logged-on attacker to delete a folder on the computer. This, combined with the fact that the attacker must also have credentials of another user who can locally log on to the same computer, made the bug seem fairly uninteresting.

However, Abdelhamid subsequently reviewed Microsotf's fix and found it to be incomplete, bypassable with a small change to the attack script. Furthermore, he confirmed the vulnerability was more impactful than described in Microsoft's advisory, namely enabling local privilege escalation from a regular user to System. Consequently, a write-up and proof of concept were published, which allowed us to analyze the vulnerability and create a micropatch for it. 

The Vulnerability

The vulnerability lies in the User Profile Service, specifically in the code responsible for creating a temporary user profile folder in case the user's original profile folder is damaged or locked for some reason. Abdelhamid found that the process (executed as Local System) of copying folders and files from user's original profile folder to the temporary one can be attacked with symbolic links to create attacker-writable folders in a system location from which a subsequently launched system process would load and execute attacker's DLL.

The crux of the attack is in quickly creating a symbolic link in the temporary user profile folder (C:\Users\TEMP) so that when the User Profile Service copies a folder from user's original profile folder, it will end up creating a folder somewhere else - where the attacker would normally not have permissions to create one.

Microsoft, even though believing the vulnerability only allowed for deletion of an arbitrarily "symlinked" folder, made a conceptually correct fix: it checked whether the destination folder under C:\Users\TEMP was a symbolic link, and aborted the operation if so. The incompleteness of this fix, as noticed by Abdelhamid, was in the fact that the symbolic link need not be in the upper-most folder (which Microsoft's fix checked), but in any folder along the destination path.

Admittedly, this bug was not easy to reproduce, as it requires winning a race condition and that depends on lots of factors. Nevertheless, an actual attacker would have an unlimited number of attempts and would not be dismayed by that. A more significant obstacle for them would be obtaining additional user's credentials, which seem to be needed in order to exploit this vulnerability. As stated by Abdelhamid, "it might be possible to do it without knowing someone else password." but until someone finds a way to do so, we shall assume this to be a requirement.

While this vulnerability already has its CVE ID (CVE-2021-33742), we're considering it to be without an official vendor fix and therefore a "0day".

Our Micropatch

Our micropatch extends the incomplete security check from Microsoft's fix to the entire destination path by calling GetFinalPathNameByHandle and thus resolving any symbolic links it may contain. Then, by comparing the original path and the "resolved" path, it determines whether any symbolic links are present; if not, original code execution is resumed, otherwise the creation of a temporary user profile is aborted.

Our micropatch (green code blocks) injected in the original code of profext.dll.

Source code of our micropatch:

And the video of our micropatch in action. Without the micropatch, exploit works; with the micropatch, corrected code in User Profile Service determines that a destination path contains a symbolic link and aborts the creation of a temporary profile folder.

[Update 11/16/2021: The list below updated with additional supported platforms]

This micropatch was written for: 

1. Windows 10 v21H1 (32 & 64 bit) updated with October or November 2021 Updates
   
2. Windows 10 v20H2 (32 & 64 bit) updated with October or November 2021 Updates
3. Windows 10 v2004 (32 & 64 bit) updated with October or November 2021 Updates
4. Windows 10 v1909 (32 & 64 bit) updated with October or November 2021 Updates
5. Windows 10 v1903 (32 & 64 bit) updated with October or November 2021 Updates
6. Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates
7. Windows Server 2019 64 bit updated with October or November 2021 Updates
8. Windows Server 2016 64 bit updated with November 2021 Updates
   

by Mitja Kolsek, the 0patch Team

This is a story of a publicly known remote code execution vulnerability that somehow got ignored and mostly overlooked for four and a half years, meanwhile rediscovered a number of times, weaponized, and finally fixed this October with an unexpected acknowledgment.

Back in May 2017, security researcher Shay Ber published details about a vulnerability affecting Windows DNS Service. They found that any member of the DNSAdmins domain group can use their privileges to get the computer running the DNS Service to run arbitrary code as Local System - which equals a complete takeover of said computer. Since many domain controllers are running the DNS Service, this could mean a complete Windows domain takeover.

Note that DNSAdmins is a powerful group: being able to change domain DNS configuration allows one to cause all sorts of problems - but it doesn't automatically allow them to take over the domain. Typically, a DNS administrator is not allowed to login to the computer running the DNS Service (often a domain controller), and configures DNS from their own workstation using a DNS management tool that utilizes remote procedure calls (RPC).

Shay noticed that legitimate functionality of these remote procedure calls, conveniently made available by the Windows dnscmd.exe tool, can be used to remotely configure a DNS Service to load an arbitrary DLL from a network share and execute its code. This is due to the DNS Service checking, upon startup, the presence of registry value ServerLevelPluginDll and, if it exists, loading the DLL from the path specified therein. This value could be set remotely using the dnscmd.exe tool by members of the DNSAdmins group.

After reporting this to Microsoft, Shay was told that "it [would] be fixed by basically only allowing DC administrators to change the ServerLevelPluginDll registry key, and that it [would] be possible to toggle this feature off in future releases."

Although in their write-up Shay generously described the issue as "a cute feature (certainly not a bug!)", it was undeniably a privilege escalation - from non domain admin to domain admin - as well as a remote code execution issue - from computer one can run code on to computer one can't normally run code on.

In any case, the issue got largely forgotten, likely because of its "not a bug" classification, until another security researcher Sean Metcalf brought it up in their article a year and a half later. Fourteen months after that, security researcher Dhiraj Sharma revisited the original article and published a new write-up. Further nine months of nothing happening later, an exploit module got added to Metasploit, making it easier for attackers of all hat colors to exploit this issue. We're not done yet. In April and May 2021, security researcher Phackt wrote a two-part analysis of this issue, further dissecting it and shedding light on the "why" and offering an alternative for using the overly-permissive DNSAdmins group. 

Finally, this October's Windows Updates brought a fix, assigned the issue CVE-2021-40469, and, surprisingly, acknowledged (only) Yuki Chen, a regular reporter of Windows vulnerabilities, for finding and reporting this to Microsoft.

What a ride.

Microsoft's Fix

Microsoft's fix delivered by October 2021 updates did what was promised back in 2017: it introduced a new registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\InternalParameters with permissions only allowing administrators to modify its content. The ServerLevelPluginDll value has been moved from the Parameters key to this new key, making it impossible to change it with permissions provided by the DNSAdmins group. A decent fix, as far as we can tell.

The only thing not fixed were affected Windows servers that aren't receiving official Windows updates anymore: Windows Server 2008 R2 and Windows Server 2008 without Extended Security Updates. This is where we come in.

Our Micropatch

Our micropatch, the whole 19 CPU instructions of it, takes a bit different approach compared to Microsoft's fix. When applied (enabled), our micropatch forces the DNS Service to ignore the ServerLevelPluginDll value even if it's present in the registry. Based on the absolute absence of hits when googling for ServerLevelPluginDll and filtering out articles about exploiting this value, we assess that very few organizations are using this feature, so simply removing it - which our patch effectively does - is the optimal approach. This decision was in line with our goal of using minimal amount of code to fix the vulnerability. However, should a customer report that they're using this feature, we'll replace the patch with one that is functionally closer to Microsoft's.

Source code of our micropatch:

And the video of our patch in action.

This micropatch was written for: 

1. Windows Server 2008 (updated with January 2020 Updates - latest before end of support) 
2. Windows Server 2008 R2 (updated with January 2020 Updates - latest before end of support)

by Mitja Kolsek, the 0patch Team

Update 12/21/2021: Microsoft provided an official fix for this issue on December 14. Our associated micropatches thus ceased being free and now require a PRO license.

Update 3/21/2022: Microsoft's fix for this issue turned out to be flawed. We ported our micropatches to all affected Windows versions and made them all FREE for everyone again.

In June 2021, security researcher Abdelhamid Naceri published a blog post about an "unpatched information disclosure" vulnerability in Windows. The post details the mechanics of the issue and its exploitation, allowing a non-admin Windows user to read arbitrary files even if they do not have permissions to do so. The exploit namely copies file(s) from a chosen location into a CAB archive that the user can then open and read.

Abdelhamid's blog post also provides the timeline of reporting the vulnerability to Microsoft through ZDI in October 2020, Microsoft assigning a CVE ID to the issue and allegedly planning to fix it in April 2021, and the latter not happening in April. Or June. Or July or August or September or October.

While we had noticed Abdelhamid's June disclosure, it didn't seem to be a critical enough issue for micropatching, as we generally don't patch information disclosure bugs.

In November, however, Abdelhamid pointed out that this - still unpatched - bug may not be just an information disclosure issue, but a local privilege escalation vulnerability. Namely, as HiveNightmare/SeriousSAM has taught us, an arbitrary file disclosure can* be upgraded to local privilege escalation if you know which files to take and what to do with them. We confirmed this by using the procedure described in this blog post by Raj Chandel in conjunction with Abdelhamid's bug - and being able to run code as local administrator.

(*) Two conditions need to be met in order for the local privilege escalation to work:

1. System protection must be enabled on drive C, and at least one restore point created. Whether system protection is enabled or disabled by default depends on various parameters.  
2. At least one local administrator account must be enabled on the computer, or at least one "Administrators" group member's credentials cached
   

The Vulnerability

The vulnerable functionality resides under the "Access work or school" settings and can be triggered by clicking on "Export your management log files" and confirming by pressing "Export". At that point, the Device Management Enrollment Service is triggered, running as Local System. This service first copies some log files to the C:\ProgramData\Microsoft\MDMDiagnostics folder, and then packages them into a CAB file whereby they're temporarily copied to C:\Windows\Temp folder. The resulting CAB file is then stored in the C:\Users\Public\Public Documents\MDMDiagnostics folder, where the user can freely access it.

It is the copying to C:\Windows\Temp folder that is vulnerable. Namely, a local attacker can create a soft link (junction) there with a predictable file name that will be used in the above-described process, pointing to some file or folder they want to have copied to the CAB file. Since the Device Management Enrollment Service runs as Local System, it can read any system file that the attacker can't.

Abdelhamid's POC targets the kernel dump files in folder C:\Windows\LiveKernelReports to demonstrate the issue, while we used SAM, SECURITY and SYSTEM files from a restore point folder to achieve local privilege escalation.

The vulnerability has CVE-2021-24084 assigned, but we still consider it a "0day" as no official vendor fix is available.

Our Micropatch

Abdelhamid's blog post suggested that user impersonation during CAB file creation would resolve the issue. While we agree with that, we were concerned that might break some use cases and rather decided to check for the presence of junctions during CAB file creation.

The function we patched is CollectFileEntry inside mdmdiagnostics.dll. This is the function that copies files from C:\Windows\Temp folder into the CAB file, and can be tricked into reading some other files instead.

Our patch is placed immediately before the call to CopyFileW that opens the source file for copying, and uses the GetFinalPathNameByHandleW function to determine whether any junctions or other types of links are used in the path. If they are, our patch makes it look as it the CopyFileW call has failed, thereby silently bypassing the copying of any file that doesn't actually reside in C:\Windows\Temp.

Here is the IDA graph showing our applied patch (green code blocks are patch code; blue code block is a trampoline with the original code).  

Micropatch Availability

This micropatch was written for: 

1. Windows 10 v21H1 (32 & 64 bit) updated with November 2021 Updates
   
2. Windows 10 v20H2 (32 & 64 bit) updated with November 2021 Updates
3. Windows 10 v2004 (32 & 64 bit) updated with November 2021 Updates
4. Windows 10 v1909 (32 & 64 bit) updated with November 2021 Updates
5. Windows 10 v1903 (32 & 64 bit) updated with November 2021 Updates
6. Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates

by Mitja Kolsek, the 0patch Team

Update 12/21/2021: Microsoft provided an official fix for this issue on December 14, and assigned it CVE-2021-43883. Our associated micropatches thus ceased being free and now require a PRO license.

Wow, this is the third 0day found by the same researcher we're patching in the last two weeks.

Abdelhamid Naceri, a talented security researcher, has been keeping us busy with 0days this year. In January we micropatched a local privilege escalation in Windows Installer they had found (already fixed by Microsoft), and in the last two weeks we fixed an incompletely patched local privilege escalation in User Profile Service and a local privilege escalation in Mobile Device Management Service (still 0days at the time of this writing).

Ten days ago, Abdelhamid tweeted a link to their GitHub repository containing a proof of concept for another unpatched vulnerability in Windows Installer. The vulnerability allows a local non-admin user to overwrite an existing file to which they do not have write access, and then arbitrarily change its content. This can easily be turned into local privilege escalation by overwriting a trusted system executable file with one's own code - as demonstrated by Abdelhamid's POC, which launches a command line window as Local System.

According to Cisco Talos, this vulnerability is being exploited in the wild. 

Note that this 0day is being referenced by multiple sources as a bypass to CVE-2021-41379, but the researcher who found it claims that is not the case.

The Vulnerability

The vulnerability lies in the way Windows Installer creates a RBF (Rollback File), a file that stores the content of all deleted or modified files during the installation process, so that in case rollback is needed, these files can be restored to their originals. The RBF file is created either in folder C:\Config.msi or in folder C:\Windows\Installer\Config.msi, based on some logic that we admittedly don't fully understand. In any case, should the RBF file be created in folder C:\Windows\Installer\Config.msi *, it later gets moved to a known location in initiating user's Temp folder where the files' permissions are also modified to give the user write access. Abdelhamid noticed that a symbolic link can be created in place of the incoming RBF file, which will result in moving the RBF file from  C:\Windows\Installer\Config.msi to some other user-chosen file on the system. Since Windows Installer is running as Local System, any file writable by Local System can be overwritten and made writable by the local user.

It doesn't take a lot of imagination to see that taking over an executable file that is being used by a privileged process can get one's code executed with such process' privileges. This Twitter thread by Will Dormann provides various options to achieve the same.

* In case the RBF file is created in C:\config.msi, the described file move does not take place, and the exploit can't work. Interestingly, Abdelhamid's 0day we had fixed in January was targeting the other rollback file, RBS or Rollback Script, which - to the contrary - had to be created in C:\Config.msi instead of in C:\Windows\Installer\Config.msi, to be exploitable. Things are weird in the Windows Installer world.

Our Micropatch

Our micropatch targets the RBF file move operation, whereby it checks that the destination path does not contain any junctions or links. If it does, we consider it an exploitation attempt, and the operation is canceled. The original code then "thinks" the file move operation has failed for some reason.

Micropatch Availability

This micropatch was written for: 

1. Windows 10 v21H1 (32 & 64 bit) updated with November 2021 Updates
   
2. Windows 10 v20H2 (32 & 64 bit) updated with November 2021 Updates
3. Windows 10 v2004 (32 & 64 bit) updated with November 2021 Updates
4. Windows 10 v1909 (32 & 64 bit) updated with November 2021 Updates
5. Windows 10 v1903 (32 & 64 bit) updated with November 2021 Updates
6. Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates
7. Windows 10 v1803 (32 & 64 bit) updated with May 2021 Updates
8. Windows 10 v1709 (32 & 64 bit) updated with October 2020 Updates 
9. Windows 7 ESU (32 & 64 bit) updated with November 2021 Updates
   
10. Windows Server 2019 updated with November 2021 Updates
11. Windows Server 2016 updated with November 2021 Updates
12. Windows Server 2012 R2 updated with November 2021 Updates
13. Windows Server 2012 updated with November 2021 Updates
14. Windows Server 2008 R2 ESU (32 & 64 bit) updated with November 2021 Updates

by Mitja Kolsek, the 0patch Team

Update 1/5/2022: Microsoft changed their mind and issued a CVE ID for this vulnerability: CVE-2021-43905. The latest version of LocalBridge also no longer recognizes the ms-officecmd: URI scheme.

Earlier this month, security company Positive Security published a detailed analysis of a critical vulnerability they had discovered in the handling of the "ms-officecmd" URL handler. In short, this vulnerability allowed a remote attacker to execute arbitrary code on user's computer when user visited a malicious web page with a browser or opened a link provided to them in documents or messaging applications.

Positive Security have responsibly reported this bug to Microsoft, who fixed it without assigning it a CVE ID, reportedly because "Changes to websites, downloads through Defender, or through the Store normally do not get a CVE attached in the same way. In this case the fix did not go out through Windows Update." 

Having a fix delivered though an alternative mechanism instead of Windows Update is not unprecedented in Windows, but can depend on assumptions that may not always be true. In this case, the fix was delivered through Windows Store - but only if the AppX Deployment Service was running. This service (AppXSVC) is enabled on Windows 10 by default and gets started when needed, but a quick Google search finds many people asking how to disable it, some presumably doing so. In addition, there is no need to have Windows Store working on users' computers in a typical enterprise environment, and in fact Microsoft provides instructions for blocking such access.

The situation is therefore such that a remote code execution vulnerability with no CVE ID assigned and official fix issued may have remained unfixed on an unknown number of computers worldwide. To make things worse, the DLL that was fixed (AppBridge.dll) has no version information, making it hard for anyone to determine whether their computer is vulnerable or not.

No version information for AppBridge.dll

The Vulnerability

The vulnerability is nicely described in Positive Security's blog post, so let's just focus on the crux here: various Windows applications such as Office, Teams or Skype register the "ms-officecmd" URL handler, which makes it possible to launch these applications by simply opening a URL provided in a hyperlink or visiting a web page. This handler parses the entire URL to determine which application is to be launched, and which file it should open.

This filename value in an "ms-officecmd" URL is problematic because it gets passed on to the launched application in form of a command-line argument. An application may, however, happily accept various additional arguments, and the vulnerability in question allows these to be sneaked in through the filename value. Teams, for example, is an Electron-based application and accepts the --gpu-launcher argument that launches any other app - as specified by the attacker.

Consequently, visiting a malicious web page while having Teams installed could launch malware on your computer. Whether you would have to okay a not-too-security-alert-looking dialog or not depended on the browser.

Microsoft's Fix

Microsoft addressed this issue in two places:

1. When the filename value points to a file (instead of a URL on the web), the new code tries to open such file locally and only continues with launching the application if that succeeds. This blocks maliciously injected arguments because a file that would match the malicious filename would not be present on user's computer and therefore couldn't be opened. (Side note: a malicious file could also be stored on a remote share and actually contain various unusual characters, so we're not entirely sure about the completeness of this approach.)
2. When the application is launched, the supplied filename value is enclosed in double quotes to force it to be parsed as a single argument.

After this fix was issued, Positive Security researchers found it to be incomplete, still allowing for argument injection with web-based filenames, such as launching Word with the /q argument like this:

"filename": "https://example.com/\" /q"

Those familiar with injection attacks will notice that even if the string is enclosed in double quotes, the double quote that is already in the string will terminate the starting quote and allow for the introduction of another argument. Classic injection attack.

Fortunately, at least Teams won't launch with a web-based URL argument like this but since many Office applications can be launched via "ms-officecmd" URL, the remaining exploitability of this issue can only be assessed with extensive analysis.

Our Micropatch

Our approach at this issue was more classic in terms of preventing injections. We replicated Microsoft's 2nd code change, enclosing the entire filename value in double quotes before it gets sent to ShellExecute, but we also added a check for existence of double quotes in the filename value and flat out refuse to launch the application if any are found. A double quote cannot be part of a Windows file name (it's one of the forbidden characters), and if someone wants to use double quotes in a web-based URL, they should encode them as %22.

Our patch was written for 32-bit and 64-bit AppBridge.dll that was delivered to Windows machines through Windows Store in October 2020. This is the last vulnerable version, and was subsequently replaced with a fixed version in June 2021. Our patch will therefore only get applied if you had Windows Store enabled in October 2020, and disabled it some time before June 2021. We expect some users may have older, or much older, versions of AppBridge.dll installed due to having disabled Windows Store earlier. In absence of AppBridge.dll version information, we can only recommend locally testing your exploitability by copy-pasting the following URL to your web browser on a machine with Microsoft Teams installed, and seeing if a calculator gets launched:

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/ --disable-gpu-sandbox --gpu-launcher=\"C:\\Windows\\System32\\cmd /c calc && \""
   }
}

Here is a video showing how 0patch prevents the above URL from launching calculator.

Micropatch Availability

This micropatch requires a 0patch PRO or Enterprise license as it cannot be considered a 0day anymore. To determine if it applies to your computer at all, you can install 0patch Agent with a free account and see if the patch appears under relevant patches.

If you're not sure whether you're vulnerable or not, try to locate AppBridge.dll on your computer: it should be in a folder like C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_[version]_x64__8wekyb3d8bbwe. (Note that the folder is only accessible to admins so running a full disk search as a non-admin user won't work.)

Once you've located the file, contact us at [email protected] and provide the exact file size and modification date of file AppBridge.dll and the name of the folder you found it in. For the record, the vulnerable AppBridge.dll on our test systems was in a folder version 18.2008.12711.0.

by Mitja Kolsek, the 0patch Team

Update 1/19/2022: User informed us that our initial micropatch for this issue broke Windows Hello PIN settings (not the login, but creating or editing the PIN). We analyzed the issue and found that our initial test for requestor's permissions was causing the problem in this case. We therefore revoked the initial patches and issued new ones where we check for requestor's permissions using token's TokenIsElevated value. 

Update 3/17/2022: March 2022 Windows Updates modified rpcss.dll on some Windows versions, so we ported our micropatch to these new versions. This vulnerability was presented to Microsoft employees at the Microsoft BlueHat Israel conference.

Update 6/27/2022: We've ported our patches for this issue to current versions of supported Windows platforms. Given that Microsoft does not plan to patch authenticated credentials relaying issues, these patches are now available only to PRO and Enterprise accounts.

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

Back in April 2021, researcher Antonio Cocomazzi of Sentinel LABS and independent security researcher Andrea Pierini published an article titled Relaying Potatoes: Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol. The article described a local privilege escalation vulnerability they had found in Windows and reported to Microsoft, who decided not to fix because "Servers must defend themselves against NTLM relay attacks."

As far as real world goes, many servers do not, in fact, defend themselves against NTLM relay attacks. Since the vulnerability is present on all supported Windows versions as of today (as well as all unsupported versions which we had security-adopted), we decided to fix it ourselves.

The Vulnerability

The vulnerability is comprehensively described in the Sentinel LABS article. It allows a logged-in low-privileged attacker to launch one of several special-purpose applications in the session of any other user who is also currently logged in to the same computer, and make that application send said user's NTLM hash to an IP address chosen by the attacker. Intercepting an NTLM hash from a domain administrator, the attacker can craft their own request for the domain controller pretending to be that administrator and perform some administrative action such as adding themselves to the Domain Administrators group.

To exploit this issue, some higher-privileged user must be logged in to the same Windows computer as the attacker at the same time. This is a relatively exotic situation on Windows workstations, although possible with the "Switch user" feature that keeps one interactive user logged in while another user logs in interactively to the same computer. One could imagine a malicious user asking the administrator to help them resolve some issue by logging in to their workstation via "Switch user", where a script running in attacker's session would autonomously perform the attack.

A much more interesting target are Windows servers, especially terminal servers where multiple users, both unprivileged and administrators, have simultaneous user sessions. There, any remotely logged-in user could attack any other user that is currently also logged in, and do so without social engineering or any assistance by the victim.

Microsoft decided not to fix this issue as their position is that NTLM relaying should be prevented through NTLM configuration or by not using NTLM anymore. Such changes have potential to break something, so companies are understandably a bit reluctant to implement them in their production environments.

Patching This Issue

To fix a vulnerability, one must first understand it, and the functionality within which it resides. This immediately brings us to the question: Why does Windows allow a low-privileged user to cause anything to get launched at all in a session other than their own? Unfortunately, we failed to find the answer or even come up with some hypothetical reason. A feature like this would immediately look suspect to any security researcher, and it's not a surprise that someone had looked at it and found it to be exploitable.

It would be easy for us to completely disable this strange functionality but just in case it's being used for some reason, we decided to only block it in case a non-privileged user is trying to launch a process in another session. We wanted to allow privileged users such as administrators or Local System to use this mysterious feature if they wanted, but prevent normal users from doing so.

Our patch was therefore placed in the execution flow of rpcss.dll where requestor's token, requestor's session ID and target session ID are known, and does the following:

1. If requestor's session ID is the same as target session ID, we do not interfere. (If the user wants to launch processes in their own session, let them do it.)
   
2. Else, if requestor's token allows for some privileged operation, we do not interfere. (Specifically, if requestor's token has a non-zero TokenIsElevated value, we consider the requestor as privileged, and do not interfere.)
3. Else, we block the operation.

Source code of our micropatch:

Here is a video showing how the micropatch blocks exploitation of this vulnerability:

Micropatch Availability

This micropatch was written for: 

1. Windows 10 v21H1 32&64 bit updated with December 2021 or January 2022 Updates
   
2. Windows 10 v20H2 32&64 bit updated with December 2021 or January 2022 Updates
3. Windows 10 v2004 32&64 bit updated with December 2021 or January 2022 Updates
4. Windows 10 v1909 32&64 bit updated with December 2021 or January 2022 Updates
5. Windows 10 v1903 32&64 bit updated with December 2021 or January 2022 Updates
6. Windows 10 v1809 32&64 bit updated with May 2021 Updates
7. Windows 10 v1803 32&64 bit updated with May 2021 Updates
8. Windows 7 32&64 bit updated with January 2020 Updates (no ESU)
   
9. Windows 7 32&64 bit updated with January 2021 Updates (year 1 of ESU)
   
10. Windows 7 32&64 bit updated with December 2021 or January 2022 Updates (year 2 of ESU)
    
11. Windows Server 2019 64 bit updated with December 2021 or January 2022 Updates
12. Windows Server 2016 64 bit updated with December 2021 or January 2022 Updates
13. Windows Server 2012 R2 64 bit updated with December 2021 or January 2022 Updates
14. Windows Server 2012 64 bit updated with December 2021 or January 2022 Updates
    
15. Windows Server 2008 R2 64 bit updated with January 2020 Updates (no ESU)
16. Windows Server 2008 R2 64 bit updated with January 2021 Updates (year 1 of ESU)
17. Windows Server 2008 R2 64 bit updated with January 2022 Updates (year 2 of ESU)
18. Windows Server 2008 64 bit updated with January 2020 Updates
    

by Mitja Kolsek, the 0patch Team

Security researcher Oliver Lyak published a detailed analysis of a local privilege escalation vulnerability in Windows Print Spooler (CVE-2020-1030), which they had previously reported to Microsoft in November 2021, and a fix for which was included three months later with February 2022 Windows Updates. (Thanks to Cliff Featherstone for pointing out we can't do math as we originally stated this was 15 months later.)

Vulnerability CVE-2022-21999, nicknamed "SpoolFool", complements numerous previously found issues in Windows Print Spooler, and like many of those, uses symbolic links to trick the Print Spooler service running with System privileges into doing something with file system that benefits the local attacker.

In this case (see proof-of-concept), the attacker makes the Print Spooler service change permissions of an attacker-chosen folder on the computer such that everyone can create files in it. It does so by creating a printer (any user can do that by default on a Windows workstation) with its own dedicated spooler folder. When Print Spooler service is restarted, it checks every printer's spooler folder to make sure it's there and properly set up - if the folder doesn't exist, the service creates it, and if the folder doesn't allow all users to write to it, it sets everyone-write permissions on it.

Oliver noticed that creating a symbolic link from a printer's spooler folder to some system folder results in Print Spooler service setting such permissions to said system folder, thus allowing the attacker to create arbitrary files there. Having this capability, the attacker can get their own executable launched by some system process.

Microsoft's patch changed the behavior of Print Spooler service such that upon restart, it no longer creates a spooler folder or change its permissions, thus redirecting printers with misconfigured spooler folders to the default spooler folder. Our micropatch does effectively the same.

The micropatch was written for the following Windows versions that don't receive official patches from Microsoft:

1. Windows 10 v1803 updated to May 2021
2. Windows 10 v1809 updated to May 2021
3. Windows 10 v2004 updated to December 2021
4. Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
5. Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
   

We'd like to thank Oliver Lyak 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.

by Mitja Kolsek, the 0patch Team

Twelve days ago, security researcher Axel Souchet published detailed analyses with associated proofs-of-concept for two remotely exploitable vulnerabilities in Windows that were fixed by Microsoft with February Windows Updates. Both vulnerabilities are similar and are caused by an uninitialized pointer that a malicious RTF file can get freed while having an illegal value.

Exploitability of such issues depends on whether the attacker can get the uninitialized value to point to a chosen address and thus control the resulting memory corruption. We don't know if this is possible but following the worst-case assumption principle (and historical track record showing that to be generally possible with sufficient motivation), unexplored memory corruption issues are assumed to allow for a remote code execution.

The two vulnerabilities are:

1. CVE-2022-21971 - see Axel's POC with analysis
2. CVE-2022-21974 - see Axel's POC with analysis
   

While Axel found these vulnerabilities, he was not the only one; both issues were reported to Microsoft by Zesen Ye and Zhiniang Peng with Sangfor, and CVE-2022-21971 also by Jinquan with DBAPPSecurity Lieying Lab. There was some initial uncertainty on whether these CVE IDs really matched Axel's findings, but Zhiniang has confirmed the match.

It was trivial to reproduce both issues by simply enabling Page Heap for WordPad.exe and opening Axel's RTF documents with WordPad. While WordPad requires the user to unblock content in a security warning, opening the same document in Microsoft Word produces no warnings. We preferred using WordPad for our analysis, however, as it is present on Windows by default.

Our analysis of Microsoft's fixes for these issues revealed that, unsurprisingly, they just added pointer initialization to constructor code. The image below shows a diff between vulnerable (left) and fixed constructor (right) in RMSRoamingSecurity.dll., and something similar was done in prauthproviders.dll as well.

Our micropatches are logically equivalent to Microsoft's. They were written for the following Windows versions that don't receive official patches from Microsoft:

1. Windows 10 v1803 updated to May 2021
2. Windows 10 v1809 updated to May 2021
3. Windows 10 v2004 updated to December 2021
   

Note that Windows 7 and Server 2008 R2 are not affected as the vulnerable functionalities do not exist there. 

Here is a video showing how 0patch blocks exploitation of these vulnerabilities:

These micropatches have already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain them 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.

We'd like to thank Axel Souchet for publishing their analyses and providing proofs-of-concept that allowed us to reproduce these vulnerabilities and create micropatches for them. We also encourage security researchers to privately share their analyses with us for micropatching.

by Mitja Kolsek, the 0patch Team

As time goes on, additional Windows 10 versions go out of official support - we have previously security-adopted Windows 10 v1803 and v1809, and now we're happy to report that we're adding two versions to the list:

1. Windows 10 v2004: This version stopped receiving security updates from Microsoft in December 2021, but we've since been delivering critical security micropatches for it to keep it running securely. If you're running Windows 10 v2004 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.
   
   
2. Windows 10 v1909: Enterprise, Education and IoT Enterprise releases of this Windows 10 version will receive its last security update from Microsoft in May this year (two months from now). At that time we will security-adopt it and start providing critical security micropatches to keep it running securely.

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 v1909/v2004 with 0patch will also receive our occasional micropatches for "0day" vulnerabilities in various products.

In order to have our micropatches applied, users will have to have their computers fully updated with the latest official Windows Updates provided by Microsoft: December 2021 updates for v2004, and May 2022 updates for v1909.

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

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

Twice Bypassed and Twice Micropatched, Will Third Time be a Charm?

by Mitja Kolsek, the 0patch Team

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

In November we issued a micropatch for a local privilege escalation in User Profile Service .This vulnerability was found and reported to Microsoft by security researcher Abdelhamid Naceri and assigned CVE-2021-34484 when initially fixed. Abdelhamid subsequently noticed that Microsoft's patch was incomplete and wrote a POC to bypass it. Based on that information, we were able to create a micropatch for what was then considered a 0day (a known vulnerability without an official vendor fix).

Microsoft then provided a fix for Abdelhamid's bypass with January 2022 Windows Updates (assigning the "new" vulnerability CVE-2022-21919), but Abdelhamid took a closer look and found another way around it (the linked article is not available at the time of this writing).

We could easily reproduce this second bypass on fully updated Windows computers, except on Windows Server 2016. While our own micropatch was not bypassable using Abdelhamid's new trick, Microsoft modified the DLL we wrote the micropatch for (profext.dll), which meant we had to port our patch to the new version of this DLL to protect users who diligently apply Windows updates.

In short, CVE-2021-34484 is again a 0day on supported Windows versions. Somewhat ironically, affected Windows computers whose official support had already ended (Windows 10 v1803, v1809,  and v2004) and have 0patch, did not have this vulnerability reopened.

1. Windows 10 v21H2 (32 & 64 bit) updated with March 2022 Updates
   
2. Windows 10 v21H1 (32 & 64 bit) updated with March 2022 Updates
   
3. Windows 10 v20H2 (32 & 64 bit) updated with March 2022 Updates
4. Windows 10 v1909 (32 & 64 bit) updated with March 2022 Updates
5. Windows Server 2019 64 bit updated with March 2022 Updates
   

by Mitja Kolsek, the 0patch Team

March 2022 Windows Updates brought a fix for a logical vulnerability in Remote Desktop Client for Windows that was found and reported by Abdelhamid Naceri. The vulnerability allowed a malicious RDP server to gain write access to any local drive on the computer running the connected RDP client, as long as at least one local drive was shared through the RDP session.

The trick Abdelhamid used in their POC was, as it so often happens, a symbolic link: Suppose you connected to a malicious RDP server and shared a locally plugged-in USB drive E:, the server could create a symbolic link from E:\temp to C:\ (which would mean your local C: drive, not server's) whereby the entire content of drive C:\ would become accessible to the server under E:\temp with permissions of the connecting user.

Microsoft assigned this issue CVE-2022-21990 and fixed it by preventing the server from creating symbolic links on drives that were shared with the server pointing to drives that were not shared with the server. This fix, however, was not delivered to Windows systems that no longer receive Windows Updates; such systems can now use our micropatches instead.

We decided to make our micropatches simpler than Microsoft's fix to avoid changing lots of code: our approach was to simply prevent creating symbolic links on drives that were shared with the server (regardless where these links would point to). We think it is very unlikely that our approach would break any reasonable use case - but just in case it does, the user can always temporarily disable our patch and then re-enable it - of course without restarting the computer, or even re-establishing the RDP connection.

Our micropatch was written for the following Windows versions that don't receive official patches from Microsoft:

1. Windows 10 v1803 updated to May 2021
2. Windows 10 v1809 updated to May 2021
3. Windows 10 v2004 updated to December 2021
4. Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
5. Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
   

We'd like to thank Abdelhamid Naceri 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.

by Mitja Kolsek, the 0patch Team

April 2022 Windows Updates included a fix for a critical remotely exploitable vulnerability in Windows Remote Procedure Call Runtime (CVE-2022-26809). The vulnerability was found and reported by company Cyber-Kunlun founded by security researcher mj0011, but no proof-of-concept was published at the time.

As is often the case, the research community "diffed" Microsoft's patch (see Ben Barnea and Ophir Harpaz of Akamai and MalwareTech) and quickly found that the vulnerability must have been an integer overflow: if a special kind of RPC packets were sent to the RPC server, and very many of them, a buffer size on the server side would grow and grow until it would have to exceed 4 GB (the highest number one can represent with 32 bits), at which point said buffer size would "overflow" and become very small again. Should the buffer then get allocated, it would be too small, incoming packets overwriting data and possibly code beyond it. By carefully selecting the size and content of packets, at least in theory, a remote attacker could cause arbitrary code to get executed in the process of the targeted RPC serve.

In practice, it would not be that easy. First of all, packets have a maximum size of about 5,000 bytes and sending enough of them over the network to cause the overflow takes hours. Moreover, several researchers have mentioned - and we can confirm - that attempting to send so much data to an RPC server often results in a timeout in communication, which means going back to square one. In addition, it became apparent that not all RPC servers would be vulnerable, as the affected code was only reachable on certain types of servers (see here). Finally, what exactly would be overwritten by malicious data, and how/if that could lead to execution of attacker's code, remains unexplored. Nevertheless, the history teaches us to assume that possible.

For a few weeks attackers and defenders alike were looking for more data and either searching for, or trying to create a POC. On May 1st, a GitHub repository from user yuanLink appeared with what looked like a POC for this issue, along with a detailed analysis of the vulnerability seemingly from the same user. We took the POC and after some modifications we were able to reach the vulnerable code and see the buffer size growing with each received packet.

While analyzing the vulnerability and comparing fixed and vulnerable code, our team noticed another integer overflow issue nearby that wasn't addressed by the April Windows Updates. Before we could report it to Microsoft it turned out Akamai researchers had already done that, and May updates brought a fix for this additional vulnerability, assigned CVE-2022-22019.

This allowed us to fix two birds with one stone, so to speak, and we created a single micropatch to address both CVE-2022-26809 and CVE-2022-22019.

Source code of the micropatch:

Our micropatch was written for the following Windows versions that don't receive official patches from Microsoft:

1. Windows 10 v1803 updated to May 2021
2. Windows 10 v1809 updated to May 2021
3. Windows 10 v1903 updated to December 2020
   
4. Windows 10 v2004 updated to December 2021
5. Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
6. Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
   

We'd like to thank yuanLink for publishing their analysis and providing a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch, and Antonio Cocomazzi for providing valuable assistance in reproducing the issue. We also encourage security researchers to privately share their analyses with us for micropatching.

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.

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.

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.

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:

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.

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.

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:

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.

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.

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:

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 

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.

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.

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!

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.

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 

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

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

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:

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)

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.