"KrbRelay" is
a tool for forced authentication issue in Windows that can be used by a
low-privileged domain user to take over a Windows computer, potentially
becoming a local or domain admin within minutes. The tool, based on James Forshaw's research, was developed by
security researcher cube0x0, and was later wrapped by Mor Davidovich into another tool called "KrbRelayUp" that further automated attack steps for escalating privileges.
KrbRelay provides various options to launch different versions of attack; some of these options were already known under the name RemotePotato0, for which we already had patches before. What was new for us with KrbRelay was its capability to launch a local service (running in session 0) via RPC and exploit it for leaking Local System credentials through forced authentication. In order to be exploitable, a service must allow authentication over the network, and just two such services were identified on affected Windows versions:
RemoteAppLifetimeManager.exe, identified by CLSID 0bae55fc-479f-45c2-972e-e951be72c0c1.
Microsoft does
not fix forced authentication issues unless an attack can be mounted
anonymously. Our customers unfortunately can't all disable relevant
services or implement mitigations without breaking production, so it is
on us to provide them with such patches.
For the purpose of identifying vulnerabilities we decided to name the vulnerability exposing the above services "KrbRelay", as other attack vectors provided by the tool were already blocked by our existing patches for RemotePotato0. We decided to inject our patch logic at the point where a local unprivileged attacker launches the exploitable service, because such patch would be fairly simple - and we like it simple: it's harder to make mistakes.
Our patch, source code shown below, resides in rpcss.dll and checks whether someone is trying to launch one of the above services via RPC; in such case, if the requestor's token is elevated, we allow it, otherwise not. This is the same approach as we used with patching RemotePotato0.
patchlet_start PATCHLET_ID 1 PATCHLET_TYPE 2 PATCHLET_OFFSET 0x6674 N_ORIGINALBYTES 5 JUMPOVERBYTES 0 PIT Advapi32.dll!GetTokenInformation,ntdll!_strnicmp,rpcss.dll!0x68ccd ; memory representation: 17 84 f1 90 f1 f0 4e 48 9d 3c 59 dc ee e5 db d8 ; clsid: 90f18417-f0f1-484e-9d3c-59dceee5dbd8
code_start call VAR dd 0x90f18417 ; CIeAxiInstallerService Class dw 0xf0f1, 0x484e db 0x9d, 0x3c, 0x59, 0xdc, 0xee, 0xe5, 0xdb, 0xd8 VAR: pop rcx ; rcx => clsid in memory respresentation mov rdx, [rbx] ; ClientToken hadle mov r8, 16 ; length to compare call PIT__strnicmp ; Compares the specified number of characters ; of two strings without regard to case cmp rax, 0 ; rax == 0 string are equal jne CONTINUE ; if rax != 0 continue normal code flow
mov rdx, [rbx+8] mov rdx, [rdx] mov rcx, [rdx+40h] ; current session token, TokenHandle mov rdx, 14h ; TokenInformationClass, TokenElevation sub rsp, 30h ; home space + vars lea r8, [rsp+30h] ; TokenInformation mov qword[rsp+30h], 0 ; memset mov r9, 4 ; TokenInformationLength lea rax, [rsp+28h] ; ReturnLength address mov [rsp+20h], rax ; pointer to address call PIT_GetTokenInformation ; The GetTokenInformation function retrieves a ; specified type of information about an access token add rsp, 30h ; restore stack pointer cmp byte[rsp], 0 ; token elevated? je PIT_0x68ccd ; if elevated(1) continue normal code flow
CONTINUE:
code_end patchlet_end
Micropatch Availability
While
this vulnerability has no official vendor 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:
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 (no ESU, ESU year 1, ESU year 2)
Windows Server 2008 R2 (no ESU, ESU year 1, ESU year 2)
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Windows Server 2022
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 James Forshaw and cube0x0 for sharing details about this vulnerability and sharing a tool, 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.
Over the years, 0patch has evolved from a simple proof-of-concept into a production-grade security service protecting computers around the World. We've been adding features and improving reliability, we have developed tools and processes to speed up vulnerability analysis and patch development, and we still have many ideas and plans to implement.
What was initially met with various skeptical remarks has now become a standard for protecting Windows computers in our customers' organizations who use 0patch both for keeping their legacy systems secure from old and new exploits, and for blocking 0day attacks while others are still waiting for original vendor fixes. We're happy to see our customers expanding their 0patch deployments and spreading the word to their peers.
To reflect the increased value and support further innovation and growth of our team, we're announcing our first price increase since our launch in 2019. This change, having been advertised on our pricing page for months, will go into effect on August 1, 2022, and will only apply to new subscriptions that get created on or after August 1, 2022; any existing subscriptions (including trials) will remain on the old pricing as long as they're renewed in time.
0patch PRO: Price of a PRO license will be increased for 2 EUR/year to 24,95 EUR/year (increase of 0,20 EUR/month).
0patch Enterprise: Price of an Enterprise license will be increased for 12 EUR/year to 34,95 EUR/year (increase of 1,20 EUR/month). We have until now offered Enterprise features for no extra charge but it's time to detach Enterprise pricing from PRO pricing to reflect the added value of Enterprise features.
Our mission has always been to help our users neutralize critical vulnerabilities in a low-effort, low-risk and affordable way before attackers start exploiting them. We remain committed to this mission and attentive to users' feedback when prioritizing new features that will make their work easier and their environments more secure.
Frequently Asked Questions
Is our current subscription going to be affected by this change? No, existing subscriptions will remain on the old rates as long as they're renewed. Only newly created subscriptions will fall under the new price list.
Can we still change the number of licenses in our subscription while staying on the old rates? Yes, you can do that - just make sure to keep the "Legacy" plan selected when modifying the subscription instead of selecting "PRO" or "Enterprise" plan, which use the new rates.
As your existing partner - reseller or MSP - do we keep the old rates for existing customers' subscriptions? Absolutely, as long as their subscriptions get renewed in time.
Can we just create a single-license subscription before August 1, and then increase license quantity later as needed to stay on the old prices? Yes you can, you clever rascal, but hurry up!
"DFSCoerce" is another forced authentication issue in Windows that can be used by a low-privileged domain user to take over a Windows server, potentially becoming a domain admin within minutes. The issue was discovered by security researcher Filip Dragovic, who also published a POC.
Filip's tweet indicated this issue can be used even if you have disabled or filtered services that other currently known forced authentication issues such as PrinterBug/SpoolSample, PetitPotam, ShadowCoerce and RemotePotato0 are exploiting: "Spooler
service disabled, RPC filters installed to prevent PetitPotam and File
Server VSS Agent Service not installed but you still want to relay DC
authentication to ADCS? Don't worry MS-DFSNM have your back ;)"
A quick reminder: Microsoft does not fix forced authentication issues unless an attack can be mounted anonymously. Our customers unfortunately can't all disable relevant services or implement mitigations without breaking production, so it is on us to provide them with such patches.
The Vulnerability
The vulnerability lies in the Distributed File System (DFS) service. Any authenticated user can make a remote procedure call to this service and execute functions NetrDfsAddStdRoot or NetrDfsremoveStdRoot, providing them with host name or IP address of attacker's computer. These functions both properly perform a permissions check using a call to AccessImpersonateCheckRpcClient, which returns error code 5 ("access denied") for users who aren't allowed to do any changes to DFS. If access is denied, they block the adding or removing of a stand-alone namespace - but they both still perform a credentials-leaking request to the
specified host name or IP address.
Such leaked credentials - belonging to server's computer account - can be relayed to some other service in the network such as LDAP or Certificate Service to perform privileged operations leading to further unauthorized access. Unsurprisingly, attackers and red teams like such things.
Our Micropatch
Since a proper access check was already in place, just not reacted to entirely properly, we decided to use its result and correct the logic in both vulnerable functions.
The image below shows our patch (green code blocks) injected in function NetrDfsremoveStdRoot. As you can see, a call to AccessImpersonateCheckRpcClient is made in the original code, which returns 5 ("access denied") when the caller has insufficient permissions. This information is then stored as one bit into register r8b, and copied to local variable arg_18 (sounds like an argument, but compilers use so-called "home space" for local variables when it suits them). Our patch code takes the return value of AccessImpersonateCheckRpcClient and compares it to 5; if equal, we sabotage attacker's attempts by placing a zero at the beginning of their ServerName string pointed to by rcx, effectively turning it into an empty string. This approach allows us to minimize the amount of code and complexity of the patch, which is always our goal. Function DfsDeleteStandaloneRoot, which causes the forced authentication to attacker's host, is then called from the original code (moved to a blue trampoline code block) but it gets an empty string for the host name - and returns an error. A blocked attack therefore behaves as if a request was made by an unprivileged user with an illegal ServerName. We decided not to log this as an attempted exploit to avoid possible false positives in case a regular user without malicious intent might somehow trigger this code via Windows user interface.
Source code of the micropatch shows two identical patchlets, one for function NetrDfsAddStdRoot and one for NetrDfsremoveStdRoot:
patchlet_start PATCHLET_ID 1 ; NetrDfsAddStdRoot PATCHLET_TYPE 2 PATCHLET_OFFSET 0x183e N_ORIGINALBYTES 5 JUMPOVERBYTES 0 code_start neg eax ; get original return value from AccessImpersonateCheckRpcClient cmp eax, 5 ; check if access denied(5) was returned jne CONTINUE_1 ; return value is not 5, continue with ; normal code execution mov word[rcx], 0 ; else set ServerHost to NULL. Result: DFSNM ; SessionError: code: 0x57 - ERROR_INVALID_PARAMETER ; continue with original code CONTINUE_1:
code_end patchlet_end
patchlet_start PATCHLET_ID 2 ; NetrDfsremoveStdRoot PATCHLET_TYPE 2 PATCHLET_OFFSET 0x1c96 N_ORIGINALBYTES 5 JUMPOVERBYTES 0 code_start neg eax ; get original return value from AccessImpersonateCheckRpcClient cmp eax, 5 ; check if access denied(5) was returned jne CONTINUE_2 ; return value is not 5, continue with ; normal code execution mov word[rcx], 0 ; else set ServerHost to NULL. Result: DFSNM ; SessionError: code: 0x57 - ERROR_INVALID_PARAMETER ; continue with original code CONTINUE_2:
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:
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Windows Server 2022
Note that only servers are affected as the DSS Service does not exist on workstations.
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.
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.
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:
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:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 (no ESU, ESU year 1, ESU year 2)
Windows Server 2008 R2 (no ESU, ESU year 1, ESU year 2)
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
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.
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.
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:
The diagcab archive contains package configuration XML file pointing to a folder on a remote WebDAV server.
This folder hosts a file named "\..\..\..\..\..\..\..\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
Vulnerable MSDT creates a local temporary folder such as "C:\Users\John\AppData\Local\Temp\SDIAG_0636db01-fabd-49ed-bd1d-b3fbbe5fd0ca".
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".
Which in fact means "C:\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\malicious.exe".
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.
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:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
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.
[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:
from msdt.exe via an ALPC call to
DCOM Server Process Launcher (hosted inside a svchost.exe), which launches
sdiagnhost.exe that receives the data from msdt.exe, and passes it on to a RunScript call to execute
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:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
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_secfor 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.
April 2022 Windows Updates included a fix for a critical remotely exploitable vulnerability in Windows Remote Procedure Call Runtime (CVE-2022-26809). The vulnerability was found and reported by company Cyber-Kunlun founded by security researcher mj0011, but no proof-of-concept was published at the time.
As is often the case, the research community "diffed" Microsoft's patch (see Ben Barnea and Ophir Harpaz of Akamai and MalwareTech) and quickly found that the vulnerability must have been an integer overflow: if a special kind of RPC packets were sent to the RPC server, and very many of them, a buffer size on the server side would grow and grow until it would have to exceed 4 GB (the highest number one can represent with 32 bits), at which point said buffer size would "overflow" and become very small again. Should the buffer then get allocated, it would be too small, incoming packets overwriting data and possibly code beyond it. By carefully selecting the size and content of packets, at least in theory, a remote attacker could cause arbitrary code to get executed in the process of the targeted RPC serve.
In practice, it would not be that easy. First of all, packets have a maximum size of about 5,000 bytes and sending enough of them over the network to cause the overflow takes hours. Moreover, several researchers have mentioned - and we can confirm - that attempting to send so much data to an RPC server often results in a timeout in communication, which means going back to square one. In addition, it became apparent that not all RPC servers would be vulnerable, as the affected code was only reachable on certain types of servers (see here). Finally, what exactly would be overwritten by malicious data, and how/if that could lead to execution of attacker's code, remains unexplored. Nevertheless, the history teaches us to assume that possible.
For a few weeks attackers and defenders alike were looking for more data and either searching for, or trying to create a POC. On May 1st, a GitHub repository from user yuanLink appeared with what looked like a POC for this issue, along with a detailed analysis of the vulnerability seemingly from the same user. We took the POC and after some modifications we were able to reach the vulnerable code and see the buffer size growing with each received packet.
While analyzing the vulnerability and comparing fixed and vulnerable code, our team noticed another integer overflow issue nearby that wasn't addressed by the April Windows Updates. Before we could report it to Microsoft it turned out Akamai researchers had already done that, and May updates brought a fix for this additional vulnerability, assigned CVE-2022-22019.
This allowed us to fix two birds with one stone, so to speak, and we created a single micropatch to address both CVE-2022-26809 and CVE-2022-22019.
mov r13d, [rsi+24Ch] cmp r13d, edi ; check if r13 > 0 jz PIT_0xb4661 ; jmp to exit block
cmp ebx, edi ; is flag RPC_BUFFER_EXTRA set? jz PIT_0xb4647 ; jmp to TransGetBuffer block
; overflow check mov edx, [rbp+18h] ; acc buffer length lea eax, [r13d+edx] ; sum of len(new_data) + len(acc_buffer) cmp eax, r13d ; check for overflow (if the result is smaller ; than r13) jb SET_ERROR ; if so, jump to error
mov edx, eax ; take the above sum add edx, 18h ; because of instruction: lea r8, [r13+18h] cmp edx, 18h ; check for overflow (if the result is smaller ; than 18h) jb SET_ERROR ; if so, jump to error
mov r13d, eax ; save len(new_data) + len(acc_buffer) to r13 jmp PIT_0xb4647 ; jmp to TransGetBuffer block, continuing original code
SET_ERROR: mov edi, 6C6h ; error code jmp PIT_0xb4661 ; jmp to exit block
code_end
patchlet_end
Our micropatch was written for the following Windows versions that don't receive official patches from Microsoft:
Windows 10 v1803 updated to May 2021
Windows 10 v1809 updated to May 2021
Windows 10 v1903 updated to December 2020
Windows 10 v2004 updated to December 2021
Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
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.
We'd like to thank yuanLink for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch, and Antonio Cocomazzi for providing valuable assistance in reproducing the issue. We also
encourage security researchers to privately share their analyses with us
for micropatching.
