SANS Stormcast Wednesday, September 24th, 2025: DoS against the Analyst; GitHub Improvements; Solarwinds and Supermicro BMC vulnerabilities

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/9626.mp3

previous

DoS against the Analyst; GitHub Improvements; Solarwinds and Supermicro BMC vulnerabilities

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, 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.