SANS Stormcast Wednesday Mar 19th 2025: Python DLL Side Loading; Tomcast RCE Correction; SAML Roulette; Windows Shortcut 0-Day

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9370.mp3

previous

next

Python DLL Side Loading; Tomcast RCE Correction; SAML Roulette; Windows Shortcut 0-Day

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Wednesday, March 19th, 2025
 edition of The Sands and it's Storm Center's Stormcast. My
 name is Johannes Ulrich and today I'm recording from
 Jacksonville, Florida. Xavier came across an interesting
 piece of malware that he's sharing in today's diary. The
 malware itself arrives as a zip archive, nothing really
 that special about it. It's called hootsuite.zip.
 Hootsuite, I'm not sure if they're still around. It was
 sort of a front end for Twitter. They had some issues
 when their API pricing changed. But either way, it's
 probably a well enough known company where some people may
 open that zip file. Also, the zip file itself, at least at
 first, doesn't appear to include anything malicious.
 There is a legitimate PDF reader. There is a PDF. Now,
 where it gets interesting is once you are starting the PDF
 reader, The reason the attacker is sending you that
 PDF reader is because this PDF reader is vulnerable to DLL
 side loading. If it loads a DLL file, a library, it will
 prefer the file in the local directory over the one in the
 system directory. And with that, it's easy to replace a
 system library with a malicious one. That's exactly
 what's happening here. This then invokes a bad file. That
 bad file will install a complete Python environment
 because, you know, who needs to save bandwidth these days?
 So, complete Python environment is being
 installed. And then a malicious Python script is
 being executed. Don't ask me why they don't just do
 PowerShell because PowerShell is maybe too messy for them.
 But so is Python. I would have installed Perl just for good
 old times sake. But anyway, the PDF reader is also much
 larger than the original. But there doesn't appear to be any
 additional malicious functionality here. Looks like
 they're just added additional sort of garbage at the end
 here to push it beyond 100 megabytes in size, which will
 then prevent some anti-malware solutions from scanning it.
 And one listener reached out over X to point out a little
 omission in the Wall Alarm blog post about the Tomcat
 vulnerability I talked about yesterday. I mentioned, and
 that's from the Wall Alarm blog post, that in order to be
 vulnerable, you need to use a file-based session manager.
 But in addition, as DKX here points out, you also need to
 configure the default servlet to be writable. Neither one of
 these two configurations is a default configuration. So
 someone would have to specifically configure Tomcat
 with these two options to be vulnerable. I have no idea how
 popular or common these particular configurations are.
 And Portsmaker did release a detailed blog post showing how
 to exploit the recent Ruby SAML vulnerability against
 GitLab. I think that's an important blog post. It does
 fill in some of the holes left in the original announcement.
 The problem with these SAML vulnerabilities is that
 they're fairly abstract and the risk isn't always easy to
 gauge of the export actually being used and being used
 against your particular site or your particular
 application. I think a blog post like this actually
 walking you through the exploit development and how it
 works in a specific case like GitLab here certainly brings
 home the message that these are real vulnerabilities that
 are actually exploitable. And Trend Micro's third initiative
 published a blog post with details regarding a Windows
 shortcut exploit that's already being abused in
 numerous advanced persistent threat campaigns. Actually,
 the blog post goes over some of the APT campaigns that have
 taken advantage of this particular vulnerability.
 However, Microsoft at this point has no plans to actually
 fix it. And the reason is that, well, the nature of this
 vulnerability is a little bit tricky. So the problem here
 are the good old shortcut files, the .LNK or link files
 that are typically supposed to be used to basically just
 provide a convenience link to a particular piece of
 software. However, as part of the .LNK file, an attacker can
 add arguments to the command they link to. And these
 arguments then, if you're creating your links right,
 will be able to execute arbitrary code. Now, a user
 may inspect the .LNK file. Just right-click on it and you
 can see the content on it. And you should see these command
 line arguments. So the user should have a chance, even
 though I consider it a small chance, of actually
 discovering the malicious exploit. That's sort of where
 the actual nature of the vulnerability comes in. By
 using, well, interesting combinations of white space
 characters, it's possible for an attacker to sufficiently
 obscure the actual command line arguments. And basically
 push them off the screen so a victim wouldn't actually see
 anything wrong when they're inspecting this file. In the
 end, it comes down to, in my opinion, that it's a user
 downloading and executing a piece of software that, well,
 they basically received from an unverified source. Not
 really all that different from just downloading and executing
 a .exe file. Not sure how much the file being a link file
 contributes the likelihood of the exploit actually working.
 And I think that's a little bit here what Microsoft is
 thinking about. I don't know. It's probably also a hard one
 to fix for Microsoft compared sort of to the impact it may
 have for the security of the overall systems. It shouldn't
 be too difficult for anti -malware and such to basically
 check whether or not link files are using any of these
 specific characters. And, yeah, the other problem still
 remains where a user may just download and click and execute
 a link file without first checking the parameters. And
 then, of course, that particular vulnerability
 wouldn't really matter. Well, and this is it for today. So,
 thanks for listening and hope you like it. If you like it,
 please leave a good review at your favorite podcast site if
 it allows for reviews or click the five-star, whatever it is,
 link. So, thanks and talk to you again tomorrow. Bye.