Podcast Detail

SANS Stormcast Tuesday, June 23rd, 2026: Webshells; GitHub Actions Update; Fortibleed Update; Private Access Control Tokens

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

previous
Podcast Logo
Webshells; GitHub Actions Update; Fortibleed Update; Private Access Control Tokens
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Tuesday, June 23rd, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu graduate certificate program in
 cybersecurity leadership. Web shells. Well, that's a topic
 that keeps coming up and Xavier found a new one on
 GitHub. These web shells are popping up ever so often. This
 one claims to be hard to detect or undetectable. What
 this usually means, it's just too new for signatures to
 actually have been added to standard endpoint protection
 software that's often used to detect web shells. A better
 way often to detect web shells is just to look for
 unauthorized changes than just looking for signatures. Now,
 the way they are typically being deployed is that you
 have some kind of unauthorized file upload vulnerability,
 maybe a remote code execution vulnerability on a web server.
 And then very typical, the first thing that an attacker
 is doing is using that vulnerability to gain
 persistent access by uploading a web shell. So usually a
 little script in whatever language you're using on your
 server. This one, I think, is written in PHP, but they exist
 for pretty much any sort of web application language out
 there. And as a result, well, yeah, better pay attention to
 these web shells. No matter, you know, if the attacker uses
 AI or not, detecting web shells is probably going to
 help you either way. And GitHub is making some
 improvements to the security of its workflows in order to
 prevent some of the more common supply chain attacks.
 The change they made this week is a change to the pull
 request target. So when someone submits a pull request
 with this particular pull request target, you have the
 option to initiate workflows. And these workflows do have
 access to secrets. It's associated with the
 repository. Since essentially anybody can initiate a pull
 request, well, they constraint now when these workflows will
 run. And in particular, if the pull request came from a fork,
 which, well, would basically indicate that someone forked
 your repository, which is possible for any public
 repository, and then use that to submit a pull request,
 which is not an uncommon issue. That's how you submit
 pull requests. But the problem has been that pull request
 target would automatically then initiate actions in these
 workflows. And as a result, well, that led to some of
 these compromises if you didn't secure that pull
 request target accordingly. Now, you can opt out of this
 new behavior. But as GitHub points out in its manuals and
 in the blog post, they posted about this, then you it's
 basically up to you to make sure that the GitHub action is
 secured. And they give you some hints as to how to
 accomplish this. And one of the ongoing issues if you're
 running a website is that this point, a majority of the
 traffic you're seeing is likely created by bots, either
 malicious ones that are scanning your site for
 vulnerabilities, or well, AI agents, which may or may not
 be considered malicious depending on their use case,
 and really just no search engines and others that are
 just spidering your website using automated scripts. While
 sometimes you may want to allow this, quite often, it's
 really more annoying, it can cause a bit of service issues,
 our website often is sort of the victim of that. And the
 there is always a challenge, how do we figure out if a user
 is actually a person and the common solution here is
 CAPTCHAs. However, users don't like CAPTCHAs. CAPTCHAs are
 intrusive, they add friction. So there's a new solution now
 and Cloudflare announced that they're going to support it.
 And when we with Cloudflare support, of course, this is
 becoming sort of a real thing to be looking into, it's
 private access tokens, don't mix them up with personal
 access token, private access tokens, essentially an
 assertion that Cloudflare will generate the first time you
 are solving a CAPTCHA, or if there's another indication
 that you're not a bot that you're a person. So Cloudflare
 will issue that private access token. And it's digitally
 signed, of course, and with that the browser can then
 prove going forward, that it is actually operated by a
 person. And Cloudflare will then sort of act as the broker
 here in order to basically tell other websites, hey, this
 is a person and we don't need to have them solve a CAPTCHA
 again. Sounds like an interesting idea. As far as I
 understand, the standard that's sort of built around
 this is not quite complete yet. So a little bit early to
 comment on all of it. But it is supposed to be privacy
 preserving in the sense that different websites can
 correlate a particular user. So they just know it is a
 human, but they don't necessarily know what human or
 who is actually accessing their site. As a web
 developer, you probably don't really have to do anything
 about this. If you're using CAPTCHA solutions, like for
 example, Cloudflare, that's then sort of automatically
 being taken care of. As part of their CAPTCHA solution. And
 then I quickly want to comment on FortiBleed. I haven't
 mentioned FortiBleed much yet. In particular, it was
 mentioned in the press quite a bit. And part of the reason I
 didn't mention it was because it didn't appear to be that
 much new. Enterprise firewalls. We all know our
 attackers preferred entry point into networks. And
 that's just another case of outdated, meaning unpatched
 firewalls being used to breach corporate networks. But there
 is one detail that made this particular attack so
 devastating. And this again, nothing new, but I think
 something that's often overlooked when it comes to
 compromises of these border gateway devices. And that's
 that hackers used the vantage point of having access to all
 traffic traversing the device to actually then capture
 additional credentials. So this is something that you
 definitely have to consider if you find any kind of gateway
 or firewall or such that was compromised. In particular, if
 some of these devices have the ability to intercept TLS. In
 that case, you must specifically assume that any
 credential being sent through the particular device has been
 compromised and as a result must be changed. This is of
 course a very tough challenge. And I don't say it's easy to
 actually enumerate what you need to change and how you
 need to change it. But yes, that's just makes security
 more fun and complex. Well, and this is it for today. So
 thanks for listening. Thanks for liking. Thanks for
 recommending this podcast. And remember, there will be no
 podcast this week on Thursday, Friday. So thanks and talk to
 you again tomorrow. Bye.