Tuesday, January 31, 2023

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

 

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

 

The Backup Service

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


The Vulnerability

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

Now, the process of creating and deleting this temporary file is vulnerable to a TOCTOU symbolic link attack. As Filip has demonstrated, a local low-privileged attacker can trigger the backup process with some path under their control, catch the temporary file which the Backup Service creates (and hold it locked), replace it with a symbolic link to some system file they could not otherwise delete, and let the Backup Service continue with deleting said system file. This results in the service deleting a chosen file, which can be exploited for arbitrary code execution as Local System as was first shown by Jonas Lykkegård in 2020 using Windows Error Reporting Service, and subsequently also by Abdelhamid Naceri using Windows Installer. Filip's POC makes use of the latter.

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


Microsoft's Patch

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


Our Micropatch

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

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

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




Micropatch Availability

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

  1. Windows 10 v21H1
  2. Windows 10 v2004
  3. Windows 10 v1909
  4. Windows 10 v1809
  5. Windows 10 v1803
  6. Windows 7 (no ESU, ESU years 1 and 2)
  7. Windows Server 2008 R2 (no ESU, ESU years 1 and 2)
 
Note that Windows 7 and Server 2008 R2 with ESU year 3 have received Microsoft's patch with January Updates.

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

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

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

We'd like to thank  Filip Dragovic for sharing details about this vulnerability, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.

 

Thursday, January 5, 2023

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

 


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

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

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

... security patches from Microsoft, that is.

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

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

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

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

We'll be happy to set you up with a trial so you can see how 0patch works and how it co-exists with other components in your environment. Just email sales@0patch.com and you'll be quickly on your way.

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


Frequently Asked Questions


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

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

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

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

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

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

Q: We have more questions about 0patch

A: Our Help Center has a lot of answers but if you can't find yours there, feel free to contact us at sales@0patch.com.


Wednesday, December 21, 2022

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

 

 

This month brought the last security updates for Windows 10 version 21H1. What if your organization is still using it and doesn't want to - or can't - upgrade it yet?

Don't worry, we have previously security-adopted Windows 10 v1803 and v1809, and subsequently Windows 10 v2004 and v1909. Now it wouldn't be fair if we didn't also security-adopt version 21H1.

So we have.

If you're running Windows 10 v21H1 in your organization, all you need to do is install 0patch Agent on these computers and register it to an account with PRO or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them.

These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 10 v21H1 with 0patch will also receive our micropatches for "0day" vulnerabilities in various products.

In order to have our micropatches applied, Windows 10 v21H1 will have to have December 2022 Windows Updates (the last official updates for this version) installed.

We welcome all interested organizations to contact sales@0patch.com for information about pricing, deployment, or setting up a trial.

P.S.: We're getting close to Windows Server 2012 end of official support by Microsoft in October 2023. You guessed it, we're going to security-adopt this server as well, in case you're already getting nervous about that. This is a good time for you to start a free 0patch trial, so send an email to sales@0patch.com.

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

Monday, December 19, 2022

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


With November 2022 Windows Updates, Microsoft fixed a vulnerability in Internet Explorer's JScript9 engine that was found being exploited by North Korean government-backed actors known as APT37. The vulnerability is of a "type confusion" sort, which means that malicious JavaScript code can confuse the JavaScript engine into thinking that a certain object is of one type (in our case, Int32Array) while it's actually of another type (in our case, Object) - and that quickly leads to reading or writing memory addresses that were not supposed to be available to said code. From that point on, arbitrary code execution can be achieved.

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

Microsoft assigned this issue CVE-2022-41128 and fixed it by removing a code branch that was dependent on a call to function ShouldExpectConventionalArrayIndexValue; in the patched code, this function call is skipped so the code always continues down the same path. 

Admittedly, we did not investigate what really went wrong with this vulnerable code and just logically replicated Microsoft's patch as we trust they know what they're doing. Our micropatch thus only has one instruction that jumps over the now-excluded code:



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

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2156e
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT jscript9.dll!0x21581
    
    code_start
        jmp PIT_0x21581   ; jump over the excluded code block
    code_end
patchlet_end


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

  1. Windows 10 v2004
  2. Windows 10 v1909
  3. Windows 10 v1809
  4. Windows 10 v1803 
  5. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
  6. Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
 
 
This micropatch has already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain the micropatch and have it applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.

We'd like to thank Benoît Sevens and Clément Lecigne of Google's Threat Analysis Group (TAG) for publishing their analysis and providing a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.



Thursday, December 1, 2022

Micropatches for Remote Code Execution in Windows Enterprise App Management Service (CVE-2022-35841)


 

September 2022 Windows Updates brought a fix for a remotely exploitable vulnerability in the Enterprise App Management Service, discovered by security researcher Ceri Coburn of Pen Test Partners. On October 13, they published a blog post describing the vulnerability in detail, and a proof-of-concept.

The Enterprise App Management Service allows Windows admins to centrally perform various installation and application provisioning-related actions on multiple Windows computers in the network. Due to lax permissions, a non-admin attacker could perform the same actions, potentially leading to a malicious application being installed and launched on the target computer.

Microsoft's patch added code for checking whether the requestor has administrative privileges on the computer, and our patches do logically the same.

Microsoft assigned this vulnerability CVE-2022-35841.

Our micropatches were written for the following Versions of Windows with all available Windows Updates installed:

  1. Windows 10 v2004
  2. Windows 10 v1909
  3. Windows 10 v1809
  4. Windows 10 v1803
 
Micropatches have already been distributed to all affected online computers running 0patch Agent with PRO or Enterprise license. To obtain the relevant micropatch and have it applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.

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



 

Friday, October 28, 2022

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


by Mitja Kolsek, the 0patch Team

Update 12/13/2022: Microsoft patched this issue with December 2022 Windows Updates and assigned it CVE-2022-44698. Our patches for this issue were freely available 46 days before the original vendor patch, and now require Pro or Enterprise license.

 

Nine days ago we issued micropatches for a vulnerability that allows attackers to bypass the warning Windows normally present to users when they try to open a document or executable obtained from an untrusted source (Internet, email, USB key, network drive). That vulnerability, affecting all supported and many legacy Windows versions, still has no official patch from Microsoft so our (free!) patches are the only actual patches in existence as of this writing.

On the very same day we issued these micropatches, Will Dormann - who researched said vulnerability - replied to a tweet by another security researcher, Patrick Schläpfer. Patrick works at HP Wolf Security where they analyzed the Magniber Ransomware and wrote a detailed analysis of its working. Will asked Patrick about the ZIP files used in the malware campaign to see if they were exploiting the same vulnerability or employing some other trick to bypass the "Mark of the Web".

Patrick responded that malicious files extracted from the attacker's ZIP files did have the Mark of the Web but still executed without a security warning. Remember that on Windows 10 and Windows 11, opening any potentially harmful file triggers a SmartScreen inspection of said file, whereby SmartScreen determines if the file is clear to get launched or the user should be warned about it (see image below).


SmartScreen determined that this file could be harmful and warned the user. The user needs to click "More Info" and then press "Run" if they really want to open the file.

When deciding whether to trust the file or not, the Mark of the Web plays an important role: files with this mark are considered unconditionally untrusted as they originated from an untrusted source. So why did these malicious Magniber files not trigger the SmartScreen warning?

Patrick remarked that Authenticode signatures on extracted malicious files must have been causing this behavior because with signatures removed, the warning would (correctly) appear. 

Will then noticed that these signatures were not valid at all and should not have been trusted by Windows. In fact, they were malformed such that Windows could not even properly parse them. This, for some peculiar reason, led to Windows trusting them - and letting malicious executables execute without a warning.

And so a new 0day - already exploited in the wild - was revealed.

This information was sufficient for us to start our patch development process. We reproduced the issue using a sample .JS file with various malformed signatures until we reached the flawed execution path that bypassed the SmartScreen warning. We then searched for the cause, and found... well... it's complicated.

The logic behind determining whether to show a security warning to the user, and whether to show the SmartScreen warning or the old "Open File - Security Warning" dialog, is complex and distributed among various executable modules. An application attempting to open a file on user's behalf partly inspects the file itself to decide whether to send it to further inspection by SmartScreen, and if so, sends a DCOM request to SmartScreen.exe, which is another process constantly running on Windows. SmartScreen.exe then does its own inspection and, if networking is available, asks Microsoft's servers for an opinion, displays the warning if needed, then delivers the final verdict back to the requesting process in form of an error code and the information on user's decision ("Run" or "Don't run").

What looked like the most serious flaw to us was the fact that when SmartScreen.exe returns an error, this would be considered identical to the user having pressed "Run." A strange decision, security-wise.

The malformed signature discovered by Patrick and Will caused SmartScreen.exe to throw an exception when the signature could not be parsed, resulting in SmartScreen returning an error. Which we now know means "Run."

Mystery solved. Now let's patch it.

To understand our patch, we need to take a closer look at function DoSafeOpenPromptForShellExec in shdocvw.dll as this is the function that performs the flawed logic. The image below shows the relevant part of its code: register edi is initialized to 0 and is reserved for holding the final decision on whether to run/open the file or not. The function sends a request to SmartScreen and waits for its response, then based on the error code returned takes the left or the right branch. The right branch, executed when there was no error, stores the user's decision to edi; the left branch, executed when SmartScreen returned an error, leaves edi on 0 - which explains why an error equals the user's decision to run/open the file.



The simplest way to fix this would be to simply initialize edi to a value that would mean "Don't run", whereby any error in SmartScreen would lead to the file not being run/opened. However, this approach might confuse users as such files would just silently not run/open without any feedback to the user.

We therefore decided on a different approach: in the same function, there is a code block that displays the old "Open File - Security Warning" dialog to the user, and in case of a SmartScreen error, we redirect execution to that block. This way, when SmartScreen errors out, the user is presented with the old security warning and can still select whether to run/open the file or not.


While our patch fixes the most obvious flaw, its utility depends on the application opening the file using function DoSafeOpenPromptForShellExec in shdocvw.dll and not some other mechanism. We're not aware of another such mechanism in Windows, but it could technically exist. Our tests with opening files directly from Windows Explorer, from ZIP files opened with Windows Explorer, and directly from most major web browsers and email clients were successful. Except with Google Chrome, which we've long ago decided not to patch because its sandboxing model is causing us problems with injection. And even if we did patch Chrome, there is another weird logic in shdocvw.dll that gets executed in Chrome due to sandboxing which for some reason prevents SmartScreen from returning an error while still not showing the warning. We did not investigate the latter any further.

We did, however, investigate a possibility of patching SmartScreen.exe, which could potentially cover all cases, but that would have to be a much more complex patch. In addition, the SmartScreen code can throw an exception in numerous places in addition to the one triggered by a malformed signature, and each of these could lead to the same warning bypass.

Needless to say, we're very interested in learning how Microsoft will fix this issue. Meanwhile though, our patch probably covers the majority of attack scenarios.

 

Our Micropatch In Action

You can see the effect of our micropatch in the following video. There are two executable files on the desktop: goodsig.exe and badsig.exe. Both are really just calc.exe and both have the Mark of the Web, but the former has a proper parsable signature while the latter has a malformed, unparsable signature that causes SmartScreen to error out.

Without our micropatch, double-clicking goodsig.exe correctly shows the SmartScreen warning because any executable with Mark of the Web should trigger the warning. Double-clicking badsig.exe, on the other hand, just launches the executable without any warning - demonstrating the vulnerability.

With 0patch enabled and our micropatch applied, double-clicking goodsig.exe behaves the same as before (which is still correct), but double-clicking badsig.exe now triggers the "Open File - Security Warning" dialog, warning the user and allowing them to back out via the "Cancel" button.



Micropatch Availability

Since this is a "0day" vulnerability with no official vendor fix available, we are providing our micropatches for free until such fix becomes available.

Micropatches were written for: 

  1. Windows 11 v21H2
  2. Windows 10 v21H2
  3. Windows 10 v21H1
  4. Windows 10 v20H2
  5. Windows 10 v2004
  6. Windows 10 v1909
  7. Windows 10 v1903
  8. Windows 10 v1809
  9. Windows 10 v1803
  10. Windows Server 2022
  11. Windows Server 2019 

Note that Windows 7 is not affected by this issue, neither are Windows Server 2008 and 2012.

These micropatches have already been distributed to all online 0patch Agents. If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Patrick Schläpfer for sharing the details on their Magniber ransomware analysis and Will Dormann for their analysis of this vulnerability that allowed us to reproduce it and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.








Wednesday, October 26, 2022

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

 

by Mitja Kolsek, the 0patch Team


On September 24, 2022 we were made aware of a POC for a Print Spooler elevation of privilege vulnerability discovered by security researcher luckyu with NSFOCUS TIANYUAN LAB. It turned out to be another symbolic link issue that Print Spooler has quite a history of.

The POC sets up a new printer with a custom spool directory as a non-admin user. This directory is a symbolic link to another directory, which contains a .SHD file that is itself again a symbolic link to some existing file which a non-admin user lacks permissions to delete. Then, by using file locking and performing some operations on the printer, the Print Spooler process (running as Local System) is made to delete said .SHD file, which in fact deletes the file it points to. A non-admin can therefore delete any local file that Local System is able to delete. This can, surprisingly, lead to arbitrary code execution using a trick earlier discovered by another researcher Abdelhamid Naceri and described in this ZDI article.

Microsoft assigned CVE-2022-30206 to this issue and fixed it with July 2022 updates. Not for everyone, of course: we determined that older Windows versions that had stopped receiving updates by then were also affected, and therefore needed our patch.

Having decided to patch this issue, we analyzed it, found the root cause and determined that the best approach would be similar to what we've done with other symbolic link issues in Print Spooler before: add a check in localspl.dll before the DeleteFile call to see if a path to the .SHD file is a symbolic link - and skip the deletion in case it was. This would not break the typical use case without symbolic links, and we doubt that any legitimate use case would involve a .SHD file being a symbolic link.

Having written such micropatch, we started testing it and discovered something peculiar: the linked-to file still got deleted even if our patch properly bypassed the DeleteFile call. What was going on?

It turned out that while we have patched the issue at hand, there was another very similar issue elsewhere in the code that also led to deleting the .SHD file. Interestingly though, this issue was not present on a Windows 10 v1909 updated to its last updates in May 2022. This version of Windows 10 was the last security-adopted Windows version at the time and received Windows updates a bit longer than others - which meant that it must have received a patch for this "newly discovered" issue while others haven't.

To identify this second issue, we tested the POC with our patch on Windows 10 v1909 with different Windows updates starting with May 2022 (the last updates for v1909) and going back in time. This revealed that the issue was fixed with February 2022 updates.

Looking at all vulnerabilities fixed with February 2022 updates, only one fit the description: CVE-2022-21997. It was a "Windows Print Spooler Elevation of Privilege Vulnerability", with the Microsoft advisory stating that "an attacker would only be able to delete targeted files on a system." The issue was reported by Bo Wu, whom we tried to contact for confirmation but unfortunately so far failed to reach.

In any case, it would make no sense to only patch the originally intended CVE-2022-30206, so we also went on to patch this "bonus" issue CVE-2022-21997. We did that with an identical patch, just in another location in localspl.dll. With both patches in place, the POC and the technique it was using no longer worked.


These micropatches were written for the following Versions of Windows with all available Windows Updates installed:

  1. Windows 10 v2004
  2. Windows 10 v1909 (CVE-2022-30206 only)
  3. Windows 10 v1903
  4. Windows 10 v1809
  5. Windows 10 v1803
  6. Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
  7. Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
 
 
Micropatches have already been distributed to all online 0patch Agents with a PRO or Enterprise license. To obtain these micropatches and have them applied on your computers along with our other micropatches, create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.

We'd like to thank luckyu for publishing their analysis with a proof-of-concept that allowed us to reproduce both vulnerabilities and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.