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

 

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"

 

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 sales@0patch.com 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 sales@0patch.com with any questions that remained unanswered.

Stay safe!

@mkolsek
@0patch

 

 

 

 

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

 

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

by Mitja Kolsek, the 0patch Team

[Update April 2021: Microsoft issued further updates for Office 2010 in April 2021. We have updated this article accordingly.]

[Update Jan 13, 2021: 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., April 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 sales@0patch.com 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 April 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 sales@0patch.com 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 sales@0patch.com.

For any additional questions regarding this service, please consult Frequently Asked Questions About Office 2010 Micropatches or, failing to find your answers there, contact sales@0patch.com.

 

Cheers!

@mkolsek
@0patch

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

 

 

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 support@0patch.com 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 sales@0patch.com 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)

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.

New 0patch Agent is Released - Version 20.06.18.10800

Dear 0patch users,

We have just released a new 0patch Agent. We don't do that very often, for two reasons: (1) we like the software we're using to be stable, to favor reliability over novelty, and to not introduce unnecessary changes - so that's what we try to do for you; and (2) building and thoroughly testing a piece of software that needs to work reliably on multiple platforms is pretty expensive. Because of the latter, we've micropatched two functional bugs in our previous Agent version (see here and here) instead of hastily issuing a new one. Micropatching is vastly superior to the traditional rebuild-test-distribute model when fixing simple bugs (which most security bugs and many functional ones are) as it incurs minimal risk of breaking something outside the patched bits, requires only narrowly-focused testing, and allows for inexpensive and unobtrusive deployment (and revocation, if needed). 

Nevertheless, bugs and feature requests have piled up, and our server is evolving too, prompting the agent to learn a couple of new tricks.

What's new in the new 0patch Agent? If you like details, please refer to release notes, but otherwise the main changes are:

• Annoying popups in 0patch FREE are now gone and replaced by a summary popup that will tell you how many patches you're missing out on that would be relevant on your computer.
• Log is now displayed much faster in 0patch Console.
• Pop-ups are no longer shown when any application is in full screen mode.
• The above-mentioned functional bugs that we've previously micropatched have now been patched in the code, so there is no need to apply a micropatch to every process anymore.
• Failed syncs immediately after system startup (which many of you have noticed, and thankfully reported) have been fixed.
  

May we remind you that the agent is still very small, just over 4MB on the file system.

We recommend you update your agent to this new version at your earliest convenience. The update process will not require a computer restart.

Locally Managed 0patchAgents

If you're using 0patch locally on your computer, 0patch Agent has already started notifying you about a new version. To update the agent, launch 0patch Console and in the "AGENT VERSION" box, click on "GET LATEST VERSION" and let the update process complete. Note that the console will disappear in the process, and will get re-launched when the new agent version is installed.

Remotely Managed 0patch Agents

If you're managing 0patch Agents in your organization remotely through 0patch Central, your group settings will determine whether/which agents will get updated automatically and which will require a manual action on your part. To make sure all agents are updated, you can open the All Computers group, select all computers, and under ACTIONS, select "Update agent to new version."

Thank you for using 0patch! As always, we'll appreciate your feedback, bug reports, feature requests and musical recommendations at support@0patch.com.

The 0patch Team

Micropatch Available for "SIGRed", the Wormable Remote Code Execution in Windows DNS Server (CVE-2020-1350)

by Mitja Kolsek, the 0patch Team

This month's Patch Tuesday included a fix for CVE-2020-1350, a critical memory corruption vulnerability in Windows DNS Server affecting all Windows Server versions from long-unsupported Server 2003 to the latest Server 2019.

After Microsoft's initial announcement and security advisory, the CheckPoint research team published a detailed article about the issue, describing the attack vector and providing enough information for other security researchers to trigger the vulnerability. Just one day later, the first real proof-of-concept was published, developed by Max Van Amerongen (@maxpl0it) from F-Secure Labs, and later several other researchers have shown their own tools triggering the vulnerability.

We can safely assume that offensive teams worldwide are currently trying to develop a reliable arbitrary code execution exploit as they know that Windows Updates take anywhere from long to eternity before getting applied to most Windows Servers out there. Their job will not be trivial, with various exploit mitigations in place on modern Windows servers, but counting on them to fail would be a risky strategy. In addition, many companies are still using Windows Server 2008 machines with no security updates past January this year.

Numerous 0patch customers have one or more Windows 2008 Servers and we wanted to take care of them as quickly as possible. With a working proof-of-concept at hand we could easily create a micropatch for this issue. Let's look at Microsoft's patch first:

 

The image above shows the difference between vulnerable function SigWireRead (left) and its patched counterpart (right). This function was one of only three functions in dns.exe modified by the July update, and the other two were not relevant for the issue at hand.

Microsoft's patch (gray code blocks) introduced three integer overflow/underflow checks, for one subtraction and two addition operations. When faced with Max's proof-of-concept, it is the third check (the lowest gray code block) that detects the overflow and redirects execution towards function's exit instead of processing the DNS packet further - which would lead to memory corruption. 

Our micropatch does logically the same, with one difference - when integer overflow/underflow is detected, it also displays and logs an exploit attempt, allowing admins to know that their server was targeted by an exploit:

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

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x4EC89
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT dns.exe!0x4EC68
   
    code_start
        push rdi ; push to ensure normal code flow after patch
        push rax ; push to ensure normal code flow after patch
       
        ;First check
        sub rdi, rax
        cmp rdi, 0xFFFF
        ja ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
       
        ;Second check
        movzx eax, byte[rsp+30h+2*8] ; added 2*8 to the original offset to compensate for the 2 pushes at the beginning
        add ax, 0x14
        cmp ax, 0x12
        jb ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
       
        ;Third check
        lea ecx, [rax+rdi]
        cmp cx, ax
        jb ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
        jmp End ; the TCP packet is valid, continue with original code
    ExploitBlocked:
        pop rax ; restore rax to its previous value
        pop rdi ; restore rdi to its previous value
        call PIT_ExploitBlocked ; Exploit Blocked pop up
        jmp PIT_0x4EC68 ; Exit function, TCP packet not valid
    End:
        pop rax ; restore rax to its previous value
        pop rdi ; restore rdi to its previous value
    code_end
   
patchlet_end

We released our micropatch early afternoon CET today and it got applied to all online computers with 0patch PRO worldwide within 60 minutes without restarting the computer or DNS service.

This is how it looks like when a DNS server is attacked without and with 0patch:

The first instance of our micropatch is targeted at Windows Server 2008 R2 without Extended Security Updates, and we plan to port it to Windows Server 2003 next for our users who are for various reasons still using this unsupported server. [Update 7/20/2020: Micropatch is now ported to 32-bit and 64-bit Windows Server 2003.]

Although free official updates exist for all supported Windows servers, admins may not be able to apply them immediately or restart the computer; for such cases, requests for porting our micropatch to specific versions of dns.exe running on affected computers can be sent to sales@0patch.com.

If you have 0patch Agent with PRO license installed on your Windows Server 2008 R2 or Server 2003 computer, our micropatch is already downloaded and applied to your DNS server. Otherwise, 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, purchase a PRO license or request a trial at sales@0patch.com, 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 Max Van Amerongen (@maxpl0it) from F-Secure Labs for publishing their analysis and POC, and for providing additional assistance in triggering the vulnerability and simplifying our test case, thereby allowing us to create this micropatch for Windows users without official security updates.