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 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
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A note about what's going on here. 1) Word will render HTML (including MHT) content regardless of what comes before it. Plain text plays nicest. 2) When MHT content includes a <link rel=Edit-Time-Data> object that points to an undocumented ActiveMime blob, there's your Macro!
Note that the normal MotW-enabled Macro protections remain in place. (Macros on files from the internet aren't allowed these days)
The original MHT document has two obvious obfuscations. 1) The Edit-Time-Data link is URL encoded. 2) Its target is littered with extra spaces.
🤷♂️
While oletools oleid will detect presence of Macros in the MHT content, olevba seems to fall short of extracting it.
However, you can extract the undocumented ActiveMime blob with binwalk.
And from that extracted file, you can successfully extract the VBA code contained in it.
This complex CVE-2023-36884 exploit chain that some of us are looking at...
I can't tell if it's a decoy, or is nonsense written by ChatGPT, or triggers a new vulnerability but is otherwise broken, or has a an 0day exploit that is not reached, or is the real deal.
Thoughts? 🤔
I've not ruled out "Real", but for the life of me I can't get the exploit chain to work in its entirety.
Between what BlackBerry and Volexity describe, there are both parts missing, a bit of hand-waving, and some parts that simply seem broken.
BUT, let's look at the end parts...
1) By redirecting through individual HTML pages in a CHM, we can bypass the restriction on not running JavaScript. 🤔 2) By opening a .URL that targets a file inside of a ZIP via WebDav, we don't get any warnings (MotW doesn't matter). 🤔
Why doesn't the ITW exploit work for me?
Value-added ffmpeg.dll has code added to DllMain() that causes d3dcompiler_47.dll to be loaded, and decrypted payload is decoded from there.
Wide string "AVMonitorRefreshEvent" is *not* in legit ffmpeg.dll
Similarly, the malicious ffmpeg.dll will have the wide string "d3dcompiler_47.dll" in it, whereas the legit ffmpeg.dll does not.
Because, why should it? 😀
The d3dcompiler_47.dll has a "valid" signature from Microsoft, but has added value by way of using CVE-2013-3900.
Despite being 10 years old, Microsoft has left the fix for this optional, so by default we live in a world where this file is completely legit.
But we know better...
Speaking of avoiding Outlook...
Has anybody else noticed trouble recently with M365's Oauth2 authentication for SMTP, with Thunderbird at least?
IMAP seems fine, FWIW.
Login to server smtp.office365.com with username <emailaddress> failed.
This may be Thunderbird-specific, as Apple Mail seems to work fine.
Huh, so M365 mail appears to have Authenticated SMTP disabled.
Thunderbird error console to the rescue, it points to aka.ms/smtp_auth_disa… for a fix.
This seems like a recent change by MS that it throwing off Thunderbird, but not Apple Mail.
Folks poking at CVE-2023-23397 ...
I can't seem to send any kind of calendar invite that's generated by MsgKit.
Microsoft Outlook reports:
Cannot send this meeting request.
You don't need an actual Exchange server to send such an invite do you??
And just to clarify, even just taking the simplest sort of calendar invite MSG from MsgKit and attempting to save it as anything else (.ics, .vcs) w/ Outlook results in the same sort of error message. No SMTP / Exchange transport involved.
/me clicks "No" and waits for a solution
My understanding at this point:
- MsgKit appointments don't seem to be sendable with Outlook.
- When talking to an Exchange box, Outlook will allow "rich" invites that can trigger CVE-2023-23397
- If I request the invite email via IMAP, Exchange interprets it into VCF, so no fun!
The Microsoft update for CVE-2023-21716 was updated to suggest configuring Outlook to read mail in plain text as opposed to "Rich Text".
But despite calling it "Rich Text", Outlook doesn't use RTF for emails. It's TNEF.
Anyone know why this advice was added?
Spaghetti + Wall?
Ok, yeah, thx to @jduck TNEF does indeed include compressed RTF data in it.
Now about that "Use Microsoft Outlook to reduce the risk of users opening RTF Files" part... 🤔
Now, let's think about the consequences of choosing to "fix" a vulnerability in a way that the software still crashes, but presumably a bit more safely.
Our fully-patched (with Feb's updates) Outlook crashes on "previewing" an email received from the internet.
THIS_IS_FINE.PNG