Hello and welcome to the Monday, March 17th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and today I'm recording from
Jacksonville, Florida. First I want to start out today with a
quick congratulations to our SANS.edu graduates. We had our
commencement in D.C. on Saturday. And well, at this
class, the class of 2024, we did graduate almost 500
students. Quite a ways from the early days where we had
maybe two, three, five, I think at some of the first
years. In diaries this weekend, nothing really earth
shattering. Some kind of interesting scans for Traytech
Vigor routers. These routers have been attacked for quite a
few years now. Actually, 2024, there was a new set of
vulnerabilities that was being released. But pretty much ever
sort of since 2020, they have been attacked, have been
scanned for. What's a little bit different here for these
attacks is that they're quite a bit more aggressive than
some of the earlier ones. Looks like, you know, some
Mirai variant picked up on this. And well, as far as I
can tell, they're actually malformed and don't work.
Remember, attackers don't have SLAs. If they throw 100
exploits at you, one of them sticks. That's really all they
need. So I think they never really noticed that this
particular exploit they added here recently doesn't actually
do anything. At least that's my opinion here on it. In the
cgi-bin part of the URL, they omitted the dash. So it's just
cgibin. I don't think that'll work for vulnerable routers. I
may be wrong. Please tell me if there is some other exploit
or so they're trying to take advantage of here. But we also
have a real serious issue to talk about. And that's
malicious GitHub actions. tj-actions/changed-files.
That's the name of the action. Its intent, as far as I can
tell, is just to tell you what files have changed between
branches. Of course, quite useful in that respect. But
this particular action has been compromised. And it is
now logging secrets. This is an issue because these logs
are sometimes publicly accessible. In that case,
well, an attacker would be able to then retrieve these
secrets from the logs. So it's a pretty tricky kind of
compromise. They're not connecting anywhere outbound
or anything like this. So not that easy detectable. Also,
they did go back and retroactively changed a couple
of sort of tagged versions. So if your build process
automatically does pull a certain version from GitHub,
well, you're compromised. Your action will be compromised.
This is different from some of these simpler tags that
basically just update an action. And then, you know,
only if you're using the latest, greatest, newest,
you're affected. So if you are using this action, assume that
you're compromised. Double check your logs. Check there
are no secrets being logged. And definitely remove this
action from your workflow. Sounds like 23,000
repositories used this particular action. And the
next story also comes from GitHub, but from the GitHub
security team. So not a vulnerability in GitHub, but
instead a vulnerability discovered by the GitHub
security team. It's, again, the ruby-saml implementation.
SAML, of course, is built around XML and uses XML
parsers in order to verify SAML signatures. The problem
is that different XML parsers don't always parse the same
document the same way. And this has been an ongoing
problem with some of the earlier SAML issues, like how
comments, for example, are being interpreted in XML
messages. Here, again, this sort of issue of parser
differentials strikes. Ruby SAML uses, interestingly, two
different parsers. One is REXML and then Nokogiri. Both
parsers are being used as part of Ruby SAML. They're then
being used to extract information from the XML
document from our SAML signatures. And that's sort of
where the problems happen. These two parsers don't
exactly work alike. And that's how you have an authentication
bypass. I'll leave the details to the blog post. It gets a
little bit more complicated and a little bit too much for
the podcast here to explain. But if you are using Ruby
SAML, make sure you update. And, of course, it's one of
those components that you may find in various SAML
applications. So, definitely, you know, watch out for
updates. And since this is already sort of a little bit
of GitHub episode, let's cover a third and last GitHub event
for today. And that's the use of fake GitHub security
warnings in order to trick users to give the attacker
OAuth permissions. This kind of OAuth phishing, of course,
has been around and has been used against Office 365, for
example, a lot. Where an attacker is sending an email
that looks legit. You're clicking on it. You're now
being directed to the official GitHub page, in this case. And
being asked to give this application permissions. If
the attacker names your application in a, well,
confusing way, then, of course, users will give it
permission. They just call their security alert
application here. And there are probably others spinning
up as we see it. This is an issue, of course, if you are
using GitHub. If you're responsible for a particular
piece of code for a repository, then you may be at
the receiving end of these fake security warnings. Well,
and this is it for today. So thanks for listening and talk
to you again tomorrow. Bye.
