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

0:00Hello and welcome to the Thursday March 12, 2026 edition of the Sands, and then at Storm Centers, Stormcast, my name is Johannes, all re-requanodate from Jacksonville, Florida. And this episode is brought to you by the Sands.edu credit certificate program in instant response. Well, let's get started with a vulnerability and a script by DDA. So in DDA's diary today, DDA writes about Sombie Sip. Sombie Sip 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 Sip file, you typically have an indicator what kind of compression is being used and then the content. Now, two of the methods that can be used with Sip is when it's stored, which actually means

1:00it's not compressed at all. And then you have deflated, which is, yes, it's compressed. Well, what the attacker is doing here is just using the stored indicator and then still including deflated file, meaning that it's now an invalid Sip file and it cannot be opened as is. That's where it all comes down to. Of course, since it can't be opened, the anti-virus tools can't open it as well and can not sort of by default inspect the content of the file. However, by 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 check sums 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 on Sip program

2:00will 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 off-uscate the payload. So that makes it not really a very practical attack and I think we're more of a curiosity. But we all know, you know, the kits will start playing with it and you may see some of these payloads out in a while. Well, DDA now has an updated version of its, its Sip 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 well, regardless, not apply the deflate or whatever method is appropriate. So yeah, that's really it about some B Sip don't like make a big deal of it,

3:01except 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, happening fresh RSS, which is an RSS aggregator. Not really sure how popular it is, but the actual vulnerability, something that I've seen before and something that sadly often happens when people have softy best intention in creating some good cryptographic hashes. The root cause here is the B crypt function. So B crypt is a solid hashing function, but it has this interesting artifact where it only uses the first 72 bytes of the plaintext in order to create the hash. Now you would think for passwords that not really a big deal, passwords are really never 72 bytes long,

4:02and even if a user has like 100 by 200 by 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.

5:02Common recommendation is sort of no 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 as salt, if you must you speak crypt for whatever reason, then yeah, make sure that you prepend the password and you know, append the the salt. That I guess makes the salt then meaningless if the password is long on 72 bytes or just no use another hashing algorithm. Typically, you have plenty available. And then we have a vulnerability in the simple git package. Now,

6:05this is a very popular NPM package. And the vulnerability here is also a very typical vulnerability. The AI company code and 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. It's a lower case 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 overwrite files, you know, 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 and sensitive. It really depends on the use case that makes this more complicated problem.

7:10Well, 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.