SANS Stormcast Tuesday, November 25th, 2025: URL Mapping and Authentication; SHA1-Hulud; Hacklore

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

previous

URL Mapping and Authentication; SHA1-Hulud; Hacklore

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Tuesday, November 25th, 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
 Incident Response. Well, today's diary is not some
 breaking new item for a change, but something that I
 have been seeing more and more lately. And it's nothing
 really new, but I think worth pointing out and reminding
 people about. And that's how URL mapping and URL-based
 access control can sometimes lead to gaps in authentication
 and access control. We have seen this lately with the
 Oracle Identity Manager, where just adding a little
 extension, sort of cost bypassing of the access
 control. And then, so what prompted me to write this
 diary is earlier today, I saw an older vulnerability in the
 Hitachi, Wantara, Pantau business analytics server
 being exploited. Same pattern here, as long as you append
 require.js to the URL, you're good to go. You can basically
 execute whatever you want. And this, in this particular case,
 then opens up a command injection vulnerability that,
 well, otherwise would be protected by authentication.
 So that's really what's happening here. And the reason
 behind it is that for a range of different URLs, so as long
 as you have this LDAP three node children part in the URL,
 it's all going to the same script. And that's sort of
 where the URL mapping comes in. In web servers, you often
 map your URLs that several URLs or range of URLs or any
 request to particular directory is really processed
 by the same script. So appending things like here
 require.js does not change what's being executed, but it
 does change your authentication logic. And
 that's really the problem here. And that's something,
 looking at Java applications, I see that a lot because the
 way they're sort of being built. But in general, in
 particular, if you have sort of some middle boxes or so
 doing URL-based authentication, if you're not
 careful, it's then bypassable by taking advantage of some of
 these URL mappings or aliases or rewrites or whatever your
 particular web server calls them. And then you have a new
 NPM warm. This one very much modeled after the Shah Hulut
 warm. Now they call it Shah 1 Hulut warm. This particular
 warm is very similar. It attempts to gain access to
 GitHub and NPM credentials and then spreading itself via any
 credentials it can find to infect other repositories.
 It'll also make repositories public if it finds access to
 them. What's very different to the original version is that
 it's a destructive warm. If it can't find any GitHub or NPM
 credentials, it will actually go out and delete the user's
 home directory. So the prior warm didn't do that. It sort
 of had a more simple fallback mechanism. But this version
 now is destructive. So if you see any files in your home
 directory deleted, well, that may be the reason for it. At
 this point, there are a few hundred NPM repositories
 affected by this particular warm. And of course, there's
 still a little bit of a developing story at this
 point. I'll link to the Koi security version of this
 story. But there are others who have broken basically the
 same story as this warm came out. The real question is kind
 of what took him so long, given that the original warm
 was quite successful. And, well, of course, by the nature
 of the event, open source, it was not really that difficult
 for someone else to adapt this warm for their own purposes.
 So I don't think that these two are related in the sense
 that it's the same actor behind these two versions.
 Possible, but not very likely at this point. And then we
 have a new website, hacklore.org. This website was created
 by a group of former chief security officers, security
 leaders, and practitioners. How do you call them?
 Essentially people who are around the industry for quite
 a while. And, well, they try to clean up with some of the
 outdated security advice that is often being repeated and no
 longer really timely. The six things that they are noting
 here is, first of all, avoid public Wi-Fi. Then never scan
 QR codes. Never charge devices from public USB ports. Turn
 off Bluetooth and NFC. Regularly clear cookies. And
 regularly change passwords. These are definitely often
 being discussed. So maybe this open letter they published
 here at hacklore.org will help with some more informed
 security decisions, discussions on the
 Thanksgiving table. But I think it's a good initiative.
 And I'm mostly behind these points, particular in sort of
 the absolutes as they're being formulated here. Well, and
 that's it for today. Remember, there will be a podcast on
 Wednesday, but none on Thursday, Friday because of
 Thanksgiving. That's it for today. And talk to you again
 tomorrow. Bye.
 Bye. Thank you.