SANS Stormcast Thursday, March 12th, 2026: Zombie Zip;

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

previous

Zombie Zip;

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 Thursday, March 12, 2026
 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, let's get started with a
 vulnerability and a script by Didier. So in Didier's diary today,
 Didier writes about Zombie ZIP. Zombie ZIP has sort of made
 the news a little bit yesterday, today. It's really
 a stupid vulnerability in some sense. And I'll explain a
 little bit why. So the root issue here is when you're
 having a compressed file like a ZIP file, you typically have
 as an indicator what kind of compression is being used and
 then the content. Now, two of the methods that can be used
 with ZIP is one is stored, which actually means it's not
 compressed at all. And then you have deflated, which is
 basically, yes, it's compressed. Well, what the
 attacker is doing here is just using the stored indicator and
 then still including a deflated file, meaning that
 it's now an invalid ZIP file and it cannot be opened as is.
 That's really all it comes down to. Of course, since it
 can't be opened, the antivirus tools can't open it as well
 and can not sort of by default then inspect the content of
 the file. However, while this sounds cool overall, it's
 definitely nothing sort of new to concept. We have seen this
 a lot with, you know, some of the compressed file formats
 and such being abused, like with bad checksums and the
 like. That is like decades old. But this is actually sort
 of a not very useful vulnerability in this
 particular case because no standard unzip program will be
 able to actually unzip the file. So the attacker would
 still make you use some kind of custom loader. If I can
 make you run a custom loader, well, I can probably just send
 you some encrypted malware or use something better than
 deflate in order to obfuscate the payload. So that makes it
 not really a very practical attack and I think really more
 sort of a curiosity. But we all know, you know, the kids
 will start playing with it and you may see some of these
 payloads out in the wild. Well, Didier now has an updated
 version of his ZIP utilities that will make it easier for
 you to then extract any relevant payloads. But
 basically just ignores the indicator what method was used
 to store the content and will regardless apply the deflate
 or whatever method is appropriate. So, yeah, that's
 really it about zombie ZIP. Don't like make a big deal of
 it. Like I said, it's really not a very useful or really
 applicable vulnerability in that sense. And I would really
 just ignore it for now. Well, the next vulnerability I'm
 going to talk about, I'm not going to talk about because of
 the particular product it happened in. It happened in
 Fresh RSS, which is an RSS aggregator. I'm not really
 sure how popular it is, but the actual vulnerability is
 something that I've seen before and something that
 sadly often happens when people have the best intention
 in creating some good cryptographic hashes. The root
 cause here is the bcrypt function. Now, bcrypt is a
 solid hashing function, but it has this interesting artifact
 where it only uses the first 72 bytes of the plain text in
 order to create the hash. Now, you would think for passwords,
 it's not really a big deal. Passwords are really never 72
 bytes long. And even if a user has like, you know, a 100
 byte, 200 byte password, if you're just using the first 72
 bytes, you're probably not significantly weakening the
 system. The problem is that in addition to the password, you
 usually also include a salt in the hash. And that's sort of
 where the problem happens if the salt is prepended to the
 password before it's being hashed, or in this particular
 case, prepended to the password hash. So they're
 doing like this double hashing kind of system here. Then if
 the salt is longer than 72 bytes, well, then basically
 the password no longer matters. And this is exactly
 what happened here. I've seen this in the past where people
 like use sort of things like email addresses and such as a
 salt, which can easily then exceed 72 bytes. In this
 particular case, they're using then some other hashing
 functions to create the salt. Common recommendation is sort
 of, you know, a random salt of eight bytes, which again,
 shouldn't really be an issue. But in this case, yes, you
 know, they ended up with salts again, trying to be secure.
 They ended up with salts being larger than 72 bytes. And then
 they prepended the salt to the password hash. And then the
 password stopped mattering. And basically any password,
 any password hash worked. Like I said, I've seen this before
 in various variations, usually like with the email address
 assault. If you must use speakcrypt for whatever
 reason, then, yeah, make sure that you prepend the password
 and append the salt. That, I guess, makes the salt then
 meaningless if the password is long and 72 bytes. Or just,
 you know, use another hashing algorithm. Typically, you have
 plenty available. And then we have a vulnerability in the
 simple git package. Now, this is a very popular NPM package.
 And the vulnerability here is also a very typical
 vulnerability. The AI company CodeAnt did identify this
 particular vulnerability. It's pretty straightforward. Well,
 it does attempt to filter out some, you know, possible
 malicious parameters from git commands. But it does apply
 the check case sensitive. So an attacker is able then to
 basically use an uppercase parameter instead of a
 lowercase parameter. Git doesn't care for these
 parameters. And as a result, you'll end up with arbitrary
 code execution in this case, once you basically use this to
 then override files. Again, regular expression
 vulnerabilities like this are quite common. Definitely make
 sure that you use case sensitivity correctly. And
 it's not always that you need case insensitive. It really
 depends on the use case that makes this a more complicated
 problem. Well, and that's it for today. Thanks for liking,
 thanks for subscribing, and thanks for leaving comments
 for the podcast. And talk to you again tomorrow. Bye.