by Mitja Kolsek, the 0patch Team
by Mitja Kolsek, the 0patch Team
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.
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:
Save money with 0patch by:
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.
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 firstname.lastname@example.org 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?
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.
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:
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.
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.
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 email@example.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.
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:
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 firstname.lastname@example.org 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@example.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 firstname.lastname@example.org.
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:
VulnerableChannelAllowListwas 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 18.104.22.168. (
VulnerableChannelAllowListis not supported in Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008.)"
VulnerableChannelAllowListsetting. (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
ClientStoredCredentialcomputation result (step 1, section 22.214.171.124) 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
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.
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|