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.
