Hello and welcome to the Monday, March 24th, 2025
edition of the SANS Internet Storm Center's
Stormcast. My name is Johannes Ulrich and today I am
recording from Jacksonville, Florida. Well, we've got an
interesting vulnerability to start out with and actually I
wrote a little bit a diary inspired by that
vulnerability, but we'll cover diary and vulnerability sort
of here in one. The vulnerability is in Next.js.
Next.js is a framework built around React and well, like so
many of these frameworks, basically allows you to write
a ton of JavaScript and backend components, all of it
sort of nicely integrated. The problem here is how middleware
plays into this. So in a modern web application, it's
not just Next.js, it's I think particular when you're looking
at cloud-based application, very common where a request
hardly ever goes directly to just one web server, but it's
passing through various middleware components or
proxies. These proxies, they can have a number of different
functions. The simplest one is just caching, but then you
have more complex things like rewriting headers or
authentication. And authentication is the part
that of course is specifically of interest to us. The
interesting thing about having middleware take care of
authentication is that it really sort of removes some of
the dangers of implementing authentication from
developers. The way this is usually implemented is that
you design certain paths in the application as requiring
authentication or authorization. And that is
then being taken care of by a particular proxy. So the proxy
knows, hey, if you are going to an admin page, then you
have to be authenticated as an administrator. And it may
actually hand the request off to another piece of middleware
that makes sure that you are the administrator. And these
things often have caused problems. Same here for Next
.js. So one issue with having this zoo of different
middleware boxes is that it's easy to get confused. Hey, did
this request already go through a particular proxy?
Next.js's solution here is to add a header that basically
tells you, okay, you know, this particular request went
through these proxies and it can't be a list of them. And
that's exactly where the problem happens here, where an
attacker could just add a header that identifies that
this request already went through the authorization
proxy. So no need to check if this request is actually
coming from administrator. We already verify that and it is
allowed to go to this particular URL to implement
that particular function. So that's the problem here that
an attacker could spoof this header. And in doing so, and
this header is called x-middleware-sub request. So in
doing so, the attacker can then bypass authorization.
Interesting vulnerability. And like I said, not the first
time that this kind of vulnerability has happened in
these type of applications. That's sort of what inspired
me a little bit with the diary about headers. I think I have
to flesh this out a little bit. This was sort of written
on short notice. But overall, the problem is, well, of
course, attackers can send headers. And you have to make
sure that headers are verified, maybe digitally
signed, maybe initial proxies make sure that certain headers
are not set as a particular request enters your bucket
chain of middleware. And overall, you know, don't make
that middleware stuff too complex. I see this in
particular with cloud based application, where I call it a
little bit request inflation, where you have one request
coming in. And like I said, instead of going straight to a
web server and being responded, it goes through an
API gateway that then, you know, sends requests to other
APIs that themselves send requests to even more APIs. So
very quickly with like, you know, one little innocent
request, you end up with dozens of sort of backend
requests, which of course just increases your footprint,
increases your attack surface, but also complexity, which
hardly ever is good for security. Plus, of course, it
sometimes leads to these very difficult to debug latency
issues in applications like this. What should you do next?
Well, of course, patch next .js. Also, maybe review a
little bit these proxy pipelines. There is an easy
way to detect if you're running next.js. It adds one
of these X powered by headers to HTTP responses. So that
should be relatively easy to pick up. And according to an
article on Bleeping Computer, there has been more and more
abuse of Microsoft's trusted signing platform. This is
something that Microsoft started offering last year. It
costs you about $10 a month. And as a developer, if you
signed up with the Microsoft trusted signing platform, you
can basically have your software easily digitally
signed using a Microsoft -backed certificate. Now, to
balance a little bit the security part here, they
implemented a couple of protections. One is if you
want to get the certificate on behalf of a company, the
company has to be in business for three years. But you can
also just get a certificate for your personal name, and
then no real verification is happening. The other part is
that these certificates are only valid for three days. So
they're meant for basically short-lived development
binaries that maybe you want to hand to a couple testers,
and you don't want them to sort of be confused by
certificate warnings. But of course, for a malware author,
all of these barriers don't really mean much. Malware is
changing all the time anyway. Three days after three days,
probably it's getting recognized by some anti
-malware. And as such, a three -day valid certificate is
actually quite appropriate for malware, and that's apparently
how they're being used. Definitely something to be
aware of. If you are looking at suspect binaries, double
-check how long the certificate is valid for.
Don't just trust it because it uses a Microsoft verified
certificate. Well, and that's it for today. So thanks for
listening and talk to you again tomorrow. Bye.
