Hello and welcome to the Friday, August 8, 2025 edition
of the SANS Internet Storm Center's Stormcast. My name is
Johannes Ullrich, recording today from Jacksonville,
Florida. This episode is brought to you by the SANS.edu
Graduate Certificate Program in Incident Response. In
diaries today we have yet again one of our SANS.edu
undergraduate interns that wrote up a little observation
from their own honeypot. Duncan Woosley observed all
for a sudden a big influx of scans from Panama. Looking at
it closer, it actually turned out that this was associated
with ASN 43350, ASN Autonomous Systems or Autonomous System
Numbers. That's basically the different networks connected
to the internet and ASN 43350, which is assigned to a company
called NForce Entertainment, has a little bit of habit of
often renting out its IP address space. So that of
course opens them up to more suspicious and sometimes
malicious uses. The traffic spiked over a couple days
between April and then later again in July. The next
question of course that always comes up here is block lists.
And last time I mentioned block lists in Diary, there
was a question that came up, why I don't like block lists.
So should you block this particular ASN? Well, maybe.
It really all depends on your own network. Blocking sort of
a big scanner like this can certainly reduce the noise in
your network, in your network sensors also. Does it protect
you from attacks? Well, that's the part where I think it's a
little bit questionable as far as successful attacks go. Many
of these scans are more or less just random scans that
are coming from many, many different other IP address as
well. So just blocking that one ASN does not prevent
actual exploitation. It may always block some legitimate
traffic as well. So that's where your own network comes
in. How you feel about potentially blocking non
-malicious traffic from your network by putting in this
relatively large blocks. Overall, just blocking the top
10 IP addresses for your own network is often pretty not
that helpful. Because, well, like you see with the data
that was collected here, you basically have a spike for a
day. Next day it's going away again. So you're usually just
chasing the peaks here. You're not actually blocking any
current scans that are happening after you put the
block in place. And of course this week, well, it's Hacker
Summer Camp in Vegas. I'm, of course, not participating this
year. But one of the papers that I really anticipated was
this one about HTTP/1.1 and the syncing attack. This was
published by Portswigger, the people behind the famous Burp
proxy. And, well, I think really the paper has some
interesting insights here. Why you probably don't want to use
HTTP/1.1 anymore. Or why at the very least your end
servers, your servers should support HTTP/2. And you
shouldn't just rely on middle boxes like Cloudflare and
other proxies to translate HTTP/2 to HTTP/1.1. So that's at
least the lesson that sort of I took away from this paper.
What they were really talking about was HTTP/request
smuggling. And what this refers to is that sometimes it
can be unclear where one request ends and the next
request starts. And it becomes in particular a problem
between middle boxes like proxies and your server.
Because requests from multiple users are munched together in
one connection. And then things like, for example,
small modifications to the content length header. Where
you add space here, for example, can confuse systems
as to like, you know, where, how long is this request
actually? And where does it end? Now, many of these
attacks have been talked about quite a bit in the past. And
Portsvigar is showing that some of the literature is
going back to like the early 2000s. But they outline here a
number of new attacks. One that I thought was
particularly sort of novel and least interesting to me was
the use of the expect-100 continue header. Now, 100
continue is a status code that you usually don't see. But in
this case, well, you can sort of trigger it. And then again,
these not very often used features often then cause
problems. Again, sort of confusing servers, middle
boxes as to the beginning and the end of requests. And in
this particular case, well, this can then lead to the
leakage of, for example, private information like
session IDs, account IDs and the like. At least here in the
example of Netlify that they showed. So the real problem
here is that modern architectures often set up
these sort of proxy bucket brigades, how I refer to them,
where you have things like load balancers. You have web
application firewalls and other devices that are sort of
forwarding requests from one to the other. The problem with
HTTP/1.1 is that it has this fairly fragile system of ASCII
strings and colons and such to delineate different fields. HTTP
2 is a lot more modern. It uses a more binary encoding
with like length and then a value. So that makes it much
easier to write robust parsers for HTTP/2 than for HTTP/1.1. And
in the translation from HTTP/2 to HTTP/1.1, some of those
details sometimes get mixed up and lost. And that's sort of
what this paper is really about. They also released new
tooling in order to detect these vulnerabilities. So if
you're working in these kind of infrastructures,
particularly with cloud-based systems and such, certainly
something to investigate. They specifically say that web
application firewalls may help with some of the impact here,
but are probably insufficient. And that's why they recommend,
well, enable HTTP/2. So you stay HTTP/2 end-to-end and avoid the
translation from HTTP/2 to HTTP/1.1. And Microsoft released
interesting bulletin today outlining a vulnerability in
Microsoft Exchange server if operated in a hybrid
deployment. The issue here is that it's possible for an
attacker who has admin access to the Microsoft Exchange
server to pivot to your cloud environment, basically get a
complete compromise of your domain. This vulnerability was
addressed with a hotfix in April. However, back then,
this vulnerability wasn't really sort of clearly spelled
out. And the way I read the advisory, Microsoft actually
didn't know about this vulnerability. The April
advisory just happened to fix this vulnerability. So they're
now making clear that you definitely do want to apply
the April update to fix this particular problem. But
remember, in order to exploit this vulnerability, an
attacker first needs to have admin access to your Exchange
server, which probably is a bad idea or a bad thing
anyway. And that's probably then the escalation is just
making things even worse. And then we got some updated
guidance from SonicWall regarding these, well,
presumptive possible Seredei attacks that are going around
that Arctic Wolf report about. SonicWall now states that they
do not believe that any new vulnerability is being
exploited here. This is mostly just the reuse of credentials
that may have leaked via other means. They do provide the
basic guidance, how to secure your SonicWall setup. They no
longer recommend that you should disable the SSL VPN.
Just to put it in context, we have written about this over
the last month or so, a couple of times, that we have really
seen a huge spike in brute force attempts against
SonicWall in our honeypots. So it's very possible that this
is just regular brute forcing, credential stuffing, and,
well, basically just careless configurations to some extent.
However, Arctic Wolf specifically stated that they
believe that the credentials that were used in the cases
that they investigated were secure, meaning that multi
-factor authentication was used and that the credentials
were rotated after prior compromises. So still a little
bit open here, but I tend to believe the SonicWall side of
things at this point. Be careful and definitely, you
know, review your credentials, review your logs, and check
the SonicWall guidance for any updates.
Well, and then it's Friday today, and with me today,
another sans.edu student to talk about their research
project. Could you introduce yourself, please? Yeah, my
name is Wellington Rapazzo. I recently graduated a master's
degree in information security engineering. I have been in
the computer science industry for around 20 years now,
working as a developer for many years, and more recently,
the last five years in the information security field.
And I, most of the, almost all those years, I have been
working as a Microsoft, not only in the field with the
customers, but also on the engineering side, creating our
product. Yeah, so exciting work there, an exciting
research paper. Actually, a topic that is very close to my
heart. Doing a lot of web development myself and such,
and considering myself still somewhat a developer. You
talked about shifting left and vulnerable open source
software. What was this about? Yeah, so the open source world
is amazing, right? It helps a single individual or groups or
companies to create amazing, amazing softwares, amazing
libraries that are consumed by God knows how many products,
right? JSON from Newtonsoft, use it everywhere. It's
amazing library as an example. So usually when developers
start using a reference component to their
application, they just download, they start using,
they create their product, and they don't pay attention on
the security, what that library is doing, and if that
library has a security vulnerability or not. But the
key part here is not only this, but the shift at
laughter, right? So it's very common for companies,
especially to start creating their software, make the
reference to the open source component to start using, and
never pay attention on that updated again. So they write
the whole software, they deploy as a service, or they
ship as a product, and vulnerabilities are figured
out later to that component. And they don't update for many
different reasons. And even if they try to update, it's kind
of too late, and it has a high cost for the teams and for the
components. So we all know about the software development
lifecycle. And there are many researchers that if you need
to do a fix and an update after the software is ready,
the cost is way higher than if you do in the beginning of the
development phase. Right? So it's common in many companies,
you have a product and you have a vulnerability, and you
ask the developer to update for a fixed version where that
vulnerability does not exist. And you're going to listen to
answers like, oh, I cannot do this now because I have a new
feature that I have to develop in my product, so this is not
a priority. Or no, I cannot do it now because we have
incompatibility. This is going to have a high cost for us to
adapt and be compatible with this new version. And in the
end, we do have services or products with security
vulnerabilities impacting many, many users. So it would
be amazing if a developer, when is building their
software or starting a development, be aware right
after. And not only the individual, but their team,
their leadership to help them with priorities and cost and
everything else that is part of the software development
lifecycle. Yeah, and your paper is going more into
technical details here, but let's stick a little bit with
the cultural part because I think that's a real big part
that you mentioned here. What I always find is, again, from
a developer's point of view with a little bit of security
background, that security from a developer's point of view
often gets in the way. I've seen companies that really
sort of utterly fail at the open source security game and
spend a lot of money on it. So they basically spend a lot of
effort at failing. And one problem they sometimes do is
that they're too restrictive where they say, okay,
developer, you're not allowed to use open source components
unless they're specifically approved, which sounds really
great. And if you want to have an open source component
approved, our security team will take care of that. Then
three, four months from now, they'll tell you if you can
use it. And I find that just doesn't work for me as a
developer. And the developers, I would say, they're
fundamentally nice people. They want to get work done.
And what they end up doing then is doing actually
something much more dangerous, where they copy paste code
from an open source library. So now you have the
vulnerability, but you don't know that you have the actual
library. Where do you try to balance here? Like, you know,
how much scrutiny should you apply to an open source
library before you allow your developers to use it? Because
there has to be some kind of control around this or
anything that works in your experience there? Yeah, I
mean, we do have actually great products available in
the market that people and companies in general could be
using. And by the way, I'm not doing any marketing about
those products. I've just mentioned because they are
actually very useful. Not only GitHub with the GitHub
Advanced Security and the PandaBot, also Azure DevOps
and even SNCC. And I'm pretty sure there are others that
when a developer download and reference and check an open
source component into their code, but still doing a
reference check if that component has a security
vulnerability and alert in the repository that, hey, you have
a security vulnerability, you should not be using this.
Also, it's known that many package managers offer you to
have your own private feed. So companies could be creating
those private feed and doing their own checks. I understand
it has a high cost. It's not easy. So small software
companies probably would not be able to have their own
private feeds and checking for security vulnerabilities, etc.
However, they can, using those products in the market, which
would be bad, probably wouldn't be perfect, but would
be very reasonable and would help in them a lot. But one
problem that I see with this is when it happens, the code,
it's probably written already, at least some part, and
checked in the code. So most teams is going to look on that
one and say, yeah, but we have this super tight deadline.
Let's deal with this later. So it would be great if not only
the individual, the developer that is downloading that code
at that time, because the package management giving them
the alerts, right, in most of those cases when it happened,
but also leadership. And for companies that they have
secure teams, they have their blue team, their monitoring
team, they are monitoring a lot of stuff, but they are not
monitoring components being downloaded, right? So if they
can't monitor and alert the leadership, hey, this dev team
just downloaded a component with a vulnerability, the
leadership would be aware and say, hey, hold on. We have a
very tight deadline, but we cannot ship this with a
security vulnerability, right? And to your point, which is
not part of my research, but would be a great topic, when
people just copy and paste code because they cannot make
a reference, as you mentioned, I'm pretty sure today we could
have an AI agent checking for this and say, hey, by the way,
I see this code. It's very similar to this one. Why are
you doing that? And give it this one another bit. So for
people who listen to us, if you are looking for an idea
for the research, maybe you just have one nice and good. I
heard about people looking in stuff like this, particularly
like outdated encryption algorithms and stuff like
this, which it's relatively easy if you have the outdated
OpenSL library, whatever encryption library you're
using, you just update the library. But now with the
updating, another problem that I have run into is that you do
have a vulnerable library, but then the developer tells you,
but I'm not actually using the vulnerable feature. So should
I spend the effort updating? What's your take on that? I
would say, yes, you should update regardless because you
may not be using right now. You may use later, but I'm not
a malware developer or anything like that. But I'm
pretty sure that even if your code flow does not execute
that line of code, someone maybe find a way to run that
code and create that. And also, again, I'm not doing any
marketing, but we do have other tools like CodeQL that
people could take advantage and use also from GitHub to
detect the code flow and maybe not update right away, but
putting their backlog. Hey, we need to update this as soon as
possible because we're not using that function, but that
function has a vulnerability and someone probably can
exploit that one. My personal takeaway on this is if there's
something vulnerable, do not use. And if you don't know
what you are downloading, don't want to ever check,
don't do it. Not in your production systems, not in
your library, not in your code. Maybe in a sandbox
environment if you want to do your own tasks and things like
that, but not in your daily basis machine, not in your
work machine for sure. Yeah. Like I always say, don't
underestimate the creativity of the attacker. They
sometimes find ways to exploit it that may not be obvious
initially. Any final words for developers?
Don't give up on OSS. Don't give up on your components.
And keep using it. Keep contributing. The software
world is really amazing nowadays because of so many
open source contributions. But be very careful, right? When I
was in the college, in the university, security was not
even mentioned during my computer science or degrees. I
believe today it should have classes not totally focused on
security, but they should have at least something. I believe
so. I hope so. If not, there are SAMs, there are so many
others that you can learn about it. But be very careful.
Be very careful. Think that only... Your software may be
very... You may think that, hey, this is not harmful. This
is not doing anything. Oh, really? Are you creating a
software that's going to run in a hospital? That's going to
run in a grocery store. And then maybe you're going to
impact people to receive what they need. You may stop a bank
and people cannot get money and be harmful about that. And
the hospital, I think, would be the worst case scenario,
right? Imagine you are in an ER room and you cannot receive
your treatment because the software that someone created
is not working because of security vulnerability. So I
always think about that. What I'm doing is impacting the
world. And I'm pretty sure what you are doing is also
having a big impact. So you're conscious about that. Thanks a
lot. And I always think that there is no commercial versus
open source software because any commercial software you
buy is probably 90% open source components just
repackaged. I can't agree more. I can't agree more. If
you spend some time in a GitHub, you're going to be
surprised at so many. And one thing that I was surprised at,
go to the last comment, by the way, go to the NPM or any
nugget package that provides you any nugget package, any
package management. Go to any package manager that provides
you some download statistics. You're going to be surprised
by the number of people downloading that open source
with linear abilities or without linear abilities only
in a very short period of like a week or so. And you're going
to be like, wow, there's a lot of people using this. Yeah.
Thank you for joining me here. Thanks, everybody, for
listening. And talk to you again on Monday. Bye. Bye.
Thank you.
