Can confirm! The #Spring4Shell exploit in the wild appears to work against the stock "Handling Form Submission" sample code from spring.io
If the sample code is vulnerable, then I suspect there are indeed real-world apps out there that are vulnerable to RCE...
Ways that Cyber Kendra made this worse for everyone: 1) Sensational blog post indicating that this is going to ruin the internet (red flag!). 2) Linking to a git commit about deserialization that has absolutely nothing to do with the issue demonstrated by the original party.
The original researcher also made this a touch more confusing/misleading than it needed to be as well. To one not familiar with Java, the long list of requirements makes it seem like one may need to intentionally make an app vulnerable. This is not the case.
What is TBD is:
What actual real-world applications are vulnerable to this issue?
Or is it likely to affect mostly just custom-built software that uses Spring and meets the list of requirements to be vulnerable.
Note that Spring has an advisory out on this: spring.io/blog/2022/03/3…
Specifically important is: Spring Framework 5.3.18 and 5.2.20 address this vulnerability.
I've published a note, now that we have the official CVE-2022-22965 designation for #SpringShell / #Spring4Shell
Nothing novel revealed there, but it should at least help for official tracking. kb.cert.org/vuls/id/970766
I'm not sure why it took so long for me to notice, but the screenshot right in that original report calls out exactly where shenanigans begin: getCachedIntrospectionResults()
The patch for CVE-2022-22965 fixes CachedIntrospectionResults, which is invoked by this function.
For local scanning of code vulnerable to CVE-2022-22965, this seems to do the trick: github.com/hillu/local-sp…
For remote scanning of a live web server even w/ just curl and looking for HTTP 400, that's possible, but trickier: 1) You need to know that the target is even tomcat. 2) You need to know the relevant endpoint to hit. 3) You need to test both POST and GET.
In case anybody is curious how the local scanner works, it's just comparing the hashes of the CachedIntrospectionResults.class file against known-vulnerable versions. This picked up all of the vulnerable components I happened to have handy for testing. github.com/hillu/local-sp…
• • •
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