Micropatching the "PrinterBug/SpoolSample" - Another Forced Authentication Issue in Windows

 

by Mitja Kolsek, the 0patch Team

Forced authentication issues (including NTLM relaying and Kerberos relaying) are a silent elephant in the room in Windows networks, where an attacker inside the network can force a chosen computer in the same network to perform authentication over the network such that the attacker can intercept its request. In the process, the attacker obtains some user's or computer account's credentials and can then use these to perform actions with the "borrowed" identity.

In case of PetitPotam, for instance, the attacker forces a Windows server to authenticate to a computer of their choice using the computer account - which can lead to arbitrary code execution on the server. With RemotePotato0, an attacker already logged in to a Windows computer (e.g., a Terminal Server) can force the computer to reveal credentials of any other user also logged in to the same computer.

For a great primer on relaying attacks in Windows, check out the article "I’m bringing relaying back: A comprehensive guide on relaying anno 2022" by Jean-François Maes of TrustedSec. Dirk-jan Mollema of Outsider Security also wrote several excellent pieces: "The worst of both worlds: Combining NTLM Relaying and Kerberos delegation", "Exploiting CVE-2019-1040 - Combining relay vulnerabilities for RCE and Domain Admin" and "NTLM relaying to AD CS - On certificates, printers and a little hippo."

Alas, Microsoft's position seems to be not to fix forced authentication issues unless an attack can be mounted anonymously; their fix for PetitPotam confirms that - they only addressed the anonymous attack vector. In other words:

If any domain user in a typical enterprise network should decide to become domain administrator, no official patch will be made available to prevent them from doing so.

Microsoft does suggest (here, here) various countermeasures to mitigate such attacks, including disabling NTLM, enabling EPA for Certificate Authority, or requesting LDAP signing and channel binding. These mitigations, however, are often a no-go for large organizations as they would break existing processes. It therefore isn't surprising that many of our large customers ask us for micropatches to address these issues in their networks.

Consequently, at 0patch we've decided to address all  known forced authentication issues in Windows exploitable by either anonymous or low-privileged attackers.

The Vulnerability

The vulnerability we micropatched this time has two names - PrinterBug and SpoolSample - but no CVE ID as it is considered a "won't fix" by the vendor. Its first public reference is this 2018 Derbycon presentation "The Unintended Risks of Trusting Active Directory" by
Will Schroeder, Lee Christensen, and Matt Nelson of SpecterOps, where authors describe how the MS-RPRN RPC interface can be used to force a remote computer to initiate authentication to attacker's computer.

Will Schroeder's subsequent paper "Not A Security Boundary: Breaking Forest Trusts" explains how this bug can be used for breaking the forest trust relationships; with March 2019 Windows Updates, Microsoft provided a related fix for CVE-2019-0683, addressing only the forest trust issue.

Today, four-plus years later, the PrinterBug/SpoolSample still works on all Windows systems for forcing a Windows computer running Print Spooler service to authenticate to attacker's computer, provided the attacker knows any domain user's credentials. As such, it is comparable to PetitPotam, which also still works for a low-privileged attacker (Microsoft only fixed the anonymous attack), and the recently disclosed DFSCoerce issue - which we're also preparing a micropatch for.

The vulnerability can be triggered by making a remote procedure call to a Windows computer (e.g., domain controller) running Print Spooler Service, specifically calling function RpcRemoteFindFirstPrinterChangeNotification(Ex) and providing the address of attacker's computer in the pszLocalMachine argument. Upon receiving such request, Print Spooler Service establishes an RPC channel back to attacker's computer - authenticating as the local computer account! This is enough for the attacker to relay received credentials to a certificate service in the network and obtain a privileged certificate.

When RpcRemoteFindFirstPrinterChangeNotification(Ex) is called, it impersonates the client via the YImpersonateClient function - which is good. The execution then continues towards the vulnerability by calling RemoteFindFirstPrinterChangeNotification. This function then calls SetupReplyNotification, which in turn calls OpenReplyRemote: this function reverts the impersonation (!) before calling RpcReplyOpenPrinter, where an RPC request to the attacker-specified host is made using the computer account.

We're not sure why developers decided to revert impersonation of the caller before making that RPC call, but suspect it was to ensure the call would have sufficient permissions to succeed regardless of the caller's identity. In any case, this allow the attacker to effectively exchange low-privileged credentials for high-privileged ones.

Our Micropatch

When patching an NTLM relaying issue, we have a number of options, for instance:

 

• using client impersonation, so the attacker only receives their own credentials instead of server's,
• adding an access check to see if the calling user has sufficient permissions for the call at all, or
  
• outright cutting off the vulnerable functionality, when it seems hard to fix or unlikely to be used.

 

This particular bug fell into the latter category, as we could not find a single product actually using the affected functionality, and Windows are also not using it in their printer-related products. If it turns out our assessment was incorrect, we can easily revoke this patch and replace it with one that performs impersonation.

Our micropatch is very simple: it simulates an "access denied" (error code 5) response from the RpcReplyOpenPrinter function without letting it make the "leaking" RPC call. This also blocks the same attack that might be launched via other functions that call RpcReplyOpenPrinter.

Source code of the micropatch has just two CPU instructions:

MODULE_PATH "..\Affected_Modules\spoolsv.exe_10.0.17763.2803_Srv2019_64-bit_u202205\spoolsv.exe"
PATCH_ID 908
PATCH_FORMAT_VER 2
VULN_ID 7419
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x576cc
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT spoolsv.exe!0x577df
    ; 0x577df -> return block

    code_start

        mov ebx, 5
        jmp PIT_0x577df

    code_end

patchlet_end

 

Micropatch Availability

While this vulnerability has no official patch and could be considered a "0day", Microsoft seems determined not to fix relaying issues such as this one; therefore, this micropatch is not provided in the FREE plan but requires a PRO or Enterprise license.

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

1. Windows 11 v21H2
   
2. Windows 10 v21H2
   
3. Windows 10 v21H1
   
4. Windows 10 v20H2
   
5. Windows 10 v2004
6. Windows 10 v1909
7. Windows 10 v1903
8. Windows 10 v1809
9. Windows 10 v1803
10. Windows 7 (no ESU, ESU year 1, ESU year 2)
    
11. Windows Server 2008 R2 (no ESU, ESU year 1, ESU year 2)
12. Windows Server 2012
13. Windows Server 2012 R2
14. Windows Server 2016
15. Windows Server 2019 
16. Windows Server 2022 

 

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

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email 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 Will Schroeder, Lee Christensen, and Matt Nelson of SpecterOps for sharing details about this vulnerability, and Dirk-jan Mollema of Outsider Security for excellent articles on relaying attacks and exploiting PrinterBug/SpoolSample in particular. We also encourage security researchers to privately share their analyses with us for micropatching.

Microsoft Diagnostic Tool "DogWalk" Package Path Traversal Gets Free Micropatches (CVE-2022-34713)

by Mitja Kolsek, the 0patch Team

 

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

 

With the "Follina" / CVE-2022-30190 0day still hot, i.e., still waiting for an official fix while apparently already getting exploited by nation-backed attackers, another related unfixed vulnerability in Microsoft's Diagnostic Tool (MSDT) bubbled to the surface.

In January 2020, security researcher Imre Rad published an article titled "The trouble with Microsoft’s Troubleshooters," describing a method for having a malicious executable file being saved to user's Startup folder, where it would subsequently get executed upon user's next login. What the user has to do for this to happen is open a "diagcab" file, an archive in the Cabinet (CAB) file format that contains a diagnostics configuration file.

According to Imre's article, this issue was reported to Microsoft but their position was that it was not a security issue worth fixing. This was their response:

"There are a number of file types that can execute code in such a way but aren’t technically “executables”. And a number of these are considered unsafe for users to download/receive in email, even .diagcab is blocked by default in Outlook on the web and other places. This is noted a number of places online by Microsoft.

The issue is that to make use of this attack an attacker needs to create what amounts to a virus, convince a user to download the virus, and then run it. Yes, it doesn’t end in .exe, but these days most viruses don’t. Some protections are already put into place, such as standard files extensions to be blocked, of which this is one. We are also always seeking to improve these protections. But as written this wouldn’t be considered a vulnerability. No security boundaries are being bypassed, the PoC doesn’t escalate permissions in any way, or do anything the user couldn’t do already."

The above does not sound unreasonable. The victim is supposed to open a file provided by the attacker, and then something bad happens. It's true (as it was back in 2020 when this was written) that most viruses aren't delivered to victims as .exe files or other typical executables, and that files with .diagcab extension would be marked as dangerous by Outlook. However, Outlook is not the only delivery vehicle: such file is cheerfully downloaded by all major browsers including Microsoft Edge by simply visiting(!) a web site, and it only takes a single click (or mis-click) in the browser's downloads list to have it opened. No warning is shown in the process, in contrast to downloading and opening any other known file capable of executing attacker's code. From attacker's perspective, therefore, this is a nicely exploitable vulnerability with all Windows versions affected back to Windows 7 and Server 2008.

In any case, the issue was found, reported, deemed unworthy, and largely forgotten. Until security researcher j00sean found it again and brought attention to it last week, as Microsoft Diagnostic Tool was under the spotlight because of Follina.

We decided this issue is exploitable enough to warrant a micropatch, and with the cat out of the bag (having presumably stayed in the bag since 2020) the likelihood of its exploitation is now higher.

Oh, and where did the DogWalk name come from? I asked Kevin Beaumont to name this vulnerability before publishing the blog post, and Kevin agreed with Kili's suggestion. The whole story is in the Twitter thread.

 

The Vulnerability

The vulnerability lies in the Microsoft Diagnostic Tool's sdiageng.dll library, which takes the attacker-supplied folder path from the package configuration XML file inside the diagcab archive, and copies all files from that folder to a local temporary folder. During this process, it enumerates files in attacker's folder, gets the file name for each of them, then glues together the local temporary path and that file name to generate the local path on the computer where the file is to be created. For instance, if attacker's folder were C:\temp\ and it contained a single file test.txt, the affected code would find that file, determine its name to be "test.txt", concatenate the previously created temporary folder name with this file name to get something like "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca\test.txt" and finally create such file with the content of the original C:\temp\test.txt file.

Now, the source folder can be on a remote share, not only a local folder such as C:\temp. Furthermore, it can reside on a WebDAV share on the Internet because by default, Windows workstations happily use WebDAV to access network shares, and WebDAV goes through most firewalls as it is just basically outbound HTTP. But none of these is the vulnerability yet.

The vulnerability is in the fact that the code assumes the filename to be a valid Windows filename. You know, not containing those characters you see Windows complaining about when you try to rename a file to something with ":" or "|".

 Or, more specifically, that a file name can't be something like "\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".

Wait, can a file name actually look like that? Not if you try to create it with Windows Explorer or "regular tools", but there is nothing to prevent a WebDAV server from saying, "Here's the file, its name is whatever I want it to be, deal with it." Should Windows accept suchmalformed file names? Probably not - but they do, and they pass them on to applications using their APIs. Which is the case with the vulnerability at hand; let's see what happens:

1. The diagcab archive contains package configuration XML file pointing to a folder on a remote WebDAV server.
2. This folder hosts a file named "\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
3. Vulnerable MSDT creates a local temporary folder such as "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca".
4. It then appends the remote file name to this folder name and gets: "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
5. Which in fact means "C:\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
6. It finally copies the content of the remote weirdly-named file to malicious.exe in computer's Startup folder, where it will be executed the next time anyone logs in. 
   

 

Okay, but who would download and open a silly diagcab file? Well, the download can happen automatically in a drive-by-download fashion, as demonstrated by Imre's POC (click this link and see the file downloaded to your browser). Then you see it listed in browser's Downloads list and if you click on it - intentionally or not - it's game over.

How about Mark of the Web? Aren't all downloaded files and files received via email marked with this flag that tells Windows to warn the user if they want to open it?

They are indeed, and the downloaded diagcab file is marked as well. But it is up to the application processing the file to check this mark and warn the user. Many applications do that; MSDT, unfortunately, does not.

 

Our Micropatch

Clearly, this is a path traversal vulnerability, and these vulnerabilities are all addressed in the same way: by searching for occurrences of "..\" in attacker-supplied file name or path and blocking the operation in case any are found. This is exactly what we did here. Our patch adds code that searches the source file name for "..\"; if found, it reports an "Exploit blocked" event and emulates an error on the file copy operation as shown on the video below.

Source code of the micropatch:

MODULE_PATH "..\Affected_Modules\sdiageng.dll_10.0.18362.1_Win10-1909_64-bit_u202205\sdiageng.dll"
PATCH_ID 893
PATCH_FORMAT_VER 2
VULN_ID 7418
PLATFORM win64

patchlet_start

    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x20e86
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msvcrt!wcsstr,sdiageng!0x20f30
    code_start

        call VAR                    ; push "..\" to stack and use it as a variable
        dw __utf16__('..\'),0

    VAR:
        pop rdx                     ; get VAR from stack - substring
        lea rcx, [rsp+5Ch]          ; mov data pointer to rcx - path
        sub rsp, 20h                ; shadow space
        call PIT_wcsstr             ; search substring("..\") in a string(path)
        add rsp, 20h
        cmp rax, 0                  ; check wcsstr return. 0 if the string does
                                    ; not contain the substring
                                    ; else returns a pointer to the first
                                    ; occurrence of substring in string
       
        je CONTINUE
        call PIT_ExploitBlocked     ; exploit blocked popup
        jmp PIT_0x20f30             ; jmp to existing error block

    CONTINUE:                       ; normal code flow
       
    code_end

patchlet_end

 

This is how our patch (green code blocks) is integrated in the original vulnerable code (white and blue code blocks) to add the missing security check:

Micropatch Availability

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

Micropatches were written for: 

1. Windows 11 v21H2
   
2. Windows 10 v21H2
   
3. Windows 10 v21H1
   
4. Windows 10 v20H2
   
5. Windows 10 v2004
6. Windows 10 v1909
7. Windows 10 v1903
8. Windows 10 v1809
9. Windows 10 v1803
10. Windows 7
    
11. Windows Server 2008 R2
12. Windows Server 2012
13. Windows Server 2012 R2
14. Windows Server 2016
15. Windows Server 2019 
16. Windows Server 2022 

 

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

We don't know whether this vulnerability has ever been exploited in the wild, or whether it will ever be. But as former attackers, we know it's the kind of issue one could realistically use, and our micropatches make sure that 0patch users don't have to care either way.

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

We'd like to thank Imre Rad for publishing vulnerability details and a POC, which allowed us to reproduce the vulnerability and create a micropatch, j00sean for digging this thing up and shedding light on it, and all other security researchers who have shared their findings with public or privately with us. We also encourage security researchers to privately share their analyses with us for micropatching.

Free Micropatches For "Follina" Microsoft Diagnostic Tool Remote Code Execution 0day (CVE-2022-30190)

 

by Mitja Kolsek, the 0patch Team

 

[Update 6/2/2022: Additional patches were issued for Windows Servers]

[Update 15/6/2022: Microsoft issued an official patch for this vulnerability. They implemented functionally the same security check in msdt.exe as we had in sdiagnhost.exe, namely checking for the presence of "$(" in the user-provided path. With official patches being available, our micropatches for this vulnerability are no longer free but require PRO or Enterprise license.] 

It was a quiet Sunday evening with a promise of enjoying a few chapters of The End of Everything by Katie Mack (an excellent book if long-term planning is your thing) when a tweet from Kevin Beaumont came by, opening with "This is a nice find." Knowing Kevin - at lest on Twitter - this often translates to "It's going to be a long night."

The tweet quoted by Kevin was actually from Friday, where nao_sec stated that an "Interesting maldoc was submitted from Belarus. It uses Word's external link to load the HTML and then uses the "ms-msdt" scheme to execute PowerShell code."

A remote code execution vulnerability was obviously spotted getting exploited in the wild. The vulnerability, quickly confirmed by many researchers using various versions of fully updated Microsoft Office, allowed a Word document to execute arbitrary PowerShell commands on the computer with little user interaction. It utilized the "ms-msdt:" URL scheme registered by default on all modern Windows versions to execute the Diagnostic Tool msdt.exe with malicious arguments.

It all looked very similar to CVE-2021-40444, where a malicious Word document would load a remote HTML template, which in turn opened a special type of URL to launch attacker's executable. But it was even "better" because no malicious executable needed to be dropped on victim's computer to be subsequently executed, as PowerShell commands have all the power the attacker ever needs.

For more details about the context, see Kevin's article which keeps getting updated as new data becomes available. Kevin is an unofficial authority for naming 0days and he dubbed this one "Follina"; Microsoft subsequently assigned it CVE-2022-30190 after having rejected a submission by researcher CrazymanArmy as "not a security-related issue."

The Vulnerability

This issue is widely considered a vulnerability in Office, due to Office documents being an efficient vehicle for delivering a "ms-msdt:" URL and having it rendered without restrictions with user's identity. However, we believe the actual problem to be the PowerShell command injection accessible via the IT_BrowseForFile argument of msdt.exe application, as first noted by Alec Wiese. While allowing an Office document to launch an application via special URL scheme may be providing an unneeded attack surface (which may lead to additional similar 0days being discovered in the future), this would all have been a non-issue without the command execution.

So where does the PowerShell command execution come from? A minimized POC triggering the vulnerability contains this parameter for msdt.exe:

IT_BrowseForFile=/../../$(calc).exe

The IT_BrowseForFile value contains a PowerShell subexpression "$(calc)", which results in executing the "calc" command in PowerShell, and that launches the Calculator app. Now why does this get executed at all? To find the answer, we need to see where the data passed to msdt.exe travels. One could use Process Monitor and debugger to find out, but we decided to use Tetrane REVEN, a powerful tool for reverse engineering which often saves us a lot of time with vulnerability analyses.

 

Tetrane REVEN during our analysis of this vulnerability, making it easy to trace data, inspect memory and find a good location for patching

Using REVEN, we could see the value in question traveling:

1. from msdt.exe via an ALPC call to
   
2. DCOM Server Process Launcher (hosted inside a svchost.exe), which launches
3. sdiagnhost.exe that receives the data from msdt.exe, and passes it on to a RunScript call to execute
4. PowerShell script TS_ProgramCompatibilityWizard.ps1 (in folder C:\Windows\diagnostics\system\PCW), which - inadvertently - gets the attacker's PowerShell subexpression executed by putting it in an Invoke-Expression call.

 

Note that TS_ProgramCompatibilityWizard.ps1 seems to be very much aware of the possibility of a "PowerShell subexpression injection" and dutifully sanitizes user-provided data in many places by replacing all occurrences of "$" with "`$", for example:

$appName = $choice["Name"].Replace("$", "`$")

Unfortunately, the one in IT_BrowseForFile argument slips by and still gets executed.

 

Our Micropatch

It would be by far the simplest for us to just disable msdt.exe by patching it with a TerminateProcess() call. However, that would render Windows diagnostic wizardry inoperable, even for non-Office applications. Another option was to codify Microsoft's recommendation into a patch, effectively disabling the ms-msdt: URL protocol handler.

But when possible, we want to minimize our impact outside of removing the vulnerability, so we decided to place our patch in sdiagnhost.exe before the RunScript call and check if the user-provided path contains a "$(" sequence - which is necessary for injecting a PowerShell subexpression. If one is detected, we make sure the RunScript call is bypassed while the Diagnostic Tool keeps running.

In IDA, our patch looks like this (green blocks are our code, blue block is original code relocated to a trampoline, value of rdx is used to emulate an error):

And a video of our patch in action. Since this vulnerability can be triggered via different vectors (not just Office documents), the video demonstrates how 0patch blocks an attack via msdt.exe, regardless of how msdt.exe got launched.

Note that sdiagnhost.exe, which is where our patch resides, has been last modified in Dec 2019 or even earlier on all patched Windows versions (except Windows 11, where it's naturally younger). This means our patch will be applied even if you have skipped many Windows Update cycles.

Also Note that it doesn't matter which version of Office you have installed, or if you have Office installed at all: the vulnerability could also be exploited through other attack vectors. That is why we also patched Windows 7, where the ms-msdt: URL handler is not registered at all.

Micropatch Availability

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

Micropatches were written for: 

1. Windows 11 v21H2
   
2. Windows 10 v21H2
   
3. Windows 10 v21H1
   
4. Windows 10 v20H2
   
5. Windows 10 v2004
6. Windows 10 v1909
7. Windows 10 v1903
8. Windows 10 v1809
9. Windows 10 v1803
10. Windows 7
    
11. Windows Server 2008 R2
12. Windows Server 2012
13. Windows Server 2012 R2
14. Windows Server 2016
15. Windows Server 2019 

 

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

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

We'd like to thank nao_sec for publishing exploitation details, which allowed us to reproduce the vulnerability and create a micropatch, and all other security researchers who have shared their findings with public or privately with us. We also encourage security researchers to privately share their analyses with us for micropatching.