Hello and welcome to the Wednesday, September 24,
2025 edition of the SANS Internet Storm Center's
Stormcast. My name is Johannes Ulrich, recording today from
Las Vegas, Nevada. And this episode is brought to you by
the SANS.edu Graduate Certificate Program in
Penetration Testing and Ethical Hacking. And today's
Internet Storm Center diary comes from one of our
undergraduate interns, Tyler House. These interns are
looking, well, at honeypot data. And in this particular
case, Tyler looked at what kind of looks like a denial of
service attack. It certainly had a reasonably high volume,
about 2.3 million packets from about 6,000 different hosts.
But, well, if it would have been a honeypot and it would
have been a reasonably sized web server, it probably
wouldn't be enough to actually cause a denial of service
attack. So, one of the things that Tyler was investigating
is, well, maybe the denial of service attack was more kind
of a smokescreen tool to hide any other attacks that may
have been going on at the same time. This is certainly not an
unknown technique and has been done in large and smaller
attacks alike to essentially distract the analyst and also
distract resources that are then typically more focused on
the more visible, the more obvious denial of service
attack. And, of course, it also has the more immediate
impact, at least initially, in order to then distract these
resources and have the actual attack slip underneath that
particular smokescreen. Well, in this case, it wasn't quite
that clear. There were some other scans for Git
configuration files and the like that happened around the
same time the denial of service attack happened. It's
possible that that was the attack they tried to cover up,
but then again, it wasn't really sort of an attack that
was really worthwhile covering up with any significant amount
of resources. We also have sometimes seen these type of
small denial of service attacks being either launched
just by accident, where essentially an IP address was
mistaken, or maybe a host name did still point to an
unrelated IP address. Unclear exactly what happens here, but
real nice analysis into the type of attack that happened
here, what identified the denial of service part of the
attack, and then, of course, also the underlying smaller
attacks that try to access specific URLs. And GitHub
published a blog post stating some of the lessons learned
and actions they'll take in order to prevent a repeat of
the recent NPM package hijack. Remember, the root cause here
was a successful phishing attack that compromised some
popular packages. And then in the next wave, they also used
these popular packages that they had hijacked in order to
infect additional packages. There are really three actions
that GitHub will take and also recommends maintainers will
take in order to prevent something like this from
happening. The first thing is the requirement for two-factor
authentication, where they particularly emphasize FIDO2
instead of just time-based one -time passwords, which is sort
of your default, usually a two -factor authentication scheme.
FIDO2 is inherently phishing safe, so that's why they're
pushing this form of multifactor authentication.
The next thing is that they're going to switch to more
granular tokens or are forcing developers of these packages
to use more granular tokens as part of your build pipeline,
which is often not interactive, so there's no
user that can actually take part in an authentication
process. You're using these API tokens, and historically,
GitHub has often used these API tokens that basically have
access to everything, while with more granular tokens, the
damage would be more limited if the token is leaked. But
even these tokens, of course, could get leaked and could
cause a compromise of the packages. So the third item
that GitHub is proposing here is what they're calling
trusted publishing. Trusted publishing moves away from
tokens based on API tokens, which are really just secrets,
to OAuth-based OpenID Connect system, where you are using
JWTs or JSON web tokens, which are digitally signed and time
-limited for authentication of these automated processes.
We'll see how it all works out. The steps make a lot of
sense inside of the recent attack, and I hope developers
will also find them not too difficult to implement. And
SolarWinds released yet another patch for its web
helpdesk product. This fixes, well, actually still the same
vulnerability in the AJAX proxy. It's a deserilization
vulnerability. This is the third patch for this
particular set of vulnerabilities. They have
individual CVE numbers, but it's really all the same
vulnerability, and then various patch bypasses that
still allow exploitation of the deserilization
vulnerability. I haven't looked at the patch yet. Not
sure if it's sort of publicly available. But a typical
problem with deserilization vulnerabilities is that one
way to patch them is to remove the gadgets, basically the
classes, the objects that are being used to exploit the
particular vulnerability. And that basically comes down to a
block list. If the block list is incomplete, then, of
course, the underlying vulnerability is still
exploitable. And we have seen similar issues with other
products, where we had sort of these incremental patches
where additional objects, additional gadgets were being
added to the block list. And Supermicro patched its BMC
firmware, patching two vulnerabilities that would
allow a malicious actor to essentially upload rogue
firmware. The vulnerability is a cryptographic signature
validation issue, where essentially the validation
logic that's supposed to allow only authenticated firmware to
be uploaded is being bypassed, which then essentially could
lead to a compromise of the BMC. Well, and this is it for
today. So thanks again for listening. Thanks for liking
and subscribing. And as always, thanks for
recommending this podcast. That's it for today. And talk
to you again tomorrow. Bye. Bye.
