Hello and welcome to the Tuesday, March 18th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and today I'm recording from
Jacksonville, Florida. And a week or so ago, Didier wrote
about malware that he found that had the cobalt strike
beacon encoded as UUIDs. Now, Didier also maintains a script
1768.py that helps you decode cobalt strike beacons and
extract the serial number and such for the particular cobalt
strike instance, which, of course, is useful for
attributions and also to confirm that you're actually
dealing with a cobalt strike. Well, in this case, Didier now
added the ability to 1768.py to decode these UUIDs and then
essentially just with a simple Python script, you now get
everything you need from these UUIDs that are encoded in the
malware. Interesting, nice addition to a script in case
you wonder why the script is called 1768.py. Well, it turns
out to be the melting point of cobalt in Kelvin, the only
true temperature scale. Well, and yesterday I talked about a
vulnerability in the Ruby implementation for SAML.
Today, it's Node.js's turn. The problem here is the xml-crypto
library. If you're using this to parse SAML
messages, well, then you have a problem. The problem here
actually looks a little bit familiar. A couple of years
ago, Duo, I think, found a number of SAML implementations
being vulnerable to how they are parsing comments in SAML
messages. Comments are essentially supposed to be
ignored. Well, if I would have implemented it, I would have
just removed the comments and then parsed the message. But
that's not what they did. And so they ended up with a bunch
of sort of ambiguities around comments. This is yet another
one. The root issue here is that the digest value. That's
where you usually find the signature. Well, xml-crypto
uses the first child element from the digest value. And
that's typically your signature. But if the first
child element is a comment, it will just interpret the
content of the comment as the signature. And that's, again,
how you can confuse XML and SAML as to what's the actual
signature here for the particular message that you're
presenting. This can lead to privilege escalation or
outright authentication bypass. More details can be
found in the blog post by Work OS. And then there is a new
deserialization vulnerability in Apache Tomcat. The problem
with this vulnerability is that it's pretty trivial to
exploit. The only requirement is that Tomcat is using files
for session IDs. The exploit itself is actually something
that we have as an exercise in our SEC522 class. It uses yso
serial, which is a common tool to create deserialization
exploits. And then you just attach the Java object as a
cookie. You send a put request with Apache Tomcat. And then
later a get request using the same session ID, which will
then lead to deserialization and code execution.
Interesting sort of combination here of that put
and get a game. But overall, like I said, easy to exploit.
It's already exploit in the wild. Proof of concept has
been published. Like I said, this existing exploit tool
works to create an exploit for this vulnerability. So
definitely patch, patch, patch, and make sure that
whatever web application firewall or such you have does
detect this particular exploit. And Omid Mirsay with
the Cisco Talus research team did publish an interesting
blog post summarizing some techniques being used by
spammers these days in order to bypass filters. The core
message here is how cascading style sheets are being used to
essentially obfuscate the email by making it look very
differently than what the text actually means to convey when
the spam filter is parsing the email. This involves just, of
course, hiding various parts of the email or moving them
out of the field of view by using various positional
arguments in your cascading style sheets. But then Omid
also points out a number of tracking techniques being
used. Now, in the past, I remember a couple of years ago
or so, there were some blog posts discussing how, for
example, remotely loaded style sheets can be used to either
alter the email after it's being received or track users.
This is not what's going on here. All the techniques being
mentioned in this blog post are referring to inline
cascading style sheets. So no additional files are being
loaded here for the style sheet part. However, images
can be loaded by the style sheet. And a lot of privacy
software and such will block images being loaded via image
tags in the email. But apparently they're not
blocking images being loaded by cascading style sheets and
or other assets. And that, of course, can then be used to
track whether or not the email was viewed by looking at a
unique URL being assigned to this user. Interesting tricks
here. Not sure how to defend against them too well.
Attackers will always come up with ways to bypass spam
filters, bypass malware filters. But overall, probably
something good for user awareness here to tell users,
hey, you know, the email that you're seeing in your email
client may actually look, first of all, different in
different email clients, which can be a problem. And
definitely may have content that you don't see that was
just being added in order to confuse some of these filters.
Well, and this is it for today. Thanks for listening.
Thanks for recommending this podcast. Remember, we're
available via YouTube, via Amazon, lots of different
outlets where you can listen or watch this podcast. And
talk to you again tomorrow. Bye. Bye. Bye.
