Hello and welcome to the Thursday, November 13th, 2025
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 Engineering. Earlier this week, the OWASP
Foundation did release a release candidate for its 2025
edition of its Top 10 Web Application Vulnerability
List. This is of course always important given that there are
some compliance programs that refer to the OWASP Top 10, but
also a lot of application security programs use them
sort of as a guideline. There are, well, in some ways,
sadly, not a lot of changes. So really a lot of the old
vulnerabilities are still important, like, you know, the
good old things like injection and the cryptographic failure,
insecure design, broken access control. They changed the
order a little bit, but they're still part of the
OWASP Top 10. Now they did merge server-side request
forgery into broken access control, which makes perfect
sense because, well, server -side request forgery really
takes advantage of some of the insufficient access control
that sort of built around some of the trust relationships
between internal applications. There is also a new one, well,
sort of new one, that was added, and that's software
supply chain failures that used to be called vulnerable
and outdated components. However, it's really more than
just components, the supply chain, and that's really what
they're acknowledging here with that change in naming
that it's outright malicious components, for example, that
weren't really covered, at least in the title of the old
item. And also, things like developer tools and such are
often talked about that can lead to a compromise here. And
then there's one brand new item that was sort of added as
a 10th control here, or a vulnerability, and that's
mishandling of exceptional conditions. So overall, how do
you deal with failure? Also often a problem, like if
systems don't respond and such, if systems are left in
an inconsistent state, that can often then be exploited.
So take a look at it. Like I said, this is a release
candidate at this point, it's not the final list. So some
things may change a little bit until it is being finalized.
But I would assume that overall, it's pretty much
going to be the final list, what you're having here
published at this time. And Amazon published a security
blog with details regarding some attempted compromise
exploits they have seen that attempted to exploit Cisco and
Citrix vulnerability before patches were actually
available. These two vulnerabilities were patched
in July, so they're no longer zero days now, but they were
zero days at the time Amazon detected these exploit
attempts. Luckily for Amazon, it only hit one of their
honeypots. So that made it a little bit less of an incident
for them. But overall, I think the big lesson to take away
from this is number one, your secure devices, like your
firewalls, like your SL VPNs, are one of the primary ways
how attackers are entering networks these days. And it's
really competing with sort of no good old phishing and such,
actually according to some numbers, even exceeding the
number of compromises that are caused by someone actually
clicking on an attachment. Secondly, whenever you do see
a vulnerability like this and patch in particular in an edge
device, but you don't have a lot of additional redundancy
and diversity here to protect the device. Well, double check
that it hasn't already been compromised. That's probably
one of the biggest misses here that users just apply patches,
don't check for compromise, and then the attacker is just
coming back and re-taking over the device. They also sparked
a blog post that published some of the web shells that
the attacker deployed here and detecting web shells really
stable stakes at this point. You must be able to do that
because that's the payload that you will see deployed
using any exploit like this. And while I'm mentioning this,
there was also a new vulnerability that Citrix
patched in Netscaler this week. Doesn't look that
severe. There's a write-up about it from Watchtower that
explains a little bit what it's about, but exploitability
appears to be low for this particular vulnerability. And
then if you have a little bit of spare time, because we all
have spare time, or maybe management has asked for it.
If you're wondering how many of your publicly facing assets
are using quantum-safe cryptography, there's a neat
little website to test for this, qcready.com. It's a
little bit like the good old SL Labs website, which I found
lately hasn't really gotten a lot of updates, but this
particular site just focuses on quantum readiness for your
particular website. So a neat little test to run and see
where you're at. I wouldn't panic if you aren't quantum
ready yet, but another thing to check for then is, well,
what would it take to become a quantum, a post-quantum crypto
ready here, and actually be able to deploy those ciphers.
This may in some cases require a system update in others for
your particular application stack or so. Those crypto
libraries may not be available yet, but probably good to sort
of take a few minutes and take a look where you are at on
that respect. Well, and this is it for today. So thanks for
listening. Thanks for liking. Thanks for subscribing to this
podcast. And as always, talk to you again tomorrow. Bye.
