SANS Stormcast Monday Mar 24th: Critical Next.js Vulnerability; Microsoft Trust Signing Platform Abuse

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

previous

next

Critical Next.js Vulnerability; Microsoft Trust Signing Platform Abuse

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

Podcast Transcript

 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.