RSS Security

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterday0patch Blog

0patch Agent 21.05.05.10500 released

12 July 2021 at 16:20


 

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.


 

 

 

Free Micropatches for PrintNightmare Vulnerability (CVE-2021-34527)

2 July 2021 at 13:34


by Mitja Kolsek, the 0patch Team


[Note: This blog post is expected to be updated as new micropatches are issued and new information becomes available.]

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



 

See our micropatch in action:



Micropatches for PrintNightmare 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.


Frequently Asked Questions


Q: Which Windows versions are affected by PrintNightmare?

Answer updated 7/15/2021: We believe Will Dormann's PrintNightmare diagram most accurately describes the conditions under which PrintNightmare is exploitable, and this applies to all Windows versions at least back to Windows 7 and Server 2008 R2.

We have previously thought that domain-joined computers were not vulnerable but this was likely because by joining a domain, firewall rules were set up that blocked remote exploitation until one started sharing a folder or a printer.

 

Q: How about Windows systems without June 2021 Windows Updates?

We believe that without June 2021 Windows Updates, all supported Windows systems, i.e., all servers from 2008 R2 up and all workstations from Windows 7 and up, are affected.


Q: What will happen with these micropatches when Microsoft issues their own fix for PrintNightmare?

[Update 7/15/2021: We recommend everyone continues applying regular Windows Updates, including specifically the July Patch Tuesday update.]

First off, we absolutely usually recommend you do install all available security updates from original vendors [Update 7/8/2021: For the first time ever we do NOT recommend installing the July 6 update if you're using 0patch. See the top of the article for more information].When Microsoft fixes PrintNightmare, their update will almost certainly replace localspl.dll, where the vulnerability resides, and where our micropatches are getting applied. Applying the update will therefore modify the cryptographic hash of this file, and 0patch will stop applying our micropatches to it. You won't have to do anything in 0patch (such as disabling a micropatch), this will all happen automatically by 0patch design.

When the official fix is available, our micropatches will stop being free, and will fall under the 0patch PRO license. This means that if you wish to continue using them (and many other micropatches that the PRO license includes), you will have to purchase the appropriate amount of licenses.

[Update 7/8/2021: We do not consider Microsoft's July 6 out-of-band updates to be a proper fix, so we're keeping our PrintNightmare patches free until they issue a correct fix.]


Q: I have installed 0patch but the PrintNightmare patch is not applied. Why?

The Print Spooler service doesn't initially load localspl.dll when you start it, so it's probably not loaded yet. When it's needed (e.g., when installing a new printer, probably also when you print, and certainly if you launch a PrintNightmare proof-of-concept or exploit against it), localspl.dll gets loaded, and patched by 0patch.

To be sure you have the correct version of localspl.dll, launch 0patch Console and open the PATCHES -> RELEVANT PATCHES tab. At least one PrintNightmare patch should be listed there.


Q: We have a lot of affected computers. How can we prepare for the next Windows 0day?

Obviously deploying 0patch in an enterprise production environment on a Friday afternoon is not something most organizations would find optimal. As with any enterprise software, we recommend testing 0patch with your existing software on a group of testing computers before deploying across your network. Please contact [email protected] for setting up a trial, and when the next 0day like this comes out, you'll be ready to just flip a switch in 0patch Central and go home for the weekend.


Credits

We'd like to thank Will Dormann of CERT/CC for behind-the-scenes technical discussion that helped us understand the issue and decide on the best way to patch it.


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

Micropatch for Another Remote Code Execution Issue in Internet Explorer (CVE-2021-31959)

14 June 2021 at 13:45

 


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:



MODULE_PATH "..\Affected_Modules\jscript9.dll_11.00.9600.19867_32bit\jscript9.dll"
PATCH_ID 614
PATCH_FORMAT_VER 2
VULN_ID 7138
PLATFORM win32
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x10d189
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT jscript9.dll!0x10cf2d
    ; jscript9.dll!0x10cf2d -> SaveToPropIdArray
    
    code_start
        mov ecx, [ebp-0ch]  ;
get linked list
        mov eax, [ecx+0x28] ;
        mov esi, [eax+0x30] ;
       
    LOOP:
        test esi, esi       ; is there more of PropertyID array?
        jz END              ; if everything is initialized, jmp to
                            ; label END, else go into loop.

        mov ecx, [esi+20h]
        lea eax, [ebp-20h]  ; get struct Js::PropertyIdArray *
        push eax            ; struct Js::PropertyIdArray *
        push ebx            ; struct Symbol *
        mov edx, edi        ; struct FuncInfo *
        call PIT_0x10cf2d   ; call SaveToPropIdArray
        mov esi, [esi+18h]  ; next element in linked list
        jmp LOOP
       
    END:
    code_end
   

 

See the micropatch in action:




We'd like to thank  Ivan Fratric for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.
 
This micropatch is immediately available to all 0patch users with a PRO license, and is already downloaded and applied on all online 0patch-protected Windows versions we've security-adopted:
 
  1. Windows 7 and Windows Server 2008 R2 without Extended Security Updates, 
  2. Windows 7 and Windows Server 2008 R2 with year 1 of Extended Security Updates.
  3. Windows 10 v1803
  4. Windows 10 v1809

To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

By the way, if your organization has Windows 10 v1803, Windows 10 v1809 or Office 2010 installations that stopped receiving security updates, and would like to continue using them, it could be useful to know we've security-adopted these for at least 12 months. To save time and money, and step into the age of reboot-less security patching, contact [email protected].

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




 

Micropatch for Remote Code Execution Issue in Internet Explorer (CVE-2021-26419)

18 May 2021 at 15:23

 


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:



MODULE_PATH "..\Affected_Modules\jscript9.dll_11.0.9600.19867_64bit\jscript9.dll"
PATCH_ID 606
PATCH_FORMAT_VER 2
VULN_ID 7112
PLATFORM win64
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0xbe342
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT jscript9!0x8be60 ; ByteCodeGenerator::EmitLocalPropInit
    
    code_start
        mov r9, rbp ; Some instructions are erased and a new function call added
        mov r8, rdi
        mov edx, esi
        mov rcx, rbx
        mov rbx, [rsp+70h]
        add rsp, 40h
        pop rdi
        pop rsi
        pop rbp
        jmp PIT_0x8be60 ; New call to EmitLocalPropInit
    code_end
    
patchlet_end

 

See the micropatch in action:




We'd like to thank  Ivan Fratric for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is already downloaded and applied on all online 0patch-protected Windows 7 and Windows Server 2008 R2 machines without Extended Security Updates, or with year 1 of Extended Security Updates.

To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

By the way, if your organization has either Windows 10 v1809 or Office 2010 installations that stopped receiving security updates, and would like to continue using them, it could be useful to know we've security-adopted both for at least 12 months. To save lots of money and step into the age of reboot-less security patching, contact [email protected].

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




 

0patch Security-Adopts Windows 10 v1803 and v1809 to Keep it Running Securely

11 May 2021 at 08:05

Towards Micropatching the "Security Update Gap"

 


by Mitja Kolsek, the 0patch Team

 

[Update: We initially security-adopted only Windows 10 v1809, but were then approached by customers needing micropatches for v1803 as well, so we security-adopted that version too.]

The May 2021 Windows Updates will contain the last official security fixes for many editions of three Windows 10 operating system versions:

  1. Windows 10 v1803
  2. Windows 10 v1809
  3. Windows 10 v1909

For organizations with any of these versions installed on their computers, this means the end of official security patches, and a pressure to upgrade to a supported Windows 10 version. Such organization-wide operating system upgrade may seem like a simple, mostly automated task - but in reality, updates break things:

In addition, with many users working from home these days, upgrading an operating system involves users downloading a huge update via their home Internet connection and difficult remote assistance in case something goes wrong with the upgrade.

Consequently, customers were approaching us in recent months asking whether we were planning to security-adopt some of these Windows 10 versions (mostly version 1809, later also version 1803), as they were looking for ways to keep using them securely.

And so we've decided to security-adopt Windows 10 v1803 (build 10.0.17134) and v1809 (build 10.0.17763) - as we have previously security-adopted Windows 7, Windows Server 2008 R2, and Office 2010.

Starting this month, initially for one year, we will actively gather information about vulnerabilities affecting Windows 10 v1803/v1809 and, based on our risk criteria, create micropatches for this operating system. We will be particularly interested in any vulnerabilities patched by Microsoft in still-supported Windows 10 versions, and whether they might affect v1803/v1809 as well.

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

In order to have our Windows 10 v1803/v1809 micropatches applied, users will have to have their computers fully updated with the latest (May 2021) official Windows Updates provided by Microsoft.

We welcome all interested organizations with Windows 10 v1803/v1809 to contact [email protected] for information about pricing, deployment, or setting up a trial. If you happen to be using a large number of v1909 versions in your environment, also let us know as given sufficient demand we will security-adopt those too.

 

Addressing The Security Update Gap 

Our security-adoption of an unsupported Windows 10 version is an important milestone on our journey towards addressing the "security update gap" on supported Windows versions, which aims to allow organizations to protect themselves with our micropatches while thoroughly testing monthly Windows Updates before deploying them. And eventually even skipping one or two monthly updates under our protection.

 

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


 

 

 

Another Windows Installer Local Privilege Escalation Bug Gets a Micropatch (CVE-2021-26415)

6 May 2021 at 14:24

 


by Mitja Kolsek, the 0patch Team


On April 21, security researcher Adrian Denkiewicz published an in-depth analysis of a local privilege escalation vulnerability in Windows Installer that was fixed by April 2021 Windows Updates. Adrian's analysis included a proof-of-concept.

The vulnerability is a classical symbolic-link issue, whereby a privileged process (in this case, msiexec.exe) works with a file (in this case, installer log file) that the attacker is able to "redirect" to another location where the they do not have permissions to create or modify files.

Since attacker has limited control over the content of installer log file, and cannot modify the redirected log file after it has been created, Adrian had to be creative and found a working attack scenario in creating/overwriting PowerShell profile file (C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1) that gets loaded whenever anyone, ideally admin, uses PowerShell.

In essence, Microsoft's fix included a call to function IsAdmin from function CreateLog, which is in charge of creating installer log file. Some permissions checking was already in place before in this function but was not resilient to the "bait-and-switch" symbolic link trick that has been successful against many Windows products before, and will surely be successful against many more to come.

Our micropatch does logically the same as Microsoft's fix. Here is its source code for 64-bit Windows 7 and Server 2008 R2 with its 7 CPU instructions.



MODULE_PATH "..\Affected_Modules\msi.dll_5.0.7601.24535_64bit\msi.dll"
PATCH_ID 604
PATCH_FORMAT_VER 2
VULN_ID 7058
PLATFORM win64

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0xf5a55               ; First GetCurrentThread block in CreateLog function
                                       ; instruction lea r9, [rsp+98h+TokenHandle]
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msi.dll!0xf5b31,msi.dll!0xef7f8   ; Address of block to jump to; IsAdmin function
    
    code_start
        push rax                      ;Save the GetCurrentThread return
        push rax                      ;Push one more time to fix stack alignment
        call PIT_0xef7f8              ;Call IsAdmin (ret 1 if admin, 0 if not)
        cmp rax, 0                    ;Check if user is admin
        pop rax                       ;Restore the GetCurrentThread return and fix stack alignment again
        pop rax
        je PIT_0xf5b31                ;If user is not an admin, jump over the scond createfile block
    code_end
    
patchlet_end

 

See the micropatch in action here:




We'd like to thank Adrian Denkiewicz for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is already downloaded and applied on all online 0patch-protected Windows 7 and Windows Server 2008 R2 machines without Extended Security Updates, or with year 1 of Extended Security Updates.

To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

And don't forget, if your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive low-risk security patches in 2021 that don't even need your machines to be restarted, contact [email protected].

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



 

 

 

 

 

 

 

 

 

Remotely Exploitable 0day in Internet Explorer Gets a Free Micropatch

29 March 2021 at 20:44


by Mitja Kolsek, the 0patch Team

 

[Note: This blog post was originally published on February 17, 2021 under URL https://blog.0patch.com/2021/02/remotely-exploitable-0day-in-internet.html but was for some reason deleted. Perhaps it was our fat fingers, perhaps evil forces - we'll never know. We have now reconstructed it from the Internet Archive which is an incredible service that you should donate to if you like this post, as we did.]

[Update 3/19/2021: This issue has been fixed by March 2021 Windows Updates. 0patch users had this critical issue, now assigned CVE-2021-26411, patched since February 17, full 20 days before an official patch became available. Since the official fix is available, this micropatch is no longer FREE and requires a PRO license.]

On February 4, 2021, security researchers at ENKI, a South Korean security consultancy, published a blog post detailing an unpatched vulnerability in Internet Explorer. This "0day" vulnerability was used in an attack campaign against various security researchers, including ENKI researchers, who noticed the attack and took the exploit apart to extract the vulnerability information. ENKI researchers kindly shared their proof of concept with us, so we could quickly start analyzing the vulnerability and create a micropatch for it.

The vulnerability is a "double free" bug that can be triggered with JavaScript code and causes memory corruption in Internet Explorer's process space. As is often the case, this memory corruption could be carefully managed and turned into arbitrary read/write memory access - which can then be leveraged to arbitrary code execution. Attackers delivered the exploit in an MHTML file to ensure recipients would open it in Internet Explorer (which is registered to open this file type). While this delivery method required recipients to confirm a security warning about executing active content, the exploit could be delivered without such warning if the victim visited a malicious web site with Internet Explorer. 

In such case, just opening the malicious web site would instantly, or a benign web site hosting a malicious ad, would result in malicious native code execution inside Internet Explorer's render process running (by default) in Low Integrity. Such code could read any data from the computer and network that the user running Internet Explorer could read, and silently send it to attacker. An additional vulnerability would be needed to escape the "Low Integrity sandbox" and achieve a long-term compromise of the computer.

Is anyone still browsing the web with Internet Explorer? While Internet Explorer is not widely used for browsing web sites anymore, it is installed on every Windows computer and (a) opens MHT/MHTML files by default, (b) is being used internally in many large organizations, and (c) executes HTML content inside various Windows applications.


The Vulnerability

Exploit and proof-of-concept have not been published yet and we won't be the first to do so, but the root of this vulnerability is not new - it's about tricking the browser to delete an object that has already been deleted in some unexpected way that existing sanitization checks don't notice. In this case, it's about deleting a node value of an HTML Attribute. The trick is to create an attribute, assign it a value that is not a string or a number, but an object (why is this even allowed?) - then when deleting this attribute, said object makes sure that the attribute is deleted before it gets deleted, so to speak.


The Micropatch

While Internet Explorer developers will probably fix the way the attribute node is deleted so that it doesn't actually get deleted while references to it still exist, we decided that such approach would simply require too much time for us and would introduce an unnecessary risk of breaking something. We thus rather decided to break the obscure browser functionality that allows setting an HTML Attribute value to an object. We assess this functionality to be useful to very few web developers whose apps are supposed to work with Internet Explorer.

Our micropatch gets applied inside the CAttribute::put_ie9_nodeValue function of mshtml.dll, where it checks the VARIANT type of the value that JavaScript code wants to assign to an attribute - and prevents that from happening if the type is 9 (VT_DISPATCH) - which is used for Object, Array, or Date.



The 64bit micropatch only has 5 CPU instructions, and the 32bit one has 6 CPU instructions.



MODULE_PATH "..\Affected_Modules\mshtml.dll_11.0.9600.19597_64bit\mshtml.dll"
PATCH_ID 560
PATCH_FORMAT_VER 2
VULN_ID 6943
PLATFORM win64

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0xbf34b4

 N_ORIGINALBYTES 5
 PIT mshtml.dll!0xbf359f ; address of exit block

 code_start

  ; we're going to check the incoming VARIANT's data type; if it's 9 (object), we're going
  ; to prevent it from being copied to the attribute.
  ; The incoming VARIANT is pointed to by rdx, and the type is in the first byte.

  mov r14, rcx         ; replicate the instruction we're injected in front of to make sure
                       ; rcx is stored in r14 in case we jump to the exit block (where rcx is
                       ; restored from r14)
  cmp byte [rdx], 0x09 ; is the incoming VARIANT data type 9 (object)?
  jne DO_NOTHING       ; if not, we don't interfere
 
  mov rbx, 0            ; return value - we simulate a successful operation
  jmp PIT_0xbf359f     ; jump to exit block
 
 DO_NOTHING:

 code_end
    
patchlet_end


Here's a video of the micropatch in action:




The micropatch applies to the following Windows versions (32bit and 64bit). 

Updated to February 2021:

  1. Windows 7 + ESU (first update from ESU year 2)
  2. Windows Server 2008 R2 + ESU (first update from ESU year 2)
  3. Windows 10 v1809, v1909, v2004, v20H2
  4. Windows Server 2016, 2019

Updated to January 2021:

  1. Windows 7 + ESU (last update from ESU year 1)
  2. Windows Server 2008 R2 + ESU (last update from ESU year 1)
  3. Windows 10 v1809, v1909, v2004, v20H2
  4. Windows Server 2016, 2019 

Updated to January 2020:

  1. Windows 7 without ESU (last free update without ESU)
  2. Windows Server 2008 R2 without ESU (last free update without ESU)
 

Online Test

 
We have prepared a simple online test to demonstrate how our micropatch changes the behavior of Internet Explorer. To perform this test, you have to use Internet Explorer 11 on one of the Windows systems listed above.

Step 1: With 0patch disabled, open https://0patch.com/poc/IE_Attribute_nodeValue_0day/test.html in Internet Explorer 11. The web page should look like the image below, indicating 6 FAILed tests.
 

Step 2: With 0patch enabled, press F5 to refresh the test page in Internet Explorer 11. The web page should look like the image below, indicating no failed tests.


 

According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it. By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
 
We'd like to thank ENKI researchers for their analysis of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.

While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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

Analyzing And Micropatching With Tetrane REVEN (Part 1, CVE-2021-26897)

29 March 2021 at 14:52

 

by Mitja Kolsek, the 0patch Team


March 2021 Windows Updates included fixes for seven vulnerabilities in Windows DNS Server, two of which were marked by Microsoft as "Exploitation More Likely": CVE-2021-26877 and CVE-2021-26897. They were not known to be exploited and no details were publicly available until security researchers Eoin Carroll and Kevin McGrath published their analysis on McAfee Labs blog. Their article included enough information for us to reproduce both vulnerabilities, and then create micropatches for them.

This article will be about CVE-2021-26897, while CVE-2021-26877 will be covered in a parallel article.

These two vulnerabilities were the first we have ever analyzed with the help of Tetrane REVEN, an incredibly powerful reverse engineering tool that allows you to record a virtual machine and then browse or search through all recorded instructions in all processes and the kernel, or taint any data value forward or back in time, across processes and between user and kernel space (plus much more). I wanted to use this opportunity to show how REVEN helped us perform these analyses, which would otherwise have been done with WinDbg and countless re-launching of dns.exe process, having all interesting objects bouncing around on different memory addresses every time.


Analysis

CVE-2021-26897 is a buffer overflow issue, whereby a series of oversized "dynamic update" DNS queries with SIG (signature) records causes writing beyond the buffer boundary when these records are saved to file. DNS server periodically saves all received updates to file (so they don't get lost on restart or crash), and the issue gets triggered by simply waiting for this file write to happen after sending a number of requests, or by stopping the DNS Server service, which was a convenient time saver for us.

Our proof-of-concept (POC) sends ten malformed DNS requests, and upon stopping the DNS Server service, the dns.exe process crashes. Let's use REVEN to see what goes on.

We used a virtual machine with Windows Server 2019 and DNS Server role without March updates to keep it in the vulnerable state. It is important to record as few events (called "transitions") as possible, so "lightening" of a machine - stopping unnecessary services, and disabling Windows Defender and Windows Error Reporting - is generally a good idea. We did not stop any services but did the latter as error reporting gets triggered upon every process crash and, well, executes a lot of instructions. While it's easiest to start and stop recording manually, even one second of extra recording can create tens of millions of unneeded transitions that will just slow down post-processing of the recording. To optimize start and end of recording, REVEN provides a cool trick they call "ASM stubs", which is a fancy name for calling the int3 CPU instruction while having the ecx register set to some magic value. In other words, you can trigger starting and stopping of recording from within the virtual machine you're recording, which means you can start right before the interesting stuff happens, and stop right after it's done.

In our case, the mere sending of malformed DNS requests does not crash the process, but the stopping of the DNS Server service does. So we used our POC to send the requests, and then launched a batch script that started the recording and stopped the service. Before that, we have "abused" the Postmortem Debugging mechanism to make it launch a small executable that stops recording whenever a process crashes - instead of launching a debugger, which postmortem debugging was designed for.

Our recording generated around 1.25 billion transitions.Yes, that's billion. But it's really no problem because REVEN handles that effortlessly. The only price you pay for a larger recording is the time you have to wait for REVEN to "replay" it, which extracts all machine states and transitions, indexes them, extracts everything that was happening to the memory, downloads symbol files and a bunch of other things to assure a swift analysis thereafter. Our replay took just over an hour and generated 55 GB of data, upon which the analysis would then actually be done.

Granted, we could have tried to further reduce the recording and possibly succeed, but that doesn't make too much sense - one hour for preparation while you're having lunch is more than acceptable, and fiddling with recording optimization also takes time that can quickly exceed the time saved by a potentially quicker replay.

Proceeding to "Axion", the analysis user interface where the magic stuff happens. Axion has multiple widgets; prominently positioned in the middle are Transitions, displaying a small part of the entire recorded execution conveniently grouped in code blocks with one or more CPU instructions. Other widgets include Backtrace (the call stack for the current transition), CPU (register values before and after the current transition), Memory (at chosen address, before or after the current transition, along with the entire history of read and write accesses), Search (immensely useful, allows you to find calls to specific function, or all executions of a specific instruction), Bookmarks, and - my favorite - Taint. REVEN allows you to select any piece of data (e.g., the current value in register r8, or the value at some memory address) and taint it either forward or back in time, to see what this value affects or where it came from, respectively. This is a huge value-add for our analyses - although by no means the only one.

Now let's dive into the analysis. The first thing we need to do is find where dns.exe crashed. Scrolling through a billion+ transitions is obviously out of the question, but we can search for one of the functions that get called when an unhandled exception is thrown. KiUserExceptionDispatch is one such function.

 

 

Search finds a single hit, as expected, and here we are looking at the first executed instruction in this user-space function, as it was launched by kernel's KiExceptionDispatch. (The kernel code is on grey background because we filtered out only user-space execution.) Now we want to see why this exception was thrown. A simple press of the "%" key transfers our to the other end of a call-ret pair, or in our case, to the other end of the kernel call.

 

The "%" key landed us on the exact instruction that caused access violation in function Dns_SecurityKeyToBase64String. It was an attempted write to address r8+1, and the Memory view shows this address to be immediately after a valid memory block, where we see a bunch of A's that were likely written to this buffer in some loop we're probably currently in. We did not use REVEN-IDA integration here but if we did, we would immediately see the code graph for this function in IDA, with the current instruction selected in IDA. And we would see that we are, indeed, in a loop that copies base64-encoded signature value from our DNS request to this buffer that just got overflown, and uses r8 as the destination pointer that gets increased in every iteration. 

(Note that we enabled Page Heap for dns.exe to make it crash immediately on buffer overflow, otherwise the overflow could just corrupt the heap and eventually cause some random malfunction. With Page Heap, every heap buffer is allocated at the very end of a read-write memory block, followed by unallocated memory page - which means any typical buffer overflow will immediately trigger an access violation exception.)

Execution of a loop is shown in REVEN as a repetition of loop instructions, over and over again, but you can of course select any of these instructions and see how registers and memory looked like at that exact moment. What we want here, though, is to see where the buffer was allocated.

If we were in WinDbg, we'd have used the !heap command to get the call stack from the moment the overflown buffer was allocated. In REVEN, however, we can not only find the code that allocated the buffer, but also values of registers and content of memory in that precise moment. The simplest way (that I know of) would be to simply taint register r8 to see where its value came from - going back to the past far enough, at some point its value must have been determined by whoever allocated this buffer, or it would not have pointed to the end of this same buffer now.

However, tainting r8 backward produces too long a path that just keeps bouncing in the loop that we're in. While it eventually gets to where we want to be, it slows down the UI. So our first goal is to get to the beginning of our loop's execution. We copied the address of our access-violation-triggering instruction (0x7ff729ca224a) and went to the Search widget, where we searched for all uses of this address.



Results: this exact instruction has been executed 130705 times in our recording; in other words, it would take a significant chunk of one's lifetime to just scroll up to the start of the loop. However, it only took one press of the "Next" button to get to the first iteration of the loop - because we were already positioned on the last iteration.

 



 

This got us to the very first execution of our instruction in this recording, and we can see that it wrote 0x41 to memory (to the very same buffer it overflowed 130704 iterations later). The 0x41 left to it was written earlier by a similar instruction in the same loop. Now that we're out of the loop, so to speak, let's taint r8 and see where it got from.



We launched tainting for value of register r8 from the current transition, back to some function we selected high in the call stack; we chose function Zone_WriteBackDirtyZones. Why not taint all the way back to the very first transition? Because we're only interested in who has allocated the memory buffer that got overflown, but the taint would go way further back in time because the address of this allocation was influenced by earlier allocations (that's how the heap works) and that is just irrelevant to us.

Tainting identified a couple of hundred transitions, and we're interested in those at the very end of the list (i.e., the earliest ones). When one is often looking for memory allocations, some familiar Windows functions catch one's eye - and RtlAllocateHeap is one of them.



RtlAllocateHeap takes three arguments, allocation size being the third one - which in x64 calling convention means register r8. We can see that the value of r8 when this function was called was 0x80010. This means that the actual buffer allocated was of this size, but we still want to see if this is a hard-coded size or perhaps dynamically calculated. So we go further back in time through the taint results.



In the very first transition found with tainting, inside funtion File_WriteZoneToFile, we see a call was made to a function Mem_Alloc, which is not publicly documented but is clearly used for allocating the memory block we're after. Most importantly, we can see that a hard-coded value 0x80000 was provided to it, which is clearly the size of the buffer. (0x10 was subsequently added to it inside Mem_Alloc, which is nicely seen by walking through the taint.)

Now we know what happened: a fixed-sized memory block was allocated in function File_WriteZoneToFile, whose name implies that the DNS zone we've updated with our malformed requests was going to be written to file. At some point function Dns_SecurityKeyToBase64String was called that overflowed this buffer after base64-encoding the signature from our requests. Let's just see if function Dns_SecurityKeyToBase64String was called more than once, as we know that a single malformed request doesn't produce the crash.

To do that, we used the "Symbol call" search and provided the function name.



The search produced 6 hits, meaning that function Dns_SecurityKeyToBase64String was called 6 times. This indicates that it was our 6th DNS request that finally caused the writing to go beyond the buffer end. Some additional analysis showed that all these calls added their output to the same growing string inside the fixed-size buffer, which was supposed to be finally saved to the zone file.

Our REVEN analysis was done here. At this point we could have created a micropatch in various ways, making sure to prevent writing past the buffer end, but since we had Microsoft's official patches available, we wanted to see what they have done.

We used IDA and BinDiff to compare dns.exe from February 2021 and March 2021, and found 9 functions modified by the March update.



Technically, we could just search our recording for any execution inside these functions, and hopefully find that just one of them was executed - which would mean that the fix was included there. Actually, we did exactly that and found SigFileWrite to be the only one - but this would be very cumbersome if hundreds of functions were modified, especially if the recording included many of the modified functions that have nothing to do with our bug.

The most reliable method would be to inspect the entire taint list to see which of the modified functions affected the value we were tainting. Taint search is currently not supported by REVEN user interface, but we could undoubtedly use the API to achieve that (note to self: send a feature request to Tetrane). We're not that fluent in REVEN API yet so we took the third route: the call stack.

It is quite likely that one of the modified functions would appear in the call stack of our crash instruction. But in our case we don't see it (see the call stack on one of the screenshots above). We do see, however, that function Dns_SecurityKeyToBase64String seems to have been called by function LdrpDispatchUserCallTarget, which has a suspect name. Let's just click on that in REVEN and see what happened there.

 


We see that function RR_WriteToFile made a call to LdrpDispatchUserCallTarget, which then made a jump to SigFileWrite function. The latter is executed, but not seen in the call stack because LdrpDispatchUserCallTarget jumped to it instead of calling. Note that function LdrpDispatchUserCallTarget is part of Control Flow Guard as explained in this Trend Micro article. So whenever you see LdrpDispatchUserCallTarget in the call stack, you'll want to look for which function it jumped to.

Now that we have our "patch suspect", let's see how the original (February) and modified (March) versions of SigFileWrite function compare in BinDiff.



We see that four sanity checks were added, perhaps excessively but efficiently:

  1. If length of the SIG record is less than 0x12 (minimum possible), then exit.
  2. If length of the SIG record, subtracted by 0x12, is less than length of signer's name, then exit.
  3. If pointer to the end of the string (where it will be appended) is larger than end of buffer, then exit.
  4. The final, most complex-looking check, is compiler's "artistic rendition" of multiplication of signature length by 4/3, which is the number of characters that base64-encoding will require. If signature length multiplied by 4/3 is larger than the difference between string end pointer and end of buffer, then exit.

These checks make sure that the buffer will not get overflown, and will silently prevent DNS update records from being written to the zone file if end of buffer has been reached.

 

The Micropatch

Our micropatch does logically the same as Microsoft's, but it also adds an Exploit Blocked alert and log entry in case the buffer would have been overflown, as this would highly likely be a result of an exploitation attempt instead of something that would occur under normal circumstances.



MODULE_PATH "..\Affected_Modules\dns.exe_6.1.7601.24437_64bit\dns.exe"
PATCH_ID 597
PATCH_FORMAT_VER 2
VULN_ID 6993
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x7be32
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 21            ; eliminate some original instructions that we'll add back in
    PIT dns.exe!0x7be6c
    
    code_start
        movzx eax, word[rdi+0Eh]    ; SIG request length
        cmp ax, 12h            ; is length below 12h?
        jb EXPLOIT_EXIT            ; packet is not valid - jump to exploit exit.
       
        movzx r8d, byte[rdi+42h]    ; get signer's name length (A.mal in the exploit example)
        sub ax, 12h            ; sub 12h from SIG request length
        lea ecx, [r8+2]            ; add 2 to signers name length
        cmp ax, cx            ; compare SIG request length and signer's name length
        jb EXPLOIT_EXIT            ; if signers name length is longer, jump to exploit exit.
       
        sub ax, cx            ; sub signer's name length from SIG request length
        cmp rsi, r11            ; r11 = sprintfSafeA return (end of string), rsi = end of buffer
        jb EXPLOIT_EXIT            ; jump to exploit exit if rsi < r11
       
        movzx r10d, ax            ; r10 = SIG request length - signer's name length
        mov eax, 0x55555556        ; eax = 0x100000000 / 3
        imul r10d            ; edx:eax = r10 * 0x100000000 / 3 (rdx = r10 / 3)
        mov eax, edx            ; eax = r10 / 3
        shr eax, 1Fh            ; eax = lowest bit of (r10 / 3)
        add edx, eax            ; add the lowest bit of eax ro edx (i.e., round up the division)
        lea eax, [4+rdx*4]        ; eax = 4*(rdx+1) - length of the base64-encoded string
        movsxd rcx, eax            ; rcx = length of the base64-encoded string
        mov rax, rsi            ; rax = end of buffer
        sub rax, r11            ; rax = end of buffer - end of existing string (i.e., space available)
        cmp rax, rcx            ; is space available less than length of base64-encoded string?
        jl EXPLOIT_EXIT            ; if so, go to exploit exit
       
        movzx eax, byte[rdi+42h]    ; original code preparing arguments for Dns_SecurityKeyToBase64String call
        lea rcx, [rax+rdi+44h]
        mov edx, r10d
        add rcx, r8
        mov r8, r11
        jmp END
       
    EXPLOIT_EXIT:
        mov r11, 0            ; r11 is later moved to rax which is the return of the function
        call PIT_ExploitBlocked        ; we call Exploit Blocked
        jmp PIT_0x7be6c            ; jump to last function block
    
    END:                    ; continue normal execution
    code_end
    
patchlet_end


Here's a video of the micropatch in action. You can see that without our micropatch, the POC, launched by a local non-admin user, successfully gets the DNS Service to crash (manually stopping the service just makes the crash happen earlier so we don't have to wait). This could be leveraged to remote arbitrary code execution of attacker's code as Local System. With our micropatch applied, the POC is blocked because the corrected code prevents writing beyond the allocated memory buffer.




We created this micropatch for the following Windows versions:

  1. Windows Server 2008 R2 without Extended Security Updates, updated to January 2020
  2. Windows Server 2008 R2 with year 1 of Extended Security Updates, updated to January 2021

According to our guidelines, this micropatch requires a 0patch PRO license. By the time you're reading this, the micropatch has already been distributed to all licensed online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), create an account in 0patch Central, install 0patch Agent and register it to your account with appropriate amount of PRO licenses. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

We'd like to thank Eoin Carroll and Kevin McGrath for their analysis of the vulnerability, which allowed us to create a micropatch.



While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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




 


Remotely Exploitable 0day in Internet Explorer Gets a Free Micropatch

17 February 2021 at 16:03

 


 by Mitja Kolsek, the 0patch Team

 

[Update 3/10/2021: March Windows Updates brought an official patch for this critical vulnerability and assigned it CVE-2021-26411. 0patch users had this issue patched since February 17, full 20 days before the official patch became available.]

On February 4, 2021, security researchers at ENKI, a South Korean security consultancy, published a blog post detailing an unpatched vulnerability in Internet Explorer. This "0day" vulnerability was used in an attack campaign against various security researchers, including ENKI researchers, who noticed the attack and took the exploit apart to extract the vulnerability information. ENKI researchers kindly shared their proof of concept with us, so we could quickly start analyzing the vulnerability and create a micropatch for it.

The vulnerability is a "double free" bug that can be triggered with JavaScript code and causes memory corruption in Internet Explorer's process space. As is often the case, this memory corruption could be carefully managed and turned into arbitrary read/write memory access - which can then be leveraged to arbitrary code execution. Attackers delivered the exploit in an MHTML file to ensure recipients would open it in Internet Explorer (which is registered to open this file type). While this delivery method required recipients to confirm a security warning about executing active content, the exploit could be delivered without such warning if the victim visited a malicious web site with Internet Explorer. 

In such case, just opening the malicious web site would instantly, or a benign web site hosting a malicious ad, would result in malicious native code execution inside Internet Explorer's render process running (by default) in Low Integrity. Such code could read any data from the computer and network that the user running Internet Explorer could read, and silently send it to attacker. An additional vulnerability would be needed to escape the "Low Integrity sandbox" and achieve a long-term compromise of the computer.

Is anyone still browsing the web with Internet Explorer? While Internet Explorer is not widely used for browsing web sites anymore, it is installed on every Windows computer and (a) opens MHT/MHTML files by default, (b) is being used internally in many large organizations, and (c) executes HTML content inside various Windows applications.

 

The Vulnerability

Exploit and proof-of-concept have not been published yet and we won't be the first to do so, but the root of this vulnerability is not new - it's about tricking the browser to delete an object that has already been deleted in some unexpected way that existing sanitization checks don't notice. In this case, it's about deleting a node value of an HTML Attribute. The trick is to create an attribute, assign it a value that is not a string or a number, but an object (why is this even allowed?) - then when deleting this attribute, said object makes sure that the attribute is deleted before it gets deleted, so to speak.

 

The Micropatch

While Internet Explorer developers will probably fix the way the attribute node is deleted so that it doesn't actually get deleted while references to it still exist, we decided that such approach would simply require too much time for us and would introduce an unnecessary risk of breaking something. We thus rather decided to break the obscure browser functionality that allows setting an HTML Attribute value to an object. We assess this functionality to be useful to very few web developers whose apps are supposed to work with Internet Explorer.

Our micropatch gets applied inside the CAttribute::put_ie9_nodeValue function of mshtml.dll, where it checks the VARIANT type of the value that JavaScript code wants to assign to an attribute - and prevents that from happening if the type is 9 (VT_DISPATCH) - which is used for Object, Array, or Date.




The 64bit micropatch only has 5 CPU instructions, and the 32bit one has 6 CPU instructions.

 



MODULE_PATH "..\Affected_Modules\mshtml.dll_11.0.9600.19597_64bit\mshtml.dll"
PATCH_ID 560
PATCH_FORMAT_VER 2
VULN_ID 6943
PLATFORM win64

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0xbf34b4

 N_ORIGINALBYTES 5
 PIT mshtml.dll!0xbf359f ; address of exit block

 code_start

  ; we're going to check the incoming VARIANT's data type; if it's 9 (object), we're going
  ; to prevent it from being copied to the attribute.
  ; The incoming VARIANT is pointed to by rdx, and the type is in the first byte.

  mov r14, rcx         ; replicate the instruction we're injected in front of to make sure
                       ; rcx is stored in r14 in case we jump to the exit block (where rcx is
                       ; restored from r14)
  cmp byte [rdx], 0x09 ; is the incoming VARIANT data type 9 (object)?
  jne DO_NOTHING       ; if not, we don't interfere
 
  mov rbx, 0            ; return value - we simulate a successful operation
  jmp PIT_0xbf359f     ; jump to exit block
 
 DO_NOTHING:

 code_end
    
patchlet_end



Here's a video of the micropatch in action:




The micropatch applies to the following Windows versions (32bit and 64bit). 

Updated to February 2021:

  1. Windows 7 + ESU (first update from ESU year 2)
  2. Windows Server 2008 R2 + ESU (first update from ESU year 2)
  3. Windows 10 v1809, v1909, v2004, v20H2
  4. Windows Server 2016, 2019

Updated to January 2021:

  1. Windows 7 + ESU (last update from ESU year 1)
  2. Windows Server 2008 R2 + ESU (last update from ESU year 1)
  3. Windows 10 v1809, v1909, v2004, v20H2
  4. Windows Server 2016, 2019 

Updated to January 2020:

  1. Windows 7 without ESU (last free update without ESU)
  2. Windows Server 2008 R2 without ESU (last free update without ESU)
 

Online Test

 
We have prepared a simple online test to demonstrate how our micropatch changes the behavior of Internet Explorer. To perform this test, you have to use Internet Explorer 11 on one of the Windows systems listed above.

Step 1: With 0patch disabled, open https://0patch.com/poc/IE_Attribute_nodeValue_0day/test.html in Internet Explorer 11. The web page should look like the image below, indicating 6 FAILed tests.

 
Step 2: With 0patch enabled, press F5 to refresh the test page in Internet Explorer 11. The web page should look like the image below, indicating no failed tests.

 
 
According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it. By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
 
We'd like to thank ENKI researchers for their analysis of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.



While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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

Windows Print Spooler Keeps Delivering Vulnerabilities, And We Keep Patching Them (CVE-2020-1030)

11 February 2021 at 14:54

 

 

by Mitja Kolsek, the 0patch Team

 

Security researcher Victor Mata of Accenture published a detailed analysis of a binary planting vulnerability in Windows Print Spooler (CVE-2020-1030), which they had previously reported to Microsoft in May 2020, and a fix for which was included in September 2020 Windows Updates.

The vulnerability (see proof-of-concept) lies - once more - in Print Spooler, this time indiscriminately creating a new "spooler" folder wherever a low-privileged local user instructed it to, doing so as a Local System account and giving said user powerful permissions on such folder. While this "feature" could probably be exploited in many other ways, there is a convenient exploitation target inside the Print Spooler service itself. Namely, the service tries to load a "point and print" driver from folder %SYSTEMROOT%\System32\spool\drivers\<ENVIRONMENT>\4, which does not exist, but can be created using this very "feature".

Microsoft's patch for this issue fixed the way a non-admin user can specify the spooler folder for a printer: Print Spooler service now checks (while impersonating the user) if said user has sufficient permissions to create such folder, including some symbolic link checks to thwart symlink-related shenanigans Print Spooler has been found to be riddled with.

Our micropatch does logically the same, and unfortunately is quite large for a micropatch (172 instructions) because the symlink checks just take a lot of code.

The micropatch was only written for Windows 7 and Windows Server 2008 R2 both (32bit and 64bit) without Extended Security Updates, because other supported systems can (and should) resolve it by applying Windows Updates.

This micropatch has already been distributed to all online 0patch Agents with a PRO license. To obtain the micropatch and have it applied on your computers along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

And don't forget, if your organization has Windows 7 or Server 2008 R2 machines pending ESU subscription renewal and wouldn't mind saving lots of money and stress on security patching in 2021 that doesn't even make you restart computers, proceed to this New Year's Resolution.

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

We'd like to thank Victor Mata of Accenture for publishing their analysis and providing a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.

Micropatches for CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094?

10 February 2021 at 21:07

by Mitja Kolsek, the 0patch Team

 

Users are asking about micropatches for CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094, remotely exploitable vulnerabilities in Windows TCP/IP stack that were fixed by February 2021 Windows Updates (and left unpatched on Windows 7 and Server 2008 R2 machines without Extended Security Updates (year 2).

According to Microsoft's blog post on the matter, the two "arbitrary code execution" vulnerabilities are "complex which make it difficult to create functional exploits, so they are not likely in the short term," but that denial-of-service attacks could quickly be devised (from reverse-engineering of patches, we assume).

At the time of this writing (February 10, 2021) we're not developing patches for these vulnerabilities. The main reason is that in order to create a patch, we need to be able to reproduce the vulnerability, i.e., we need to have a proof-of-concept or an exploit that triggers it. None of these have been published or made otherwise available yet. (For the same reasons, they're also not available to attackers.) While we could reverse-engineer patches and try to create our own exploits, our time is better spent on fixing vulnerabilities we (and attackers) already can reliably reproduce, especially if official patches for them do not exist yet (such as this Internet Explorer 0day).

A likely second reason for not patching these vulnerabilities even if we were able to reproduce them would be that these vulnerabilities are likely entirely in Windows kernel, and Microsoft's Patch Guard prevents us from patching kernel code. While this is usually not a problem as most remotely exploitable vulnerabilities are in user space (where we can patch), in this case we recommend implementing Microsoft's workarounds described in respective KB articles, specifically, executing the following on all computers without February 2021 Windows Updates or later:

netsh int ipv4 set global sourceroutingbehavior=drop
netsh int ipv6 set global reassemblylimit=0

According to Microsoft's blog post, network packets that can be used for exploiting these vulnerabilities can also be blocked by firewall, but to protect yourself from internal attackers, making the above Windows systems settings will be more effective.

 

Windows Installer Local Privilege Escalation 0day Gets a Micropatch

28 January 2021 at 09:13

 


by Mitja Kolsek, the 0patch Team

 

[Update 2/9/2021: February 2021 Windows Updates included an official fix for this vulnerability and assigned it CVE-2021-1727. According to our guidelines, this micropatch is no longer FREE, but part of a PRO subscription.]

On December 26, security researcher Abdelhamid Naceri published a blog post with a number of 0days in various security products and a local privilege escalation 0day in Windows Installer. We were mostly interested in the latter.

Abdelhamid provided a proof-of-concept (the GitHub repository is disabled at the time of this writing) which allowed us to quickly reproduce the issue on Windows 10 v2004, but we were having difficulties reproducing it on other Windows 10 versions and older Windows systems. It took us a while to troubleshoot the underlying problem with reproduction and come January 2021 Patch Tuesday, it turned out this vulnerability wasn't patched by Microsoft. Having successfully reproduced the issue by then on all Windows versions back to Windows 7, we decided to create a micropatch to protect Windows users waiting for the official patch. (The micropatch would also be the only available patch for Windows 7 without Extended Security Updates (ESU), or Windows 7 with only the first year of ESU.)


The Vulnerability

This vulnerability is a bypass of Microsoft's fix for CVE-2020-16902 (described by Abdelhamid in detail here), which was itself a bypass of Microsoft's fixes for CVE-2020-0814 and CVE-2020-1302 (also found by Abdelhamid), both of which were a bypass of Microsoft's fix for CVE-2019-1415 (found by SandboxEscaper and described here).

Confusing? Well, some things aren't easy to fix, and Windows Installer is a pretty complex beast that can break a leg if you fix its arm, and then break its tail when you fix the leg. So you want to be careful when fixing.

The core of this vulnerability, and all others listed above, is in tricking Windows Installer into using attacker's own rollback script (a *.rbs file) instead of the rollback script created by msiexec.exe during the installation. See, when installing an MSI package, Windows Installer gradually builds up a rollback script in case the installation should fail at some point, and all changes made up to that point would have to be reverted. But if a local non-admin attacker manages to replace that rollback script with one that "reverts" some system registry value such that it will point to attacker's executable..., well, we get a local privilege escalation.

The proof-of-concept is using a rollback script that changes the value of  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Fax\ImagePath to c:\Windows\temp\asmae.exe, which results in the Fax Service using attacker's asmae.exe when the service is launched. This service was used because any user is allowed to launch it, and it's running as Local System.

As far as this particular 0day goes, Microsoft's fix - which it bypasses - was attempting to block the planting of a malicious rollback script by first determining if it was safe to use the default c:\Config.Msi folder for storing the rollback script, and if not safe, using a different folder, c:\Windows\Installer\Config.Msi, instead. Abdelhamid noticed a logical flaw in this fix, forced Windows Installer to keep using c:\Config.Msi, and then performed the same steps as in his CVE-2020-16902 proof-of-concept to elevate himself to Local System.


Our Micropatch

We confess we do not understand why Microsoft decided to add more complexity with their fix for CVE-2020-16902 when they could have just unconditionally use the c:\Windows\Installer\Config.Msi folder for the callback script and completely avoid numerous attack vectors that c:\Config.Msi is exposed to. Maybe they didn't want to clutter the Windows folder.

Be it as it may, we decided that if Microsoft deemed c:\Windows\Installer\Config.Msi folder to be acceptable for hosting the rollback script under some attacker-controllable conditions, it shouldn't break anything if we forced Windows Installer to always use it for rollback scripts. It is running as Local System so permissions shouldn't be a problem, and a local attacker can't touch this folder in any relevant way.

And here it is, the single-instruction micropatch that fixes this 0day by changing the logic of Microsoft's fix for CVE-2020-16902 such that it now always decides to use c:\Windows\Installer\Config.Msi folder:



MODULE_PATH "..\Affected_Modules\msi.dll_5.0.19041.746_64bit\msi.dll"
PATCH_ID 538
PATCH_FORMAT_VER 2
VULN_ID 6912
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0xc2bcc
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    
    code_start
        mov ebx,1    ; use C:\Windows\installer\Config.Msi instead of C:\Config.Msi
    code_end
    
patchlet_end


Here's a video of the micropatch in action. You can see that without our micropatch, the POC, launched by a local non-admin user, successfully modifies a registry value pointing to the Fax Service executable, leading to execution of attacker's code by Local System. With our micropatch applied, the POC is blocked because Windows Installer cannot be tricked into using c:\Config.Msi anymore.




We created this micropatch for the following Windows versions:

  1. Windows 10 v20H2, 32bit and 64bit, updated with January 2021 updates
  2. Windows 10 v2004, 32bit and 64bit, updated with January 2021 updates
  3. Windows 10 v1909, 32bit and 64bit, updated with January 2021 updates
  4. Windows 7, 32bit and 64bit, with ESU, updated with January 2021 updates
  5. Windows 7, 32bit and 64bit, without ESU, updated with January 2020 updates

What about Windows Servers? Fortunately, Windows Servers have a default security policy preventing non-admin users from launching any installations, which successfully prevents exploitation of this vulnerability. Nevertheless, our Windows 7 micropatches will also work on Windows Server 2008 R2, updated to January 2020 (without ESU), or to January 2021 (with ESU) should their system configuration allow non-admin installations.

According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it. By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
 
We'd like to thank Abdelhamid Naceri for their analysis of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.



While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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

Local Privilege Escalation 0day in PsExec Gets a Micropatch

7 January 2021 at 17:57

 

 

by Mitja Kolsek, the 0patch Team

[Update 3/25/2021: Seventy-seven days after we had issued a free micropatch for a local privilege escalation in Microsoft PsExec, a new PsExec version fixes the issue. 0patch users staying on version 2.32 remain protected by our micropatch. This issue was assigned CVE-2021-1733, although it was not properly fixed in version 2.32 as stated in Microsoft's advisory.]
 
[Update 2/17/2021: Corrected a sentence implying that PsExec may be part of various enterprise tools, while it's just commonly used in conjunction with such tools. (Thanks @wdormann)]

[Update 1/28/2021: Since our publication of micropatch for PsExec version 2.2, PsExec has been updated to versions 2.30, 2.31 and finally 2.32. where it still resides today. David was able to update his POC for each version so the current version 2.32. is still vulnerable to the same attack. Since this version seems to be here to stay for a while, we decided to port our micropatch to it to keep 0patch users with the latest PsExec version protected.]

Last month, security researcher David Wells of Tenable published an analysis of a local privilege escalation vulnerability in PsExec, a powerful management tool from SysInternals (acquired by Microsoft) that allows launching executables on remote computers.
 
It would be hard to find a Windows admin who hasn't used PsExec at some point in time, and just a tiny bit less hard to find one who isn't using it on a regular basis. Granted, some may not even know they're using PsExec because it's commonly used in conjunction with various enterprise tools - tools like JetBrains TeamCity, BMC Server Automation, Chocolatey and SolarWinds Orion.

The Vulnerability

 
The vulnerability is a pretty classic named pipe hijacking (a.k.a. named pipe squatting). When PsExec tries to launch an executable on the remote computer, it creates a temporary Windows service there using PSEXESVC.EXE which it extracts from its own body, launches that service under Local System user, and connects to its named pipe to provide it launch instructions. PSEXESVC.EXE creates the named pipe with permissions that don't allow a non-admin or non-system user to connect to it, which is good because otherwise any user could instruct the service to run arbitrary executable as Local System.
 
Now, the attack comprises a malicious local unprivileged process creating a named pipe with the same name as PSEXESVC.EXE uses, only before the service creates it. PSEXESVC.EXE, running as Local System, subsequently tries to create the same named pipe, but merely re-opens the existing one, leaving its permissions intact. At that point, attacker can connect to the named pipe and make the service run anything.
 
David has provided an elegant proof-of-concept for this vulnerability.
 
So which systems are at risk by this issue? Basically every Windows machine that admins remotely launch executables on using PsExec (or management tools utilizing PsExec) if the machine already has a non-admin attacker there trying to elevate their privileges.


Official Patch? It's... Complicated

 
At the time of this writing, there is no official patch available from Microsoft. PsExec.exe, and PsExec64.exe, which encapsulate the vulnerable PSEXESVC.EXE, are part of the PsTools suite, and were last updated in June 2016. According to Tenable's write-up, PsExec versions from 1.72 (built in 2006) to the latest version 2.2 (built in 2016) are all affected, meaning that the vulnerability has been there for about 14 years. [Update 1/28/2021: current version 2.32 is still affected.]

Note that PsExec is not part of Windows, and is also unlikely to be patchable with Windows Updates as it doesn't even have a designated installation location (one can just copy it anywhere and use it as a standalone executable). PsExec also doesn't have its own integrated update mechanism, meaning that while Microsoft can issue a new, patched version of it and put it on their website, all the vulnerable PsExec's out there will remain vulnerable until admins manually replace them with this new version.


Our Micropatch

 
Let's see how the relevant part of PSEXESVC.EXE looks where named pipe is created and connection requests accepted.



Function CreateNamedPipe is being called in a loop, each time waiting for an incoming request, spawning a new thread to process that request, and repeating the loop.
 
When fixing named pipe hijacking/squatting vulnerabilities, the obvious approach that comes to mind is using the FILE_FLAG_FIRST_PIPE_INSTANCE flag in the CreateNamedPipe call, which only allows the pipe to be created if it is the first instance of the pipe. We actually tried this approach but while it stopped the attack (as attacker's pipe was the first instance), it also broke PsExec because in the above loop, when the first request is accepted and sent for processing, a new instance of the pipe gets created - which is no longer the first instance.
 
So we went for the second best option - checking for existence of the named pipe immediately before the loop. We used a call to CreateNamedPipe with FILE_FLAG_FIRST_PIPE_INSTANCE to determine if a named pipe with this name already exists - and if so, we immediately terminate PSEXESVC.EXE, logging an "Exploit Blocked" event in the process.

Our micropatch has only 21 CPU instructions and should be easy to understand for anyone knowing x86 assembly and Windows API functions:
 


MODULE_PATH "..\Affected_Modules\PSEXESVC.exe_2.2_32bit\PSEXESVC.exe"
PATCH_ID 536
PATCH_FORMAT_VER 2
VULN_ID 6910
PLATFORM win32

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x38ae
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 12
    PIT Kernel32.dll!CreateNamedPipeW,PSEXESVC.exe!0x4e7a,Kernel32.dll!CloseHandle,Kernel32.dll!ExitProcess
    
    ; 0x4e7a -> __swprintf

    code_start   
        ; first three instructions repeated from original code to make
        ; room for the patch JMP
        lea eax, [ebp-414h]        ; buffer for pipe name
        push eax                   ; buffer on stack
        call PIT_0x4e7a            ; call __swprintf
        push 0                     ; lpSecurityAttributes
        push 0                     ; nDefaultTimeOut, A value of zero will result
                                   ; in a default time-out of 50 milliseconds.
        push 10000h                ; nInBufferSize
        push 10000h                ; nOutBufferSize
        push 0ffh                  ; nMaxInstances (the same number must be specified
                                   ; for other instances of the pipe.)
        push 6                     ; dwPipeMode (The same type mode must be specified
                                   ; for each instance of the pipe.)
        push 80003h                ; dwOpenMode - FILE_FLAG_FIRST_PIPE_INSTANCE
        lea eax, [ebp-414h]        ; buffer for pipe name
        push eax                   ; lpName
        call PIT_CreateNamedPipeW  ; Creates an instance of a named pipe and returns
                                   ; a handle for subsequent pipe operations.
        mov edi, eax
        cmp eax, 0xFFFFFFFF        ; check if handle exists
        jne CONTINUE               ; if Handle != -1 (INVALID_HANDLE_VALUE) continue
                                   ; with normal execution
       
        call PIT_ExploitBlocked    ; Exploit blocked pop up
        push -1                    ; uExitCode
        call PIT_ExitProcess       ; Ends the calling process and all its threads.   
    
    CONTINUE:
        push edi                   ; edi = pipe handle
        call PIT_CloseHandle       ; close the pipe handle.
    code_end
    
patchlet_end



Here's a video of the micropatch in action:





According to our guidelines, this micropatch is immediately available to ALL 0patch users for absolutely no cost. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatches.

 

Frequently Asked Questions [Updated 1/28/2021]

 
Q: Which versions of PsExec does the micropatch fix?

A: Our micropatch currently applies to 32bit and 64bit PsExec versions 2.2 and 2.32. We might port it to older versions of PsExec as needed.
 
 
Q: How do we get the micropatch applied?
  1. Create a free 0patch account at https://central.0patch.com.
  2. Download and install 0patch Agent on all computers on which you're running executables with PsExec, then register it to your 0patch account.
  3. Make sure to use PsExec 2.2 or 2.32, or the micropatch won't get applied

Q: Does 0patch Agent have to be running on computers where we run PsExec, or remote computers where executables get launched using PsExec?
 
A: 0patch Agent needs to be running on the remote computers where executables get launched using PsExec. What PsExec does is copy PSEXESVC.EXE to the remote computer (into c:\Windows) and registers it remotely as a service on that computer, then launches that service. This remote PSEXESVC.EXE is what needs to be patched. Note that 0patch Agent can also safely be running on the computer where you run PsExec.
 
 
Q: Can we easily deploy this patch to multiple computers?
 
A: 0patch Agent supports silent (unattended) installation with auto-registration, and central management via 0patch Central. Please see User Manual for details and ask [email protected] for an Enterprise trial.


Q: Will the micropatch also fix PsExec that is integrated into our enterprise product?

A: As long as PsExec used by the product is version 2.2 or 2.32, our micropatch will fix it. But again, 0patch Agent must be present on computers being managed by the enterprise product, not on the machine where said product is installed. If your enterprise product is using another version of PsExec and you cannot replace it, please contact [email protected].


Q: Is there any other way to prevent exploitation of the described vulnerability?

A: Not to our knowledge. Until Microsoft issues a fixed version of PsExec, ours is the only patch that exists.


Q: Is this vulnerability a big deal?

A: Depends on your threat model. This vulnerability allows an attacker who can already run code on your remote computer as a non-admin (e.g., by logging in as a regular Terminal Server user, or establishing an RDP session as a domain user, or breaking into a vulnerable unprivileged service running on the remote computer) to elevate their privileges to Local System and completely take over the machine as soon as anyone uses PsExec against that machine. For home users and small businesses this is probably not a high-priority threat, while for large organizations it may be.



We'd like to thank  David Wells of Tenable for their excellent presentation of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.

While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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

Micropatch is Available for WSUS Spoofing Local Privilege Escalation Vulnerability (CVE-2020-1013)

23 December 2020 at 18:12

 

by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1013, a WSUS spoofing local privilege escalation vulnerability.

This vulnerability was patched by Microsoft with September 2020 Updates, but POC became available in October when original researchers from GoSecure published it.Windows 7 and Server 2008 R2 users without Extended Security Updates remained vulnerable so we decided to create a micropatch for them.
 
This turned out to be harder than we had expected - not because it was hard to write a micropatch but because it was difficult to reproduce the issue on these platforms (the original POC was written for Windows 10). We had to dive deep into communication between Windows Update client and WSUS and its specifics for Windows 7, all the while multitasking on several other vulns, and finally ended up with a working POC - quickly followed by a micropatch.
 
Note that while Windows 7 and Server 2008 R2 machines without Extended Security Updates obviously don't receive operating system updates anymore, it makes sense to keep them connected to WSUS in order to receive updates for various installed Microsoft products.

The vulnerability lies in Windows Update client's willingness to honor the proxy set by a low-privileged user, while also trusting certificates from such user's certificate store. This means that even if the update client was configured to contact WSUS via HTTPS, a local attacker could redirect its communication through their own proxy using a self-signed certificate. Meta data provided to the update client would then be trusted, and long story short, attacker's file would be stored to a chosen location on the computer, where it would later be executed with high privileges. 
 
Microsoft's patch prevents Update Client from honoring user-defined proxy, and also provides a way to re-enable this feature via registry.
 
Our micropatch also prevents Update Client from honoring user-defined proxy in logically identical way to Microsoft's, while admins can re-enable the feature by simply disabling the micropatch.
 
A video of the micropatch in action:




We'd like to thank  Maxime Nadeau of GoSecure for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

And don't forget, if your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution.

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

2021 New Year's Resolution: "We Will Spend Less Time and Money on Security Patches"

15 December 2020 at 09:21

 


It's been over a year since we had announced our "security adoption" of Windows 7 and Windows Server 2008 R2 after they would reach end of support in January 2020. Starting with February 2020, the first Patch Tuesday without free security updates, we began actively collecting details on high-risk vulnerabilities affecting these Windows versions and issuing micropatches for them.

Until now, we've issued micropatches for 24 such vulnerabilities in Windows 7 and Server 2008 R2, including some 0days (i.e., vulnerabilities for which there was no official patch from Microsoft yet, such as this one) and our most popular server micropatch for the Zerologon vulnerability. Additional micropatches will surely be issued by the end of our first 12 months of keeping Windows 7 and Server 2008 R2 secure.

Many organizations that kept Windows 7 and Server 2008 R2 in their networks after January 2020 have purchased Extended Security Updates ("ESU"), which Microsoft pledged to provide for three additional years - with their price doubling in the second year, and again in the third year. For Windows 7, ESU was priced somewhere between $25 and $50 per computer for the first year, and for Server 2008 R2 at about 75% of the on-premises license cost for the first year (ouch!).

With 0patch PRO license costing about $26 (€22.95+tax) per computer per year, ESU may have seemed the better option on Windows 7 computers for organizations that wrestled a good deal from Microsoft - after all, they would get to continue doing what they did before, updating these computers every Patch Tuesday and remaining compliant while avoiding a Windows upgrade.

On servers, where 0patch PRO license costs exactly the same as on workstations, the price list was decidedly in favor of 0patch, but it's understandable that everyone is extra careful about servers and what they install on them. Consequently, many prospects we talked to ended up "going with ESU for now and keeping our eyes on 0patch until the renewal is up in 2021."

Meanwhile, Windows 7 and Server 2008 R2 are hardly going extinct. According to NetMarketShare, 24% of web traffic originating from Windows computers still comes from Windows 7 machines (33% a year ago). And both the workstation and the server are an integral part of many an expensive and/or ubiquitous medical, financial and manufacturing device - which will do their jobs quite well for years to come if only they can be kept secure.


Save Time and Money on Patches in 2021

 

Any organization still using Windows 7 or Server 2008 R2 and wishing to keep them secured is welcome to try out 0patch and see how easy, painless and inexpensive security micropatching is for fixing the vulnerabilities that really matter.

Save time with 0patch by:

  • not keeping users idle while updates are installed or uninstalled
    (micropatches get applied in-memory while users are working),
  • not rebooting all computers at least once every month
    (micropatches don't even require a restart of patched processes, much less entire computers),
  • not worrying about what the huge monthly update will break
    (micropatches change just a couple of instructions, reducing the risk of breakage to absolute minimum),
  • closing attackers' window of opportunity quickly, even automatically
    (due to low risk of breakage, micropatches can be applied instantly - but don't worry, you can also un-apply them just as instantly if you think they're causing problems).

Save money with 0patch by:

  • mainly, by simply paying much less for 0patch than for alternative sources of security patches for Windows 7 and Server 2008 R2
    (remember, 0patch PRO costs €22.95+tax per computer per year, both for workstations and servers),
  • getting Enterprise features for free by ordering before January 14, 2021
    (Enterprise features like central management, groups, group-based patching policies etc. are a free add-on to 0patch PRO in the first 12 months of our "security adoption" period).

 

Finally, if your organization happens to still be using Office 2010 and is reluctant to replace it once it stops receiving official security updates, we have more good news: Office 2010 security micropatches are included in 0patch PRO.

 

Frequently Asked Questions

 

Q: We don't have Extended Security Updates. If we start using 0patch on our Windows 7 and Server 2008 R2 computers now, will we receive all micropatches that have been issued since these systems went out of support?

A: Absolutely, 0patch PRO licenses gives you access to all patches we've issued so far and all patches we'll issue during the subscription term. Just make sure to have these computers updated with January 2020 rollup updates (the last free updates).

Q: We've purchased Extended Security Updates for 2020 but are now considering switching to 0patch. Can we keep the installed ESU updates on our computers and take it from there?

A: Yes. You should apply all ESU updates you will receive until the end of your ESU subscription, as our micropatches will be ported to the exact executable versions on so-updated machines.

Q: We'd like to try out 0patch before making a decision. How do we do that?

A: Create an account in 0patch Central and let us know at [email protected] which email address you used so we can upgrade your account to Enterprise and issue you a couple of trial licenses to work with.

Q: Where can we learn more about your security micropatches for Windows 7 and Server 2008 R2?

A: Our Help Center articles provide a lot of additional information, but you can also send an email to [email protected] with any questions that remained unanswered.


Stay safe!

@mkolsek
@0patch








 

 

 

 



0day in Windows 7 and Server 2008 R2 Gets a Micropatch

25 November 2020 at 16:15

 

by Mitja Kolsek, the 0patch Team
 
[Update 1/22/2021: This vulnerability did not get patched by December 2020 or January 2021 Extended Security Updates, so we ported our micropatch to these updates.]
 
"Lol, who's even using Windows 7 anymore?"
"According to NetMarketShare, almost one in four Windows users."
 

On November 12, 2020, security researcher Clément Labro published a detailed analysis of a local privilege escalation vulnerability affecting Windows 7 and Windows Server 2008 R2 for which no official fix exists yet (at the time of this writing). Although these Windows platforms have reached end of support in January this year but Extended Security Updates (ESU) are still available for them until January 2023 - so even fully ESU-updated machines are currently affected by this issue.

As an alternative to ESU, we at 0patch have "security adopted" Windows 7 and Windows Server 2008 R2 and are providing critical security patches for these platforms. Consequently, vulnerabilities like this one get our attention - and, usually, micropatches.


The Vulnerability

Clément wrote a very useful permissions-checking tool for Windows that find various misconfigurations in Windows that could allow a local attacker to elevate their privileges. On a typical Windows 7 and Server 2008 R2 machine, the tool found that all local users have write permissions on two registry keys:

  • HKLM\SYSTEM\CurrentControlSet\Services\Dnscache
  • HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper

These didn't immediately seem exploitable, but Clément did the legwork and found the Windows Performance Monitoring mechanism can be made to read from these keys - and eventually load the DLL provided by the local attacker. To most everyone's surprise, not as the local user, but as Local System.

In short, a local non-admin user on the computer just creates a Performance subkey in one of the above keys, populates it with some values, and triggers performance monitoring, which leads to a Local System WmiPrvSE.exe process loading attacker's DLL and executing code from it.

 

The Micropatch 

Now this is clearly a case of incorrect permissions on the above registry keys, and the solution should be obvious - correcting these permissions. However, we don't want our micropatches to make any global changes to the system, so we decided to address this in the code.

We analyzed where the Performance registry key is being read in Windows libraries and found that to be in advapi32.dll, function OpenExtensibleObjects, as a result of a call to RegKeyOpen* function with one of the performance-related predefined keys, in our case HKEY_PERFORMANCE_DATA.

Function OpenExtensibleObjects iterates through all services in the registry looking for Performance keys, and we decided to patch it so that it would ignore this key in both affected services - making it look as if the Performance key wasn't there even if it was.

This obviously breaks performance monitoring for the affected services but that's a trade-off we believe is beneficial to our users. In case performance monitoring is needed for these services, the micropatch can always be temporarily disabled (again, no restart of the service, much less of the computer, is needed for that).


Source code of the micropatch

The video below shows how the attack works on a Windows 7 computer exploiting bad permissions on the Dnscache registry key. An identical attack could be mounted using the RpcEptMapper key.

 


This micropatch is immediately available to all 0patch users, including those with a FREE plan. It is targeted at:
 
  1. Windows 7 and Server 2008 R2 computers without ESU, updated to January 2020, and 
  2. Windows 7 and Server 2008 R2 computers with ESU, updated to November 2020, 
  3. [Updated 1/22/2021] Windows 7 and Server 2008 R2 computers with ESU, updated to December 2020 or January 2021
 
According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it (presumably only as part of Extended Security Updates). By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center
 
We'd like to thank  Clément Labro for sharing their analysis and POC, which allowed us to create this micropatch for Windows users. We also encourage security researchers to privately share their analyses with us for micropatching, and further increase the positive impact of their work.
 
Most of the analysis was done by our young micropatching expert Ziga Sumenjak.
 
And finally, just one "frequently" asked question:
 
Q: "Can't I simply manually tighten permissions on affected registry keys to remove the risk instead of using 0patch?"
 
A: "Yes you can (or you can use this batch script to create Performance keys with tightened permissions). We don't know, however, if that might break some functionality under some conditions. It's quite likely that Microsoft didn't set such permissions by accident."

 

 







0patch Keeps Office 2010 Secured After End-Of-Support

5 November 2020 at 14:40

by Mitja Kolsek, the 0patch Team


[Update Jan 13, 2020: Microsoft issued further updates for Office 2010 in January 2021. We have updated this article accordingly.]

[Update Dec 15, 2020: Microsoft issued further updates for Office 2010 in December. We have updated this article accordingly.]

[Update Nov 14, 2020: In contrast to announced end of updates for Office 2010 in October, Microsoft issued additional updates for Office 2010 in November. We have updated this article accordingly.]

Remember how we "security adopted" Windows 7 and Server 2008 R2 when they've reached end-of-support in January 2020? Since then, we've issued micropatches for 21 high-risk vulnerabilities in these systems, the most popular undoubtedly being our micropatch for Zerologon (CVE-2020-1472), a vulnerability affecting virtually all Windows domains and being currently widely exploited by ransomware gangs.

With Office 2010 having reached end-of-support last month, and many organizations expressing interest in keeping it (secure), we've decided to "security adopt" Office 2010 as well. This service is already generally available at the time of this writing.

How does this work? Similarly to what we do for Windows 7 and Windows Server 2008 R2, we collect vulnerability information for Office 2010 from a variety of sources: partners, security community, public sources, and also by testing if newly discovered vulnerabilities affecting still-supported Office versions might also affect Office 2010. When we come across a vulnerability that in our assessment presents a high risk and have sufficient data to reproduce it, we create a micropatch for it that works on fully updated Office 2010. Just as for Windows 7 and Server 2008 R2, Office 2010 has to be updated with latest available official updates, i.e., January 2021 updates.

Security micropatches for Office 2010 are included in 0patch PRO subscription currently priced at 22.95 EUR + tax/computer/year (volume discount available) that already provides access to all our micropatches. Enterprise features such as central management, groups, group-based patching policies, and notifications are available for organizations managing large numbers of Office 2010 installations they want to keep secured with minimal effort.

Organizations running at least 100 Office 2010 installations on supported Windows OS versions (therefore not needing all our PRO micropatches), have an option to subscribe to just Office 2010 security micropatches for a significantly discounted price.

So what do you have to do to protect your Office 2010 installations with 0patch? You need to make sure all Office 2010 updates are installed, create a 0patch account in 0patch Central, install 0patch Agent and register it to your account, then purchase a PRO subscription for a suitable number of licenses or ask [email protected] for a free trial.

We will initially provide security patches for Office 2010 for 12 months, and then extend this period if faced with sufficient demand.

 

Frequently Asked Questions

 

Q: What do I have to do to receive Office 2010 micropatches?

A: To receive our post-End-of-Support Office 2010 micropatches, you have to:

  1. Have your Office 2010 installation updated with all available updates up to including January 2021 (the latest official updates).
  2. Install 0patch Agent on each computer running Office 2010 you want to protect with 0patch, and register these agents with your 0patch account. (Use silent installation with auto-registration for larger deployments.)
  3. Have a suitable number of 0patch PRO or 0patch Enterprise licenses in your 0patch account.
  4. Allow your 0patch-protected computers to connect to 0patch server (host dist.0patch.com, port 443) for periodic syncing in order for them to receive new micropatches and in order for you to remotely manage them (included in the Enterprise license)


Q: Do you provide patches for all known vulnerabilities affecting Office 2010?

A: We collect vulnerability information for Office 2010 from a variety of sources: partners, security community, public sources, and also by testing if newly discovered vulnerabilities affecting still-supported Office versions might also affect Office 2010. When we come across a vulnerability that in our assessment presents a high risk and have sufficient data to reproduce it, create a micropatch for it that works on fully updated Office 2010.

Consequently, an Office 2010 vulnerability may become known but it may pose too low a risk to warrant micropatching. Also, we may not have sufficient data about the vulnerability to be able to reproduce it and therefore create a micropatch. Should this happen, we will certainly utilize our connections with researchers and partners to obtain such data.

As a reference, we've been providing security micropatches for Windows 7 and Windows Server 2008 R2 since January 2020 and issued micropatches for 21 high-risk vulnerabilities in the first 9 months of the service.

Q: How long do you plan to provide Office 2010 Micropatches?

A: Initially we plan to provide Office 2010 security patches for 12 months, i.e., until October 2021. Depending on the interest from our users, we may decide to extend our support term for another 12 months.

Q: Are Office 2010 security patches part of 0patch PRO and Enterprise, or a separate subscription?

A: Office 2010 security patches are part of 0patch PRO and 0patch Enterprise; there are currently no other plans available. (See also this article.)

Q: Are post-EOS Office 2010 micropatches also available to home/personal users?

A: Yes, our post-EOS (post-End-of-Support) Office 2010 patches are available to all users with 0patch PRO or 0patch Enterprise license. So whether you're a home user with just one or a couple of computers, a small business with dozens of computers, or a large organization with a Windows fleet of tens of thousands, you're getting these micropatches if you purchase a 0patch PRO license.

We may occasionally decide to provide some of these micropatches to 0patch FREE users as well, for instance to help slow down a global worm outbreak.

Q: Can I use Office 2010 micropatches on still-supported Windows versions such as Windows 10?

A: Of course. 0patch Agent works on all supported Windows versions, and if you have Office 2010 installed there (and fulfill all requirements), our micropatches will get applied to it. (See also this article.)

Q: I only need Office 2010 security patches but not all other patches included in 0patch PRO subscription. Are any discounts available?

A: We understand that some organizations may need security micropatches for Office 2010 installed on still-supported Windows versions such as Windows 10, and not need any other micropatches we're issuing. If your organization needs to protect at least 100 Office 2010 installations, we welcome you to contact [email protected] for information about available discounts.

Q: Should we deploy 0patch now or wait until a serious Office 2010 vulnerability appears?

A: It is likely that sooner or later, a critical vulnerability will be found affecting Office 2010 and requiring rapid response from users and organizations in absence of an official fix from Microsoft.

If you're a home user or a small business where deploying a new product is a simple and quick process, feel free to wait and deploy 0patch when needed. (Knowing that you'd be missing out on our micropatches for other applications and 0days.)

However, for any sizeable organization we recommend doing a pilot/trial as soon as possible to make sure you've properly tested 0patch and ironed out any technical issues before the critical micropatch is needed across your network. To set up a pilot or a trial please contact [email protected].


For any additional questions regarding this service, please consult Frequently Asked Questions About Office 2010 Micropatches or, failing to find your answers there, contact [email protected].

 

Cheers!

@mkolsek
@0patch



Micropatch for Zerologon, the "perfect" Windows vulnerability (CVE-2020-1472)

17 September 2020 at 17:01

 


 

by Mitja Kolsek, the 0patch Team
 
 
The Zerologon vulnerability allows an attacker with network access to a Windows Domain Controller to quickly and reliably take complete control of the Windows domain. As such, it is a perfect vulnerability for any attacker and a nightmare for defenders. It was discovered by Tom Tervoort, a security researcher at Secura and privately reported to Microsoft, which issued a patch for supported Windows versions as part of August 2020 updates and assigned it CVE-2020-1472.

Secura has subsequently released a detailed technical paper and a proof-of-concept tool that anyone could use to test whether their domain controllers were vulnerable or not. The paper revealed the underlying cryptographic flaw in Netlogon remote protocol, a legacy protocol that is still supported on all Windows servers to allow old Windows machines to work in a domain environment. The flaw is described in detail in the above-mentioned paper, but the jist of it is that the attacker has a 1:256 chance that if sending a "challenge" of all zeroes, and all subsequent values in the protocol also containing only zeroes, the request will reset server's password to an empty password. Making a sufficient number of attempts, say 2000 as in the proof-of-concept tool, will succeed with extremely high probability, which we can safely approximate to 100%.


Microsoft's Fix

While most of the security community is interested in the vulnerability and its exploitation, we at 0patch care more about the fix. Critical Windows vulnerabilities are most often of memory corruption flavor, and thus generally easy to fix, but when a cryptographic flaw comes by, there's a possibility that the fix will introduce a lot of new complex code. (Spoiler: not in this case.)

Since Netlogon remote protocol still holds together many production environments with old Windows computers, we knew that Microsoft's fix couldn't include any significant design changes unless it was also ported to long-unsupported Windows versions such as Server 2003, Server 2008 and Windows NT; breaking these systems on a global scale would, with only moderate dramatization, take us back to the dark ages.

Fortunately, Microsoft is highly disciplined when it comes to documentation: the Netlogon remote protocol page shows that the protocol specification was last changed in August 2020 - a good sign for us. Furthermore, they provide a handy "diff" document for every version so it's easy to find changes. The August 2020 diff document contains the following relevant changes:


  1. Page 102: A new setting VulnerableChannelAllowList was introduced: "A setting expressed in Security Descriptor Definition Language (SDDL) ([MS-DTYP] section 2.5.1) of Netlogon client allowed to not use secure bindings, see section 3.1.4.6. (VulnerableChannelAllowList is not supported in Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008.)"

  2. Page 104: A step was added to the session-key negotiation process: "If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps. (Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008 allow the call to succeed.)"

  3. Page 110: Two steps were added to the session-key establishment process: "4. If secure bind is not used, the server MUST deny the request unless client is in the VulnerableChannelAllowList setting. (Windows NT 4.0, Windows 2000, Windows Server 2003, and Windows Server 2008 allow the call to succeed.)" and "6. If none of the first 5 bytes of the ClientStoredCredential computation result (step 1, section 3.1.4.5) is unique, the server MUST fail session-key negotiation without further processing of the following steps. (Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008 allow the call to succeed. )"

 

The relevant change for Zerologon is obviously this: "If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps." However, what exactly does "if none of the first 5 bytes of the client challenge is unique" mean? The reader is challenged to make a mental image of what this phrase means, as anyone implementing the protocol would have to - and then read on to see how that mental image compares to Microsoft's code.

Diffing of netlogon.dll between July 2020 and August 2020 versions on Windows Server 2012 shows that function NetrServerAuthenticate3 was extended with a call to a previously non-existent function NlIsChallengeCredentialPairVulnerable and a subsequent branch to terminate the protocol in case the latter returns a non-zero value (implying that the challenge-credential pair was vulnerable).

 

Function NetrServerAuthenticate3 got a new security check in August 2020

Now let's look at the new function, NlIsChallengeCredentialPairVulnerable. The client-provided challenge is stored in a buffer pointed to by rcx. First, some global variable is checked: if it is 1, the function returns 0 ("not vulnerable"). We don't know what this global variable is and we found no write references to it, only three places where it is being read. We suspect it might be an #ifdef'ed global variable that is hard-coded depending on the target Windows version so that even if Microsoft rebuilds netlogon.dll for, e.g., Windows Server 2003, this security check will not work - which would be consistent with the current Netlogon remote protocol specifications.

Then, rcx is checked to be non-null (kind of important, we don't want to cause access violation reading from it), and rdx is also checked to be non-null. We don't know what rdx points to and decided not to go there as rdx's value is not used at all (the register is overwritten with 1 shortly thereafter).

Now to the meat of the function: the first byte of the challenge is stored into r9d, then the next four bytes are compared to it in a loop. If any of these four bytes is different from the first byte, the function returns 0 ("not vulnerable"). Otherwise, it returns 1 ("vulnerable"). This covers the case from the proof-of-concept tool, where the challenge is all zeroes, but it also covers challenges starting with 11111, 22222, 33333, etc., which would also be deemed malicious by this logic. We assume Microsoft asked one of its crypto experts how to fix this and they at least thought it possible (if not outright feasible) that challenges consisting of equal non-zero bytes could also be used for an attack, perhaps a less trivial one. [Update 9/18/2020] If we were any good at reading, we would notice this part in Secura's report: "When an IV consists of only zeroes, there will be one integer 0 ≤ X ≤ 255 for which it holds that a plaintext that starts with n bytes with value X will have a ciphertext that starts with n bytes with value 0. X depends on the encryption key and is randomly distributed." This explains the logic of Microsoft's patch, and all-zero challenge is just the simplest challenge to exploit. 

 

NlIsChallengeCredentialPairVulnerable checks if the first five challenge bytes are equal.

And why check only the first 5 bytes? We assume it's either because (a) Microsoft calculated that even if a legitimate random challenge could occasionally begin with 5 equal bytes, this would only break approximately 1 in 4 billion requests, or (b) their challenge-generating code in the client makes sure that the first five bytes are not the same (which would only break 1 in 4 billion requests from non-supported Windows computers).

Now, how does this implementation match your mental image of  "if none of the first 5 bytes of the client challenge is unique"? We think something like "if all of the first 5 bytes of the client challenge are identical" would more accurately describe it, and hereby call on Microsoft to reword this sentence in a future version of the protocol.

 

Our Micropatch

The micropatch we wrote is logically identical to Microsoft's fix. We injected it in function NetrServerAuthenticate3 in roughly the same place where Microsoft added the call to NlIsChallengeCredentialPairVulnerable, but since the latter doesn't exist in old versions of netlogon.dll,  we had to implement its logic in our patch.


The source code of our Zerologon micropatch for Windows Server 2008 R2

 

The video below shows how 0patch blocks a "Zerologon" attack. The Zerologon test tool is launched against a fully patched Windows Server 2008 R2 without Extended Security Updates (i.e., patched up to January 2020) while 0patch Agent is disabled. As expected, the test tool discovers that the server is vulnerable. After enabling 0patch Agent, which applies an in-memory micropatch for CVE-2020-1472 to lsass.exe without having to reboot the system, the Zerologon test tool no longer succeeds.
 

 
 
 
 
This micropatch is immediately available to all 0patch users with a PRO license, and is primarily targeted at Windows Server 2008 R2 users without Extended Security Updates (updated with January 2020 updates!). By the time you're reading this it has already been distributed to all online 0patch Agents with a PRO license and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account, then purchase a PRO license or contact [email protected] for a free trial. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center
 
We'd like to thank Tom Tervoort from Secura for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching and further increase the positive impact of their work.
 
Most of the analysis was done by our young micropatching experts Blaz Satler and Ziga Sumenjak.
 
 

Frequently Asked Questions

 
Q: Does applying this micropatch require a computer restart?
A: No, both installation of 0patch Agent and application of the patch (to process lsass.exe) are done without restarting the computer, or restarting any process on the computer.

Q: Do we need this micropatch on a server that is not a domain controller?
A: No. Only domain controllers are vulnerable, both according to Microsoft's advisory and our own testing.

Q: How do we know this micropatch actually works on our server?
A: The best way to test is to use a non-destructive test such as the proof-of-concept tool from Secura. You should be able to replicate what is shown in the video above.
 
Q: Is Windows Server 2008 (non-R2) or Windows Server 2003 (any flavor) or Small Business Server 2008 also affected by this vulnerability?
A: To the best of our knowledge, these servers are not vulnerable to Zerologon.
 
Q: Does your micropatch work on Small Business Server 2011?
A: We're not specifically testing with SBS2011, but users are telling us that our micropatch applies to this Server 2008 R2-based Windows version. 
 
Q: We have a Windows Server 2008 R2 but your micropatch doesn't seem to be getting applied as the vulnerability test still succeeds. What is wrong?
A: The most common cause for this problem is the server not fully updated with January 2020 updates.

Q: We have a still-supported Windows server but can't apply the official update for reasons which leaves us vulnerable to Zerologon. Can you help us?
A: Please contact [email protected] and we'll port the micropatch to your specific version
 
Q: Is there anything else we need to know?
A: If your organization still has Windows Server 2008 R2 machines, you might also have some Windows 7 systems that aren't getting security patches anymore, so you should know that we're providing critical post-end-of-support security micropatches for both Windows Server 2008 R2 and Windows 7. Here is the list of micropatches we've issued so far as part of this service.
 
 

 

 





 

 

 

 

 

Micropatch is Available for Windows Task Scheduler Security Feature Bypass (CVE-2020-1113)

11 August 2020 at 15:55





by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1113, a Windows Task Scheduler Security Feature Bypass.

This vulnerability was patched by Microsoft with May 2020 Updates, but Windows 7 and Server 2008 users without Extended Security Updates remained vulnerable.

Security researcher Sylvain Heiniger (@sploutchy) of @compasssecurity analyzed this vulnerability and subsequently published a POC, from which we could reproduce the issue and create a micropatch. 
 
The vulnerability lies in Task Scheduler accepting RPC requests that can be relayed. An attacker can piggyback on such requests by having some logged-on user send an SMB request to their computer, and then act as man-in-the-middle.
 
Microsoft's patch makes sure the authentication level of the RPC request received by Task Scheduler is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, which prevents such piggybacking. Our micropatch does effectively the same, with just six CPU instructions on 32-bit Windows, and two CPU instructions on 64-bit Windows:



MODULE_PATH "..\Affected_Modules\schedsvc.dll_6.1.7601.24470_64bit\schedsvc.dll"
PATCH_ID 459
PATCH_FORMAT_VER 2
VULN_ID 6220
PLATFORM win64

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2

PATCHLET_OFFSET 0x37a1
N_ORIGINALBYTES 5
JUMPOVERBYTES 0
PIT schedsvc.dll!0x3b449

code_start

    ;This patch is inserted right after the RpcServerInqCallAttributesW call.
    ;The call fills the RPC_CALL_ATTRIBUTES_V2_W structure with data, and at
    ; address rsp+78h we can find
    ;the RPC_CALL_ATTRIBUTES_V2_W.AuthenticationLevel value, which describes
    ;the level of RPC authentication
    ;used. The range of this variable is form 0x0 to 0x6, where 0x6 is
    ;authentication with integrity (signature)

    cmp dword[rsp+78h], 6     ;Check if the RPC_CALL_ATTRIBUTES_V2_W.AuthenticationLevel
                              ; value is equal to 6
    jb PIT_0x3b449            ;If the value is less than 6, jump to the
                              ;"access denied error" block

code_end
patchlet_end



And a video of the micropatch in action:




We'd like to thank Sylvain Heiniger (@sploutchy) for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

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