Thread by @wdormann

OK, now that I have access to a computer, let's take a look at this Office 0day that folks are talking about.
It's very similar to the MSHTML CVE-2021-40444 vul from September:
1) Use of '!' at the end of the retrieved URI
2) Size of retrieved HTML must be 4096 bytes or larger

The important difference is that this variant still works.
Let's look at the preview pane attack vector, like we did for CVE-2021-40444 since that one is more fun. Protected View be damned!
Here is Office 2019 on Win10, both with May 2022 updates.

While there very may well be other dangerous protocols besides ms-msdt:, it's probably a good idea to unregister this protocol. Especially while this vulnerability is still unpatched!
I've never seen its use in the real world until today.
gist.github.com/wdormann/03196…

Also, for the love of all that is holy, please don't have the Preview pane enabled in Windows Explorer.

I'd say that there are two behaviors being leveraged here:
1) The #LOLBAS for Msdt.exe happens to have a URI handler way of invoking it. @bohops
2) The ! in the referenced remote HTML file puts MSHTML in YOLO mode where (among other things?) it doesn't prompt for unsafe things.

Why is this combo a problem?
Well, the ms-msdt: URI handler has components implemented in PowerShell. You can make a URI where some parts of arguments are specified to be subexpressions, e.g. $(dosomething)
So obviously dangerous.
If you can get this URI to open w/o prompting, 🎉

I will say it's somewhat chuckle-worthy that the dialog that asks "Do you want to update this document with the data from the linked files" is hidden behind calc

This issue (MSDT, ms-msdt, Follina, or whatever you want to call it) has been assigned CVE-2022-30190 by the way.
msrc-blog.microsoft.com/2022/05/30/gui…

This language is a bit misleading in not really describing what "calling application" means.
If you preview a file in Explorer, which uses Office to render the document, Protected View doesn't do a damn thing.

And of course the unfortunately named "wget" in PowerShell will blindly redirect to unsafe URIs and get exploited. No Office required!
Of course it does.

When I say "unfortunately named"...
Let's say that you have GNU tools installed on your Windows machine, because you like to get stuff done and are stubborn about learning new things.
If you are typing into a PowerShell terminal, you may be surprised by what runs.
e.g. here's ls:

The MS publication doesn't mention it, but the mitigation mentioned by @gentilkiwi seems to work fine in blocking this URI class.

Or for the point-and-clicky among us:
Group Policy Editor -> Computer Configuration -> Administrative Templates -> System -> Troubleshooting and Diagnostics -> Scripted Diagnostics
Set "Troubleshooting: Allow users to access and run Troubleshooting Wizards" to "disabled"

It looks like Defender sigs are making their rounds.
But please don't rely on them. Disable scripted diagnostics or the ms-msdt: URI handler.
If an exploit is tweaked to look a bit different, it slips right past Defender.

But speaking of AV, let's have a look at what happens when an exploit is in multiple parts.
First there's the parent document.
Is it malicious? Absolutely not. It simply loads a remote OLE object, as is supported by Office.
What it does with that depends on what the content is.

Let's now look at the OLE object (HTML content) that triggers the unsafe ms-msdt: URI.
0 hits. Got it.

Finally, let's look at the XML content that is loaded by the diagnostic utility that is loaded by msdt.exe, which is loaded by MSHTML, which is loaded by Microsoft Word, which is loaded by explorer.exe, if you're one of those Preview Pane weirdos. Malformed arguments here.
0 hits