Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hackers use ZIP file concatenation to evade detection

bleepingcomputer.com

Post reply on HN
Print view View original

41–50 of 111 posts

Re: Hackers use ZIP file concatenation to evade detection

#41

Post by stouset »

thrdbndndn wrote: post #33
kevin_thibedeau wrote: post #23

Earlier quoted context omitted.

The central directory allows zip archives to be split across multiple files on separate media without needing to read them all in for selective extraction. Not particularly useful today but invaluable in the sneakernet era with floppies.

Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.

If the point is being able to access some files even if the whole archive isn’t uploaded, why not create 100 separate archives each with a partial set of files?

Or use a protocol that supports resume of partial transmits.

Re: Hackers use ZIP file concatenation to evade detection

#42

Post by meehai »

rakoo wrote: post #40
thrdbndndn wrote: post #33

Earlier quoted context omitted.

Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.

That's a very bad way of solving that issue. If transmission is a problem, either use a proper retry-friendly protocol (such as bittorrent) or split the file. Using hacks on the data format just leads to additional pain

couldn't agree more!

We need to separate and design modules as unitary as possible:

- zip should ARCHIVE/COMPRESS, i.e. reduce the file size and create a single file from the file system point of view. The complexity should go in the compression algorithm.

- Sharding/sending multiple coherent pieces of the same file (zip or not) is a different module and should be handled by specialized and agnostic protocols that do this like the ones you mentioned.

People are always doing tools that handle 2 or more use cases instead of following the UNIX principle to create generic and good single respectability tools that can be combined together (thus allowing a 'whitelist' of combinations which is safe). Quite frankly it's annoying and very often leads to issues such as this that weren't even thought in the original design because of the exponential problem of combining tools together.

Re: Hackers use ZIP file concatenation to evade detection

#43

Post by exmadscientist »

PreInternet01 wrote: post #38

> To defend against concatenated ZIP files, Perception Point suggests that users and organizations use security solutions that support recursive unpacking Yeah, or, you know, just outright reject any ZIP file that doesn't start with a file entry, where a forward-scan of the file entries doesn't match the result of the central-directory-based walk. There is just so much malicious crud coming in via email that you just…

That's fair, but do realize that sometimes people do have to send around archives from the last century (they got archived for a reason!) or created by eldritch-horror tools that just make weird files (which, sometimes, are the gold masters for certain very important outputs...). And it's kind of annoying when these weird but standard files get silently dropped. Especially when that same file went through just fine yesterday, before the duly zealous security settings changed for whatever reason.

All I'm saying is, don't drop my stuff silently because your code couldn't be arsed to deal with (ugly) standard formats. At least give me a warning ("file of type not scannable" or whatever, the actual words are not so important). And then when I have to yell at the Shanghai people I can yell at them for the correct reasons.

Re: Hackers use ZIP file concatenation to evade detection

#44

Post by athrowaway3z »

tedk-42 wrote: post #22
_pdp_ wrote: post #15

This attack vector has been known for at least 17 years, if not longer. https://gnucitizen.org/blog/java-jar-attacks-and-features/ https://gnucitizen.org/blog/gifars-and-other-issues/

I'm with you. I've evaded all sorts of scanning tools by base64 encoding data (i.e. binary data) to and copy pasting the text from insecure to highly secured environments. At the end of the day, these malware databases rely on hashing and detecting for known bad hashes and there are lots of command line tools to help get over that sort of thing like zip/tar etc.

rot13 must be outlawed for its use by cyber-criminals!

Re: Hackers use ZIP file concatenation to evade detection

#45

Post by brabel »

unnouinceput wrote: post #19

Quote: "To defend against concatenated ZIP files, Perception Point suggests that users and organizations use security solutions that support recursive unpacking." That's the worse advice actually. You want the hidden shit to stay there unable to be seen by default programs. That's how you got all the crap in Windows mail starting from 90's when Outlook started to trying to be "smart" and automatically detect and run…

I agree. The ZIP definition is extremely clear that the contents of the ZIP are defined by the single Central Directory at the end of the file. Local headers are only valid if pointed to by the Central Directory. Any other local headers are just supposed to be treated as garbage, except by software that is specifically meant to recover corrupted ZIP archive's contents.

Re: Hackers use ZIP file concatenation to evade detection

#46

Post by seanhunter »

Jerrrrrrry wrote: post #25

Remember, secure encryption, good compression, and truely random data are indistinguishable. It's best to paste that encrypted payload into a JPG with some bullshit magic headers and upload that to a trusted Exfil pivot instead. Or, to get SuperMarioKart.rom to work with your chromeApp-XEMU emulator to play during down-time at work, just rename it to SMB.png, and email it you yourself.

  > Remember, secure encryption, good compression, and truely random data are indistinguishable.
Yes, and the only reason the bad guys get away with this is the people who trust signature-based scanning at the perimeter to detect all threats.

One of the hacks I'm most proud of in my whole career was when we were doing a proof of concept at an enterprise client we were being deliberately obstructed by the internal IT group due to politics between their boss and the boss who sponsored our POC. For unrelated trademark-related reasons we were prevented by a third party from having the software on physical media but we had a specific contractual clause agreeing to let us download it for install. So while we had been contractually engaged to provide this software and we had a strict deadline to prove value, the enterprise IT group were preventing us from actually getting it through the virus-scanning firewall to get it installed. What to do?

The scanner looked for the signature of executable or zipped files and blocked them. It would also block any files larger than a certain size. So what I did was write two shell scripts called "shred" and "unshred". "Shred" would take any files you gave it as input, make them into a tarball, encrypt that to confuse the virus scanner and then split it up into chunks small enough to get through the firewall, and "unshred" would reverse this. This almost worked, but I found that the first chunk was always failing to transmit through the firewall. The scanner noticed some signature that openssl was putting at the front of the file when encrypting it. The solution? Change shred to add 1k of random noise to the front of the file and unshred to remove it.

Job done. Our files were transmitted perfectly (I got the scripts to check the md5sum on both sides to be sure), and though the process was slow, we could continue.

The funny thing was the POC was a bake-off versus another (more established) vendor and they couldn't get their software installed until they had done a couple of weeks of trench warfare with enterprise IT. "To keep things fair" the people organising the POC decided to delay to let them have time to install, and eventually the person blocking us from installing was persuaded to change their mind (by being fired), so "shred" and "unshred" could be retired.

Re: Hackers use ZIP file concatenation to evade detection

#47

Post by TeMPOraL »

meehai wrote: post #42
rakoo wrote: post #40

Earlier quoted context omitted.

That's a very bad way of solving that issue. If transmission is a problem, either use a proper retry-friendly protocol (such as bittorrent) or split the file. Using hacks on the data format just leads to additional pain

couldn't agree more! We need to separate and design modules as unitary as possible: - zip should ARCHIVE/COMPRESS, i.e. reduce the file size and create a single file from the file system point of view. The complexity should go in the compression algorithm. - Sharding/sending multiple coherent pieces of the same file (zip or not) is a different module and should be handled by specialized and agnostic protocols that do…

Well, 1) is zip with compression into single file, 2) is zip without compression into multiple files. You can also combine the two. And in all cases, you need a container format.

The tasks are related enough that I don't really see the problem here.

Re: Hackers use ZIP file concatenation to evade detection

#48

Post by meehai »

TeMPOraL wrote: post #47
meehai wrote: post #42

Earlier quoted context omitted.

couldn't agree more! We need to separate and design modules as unitary as possible: - zip should ARCHIVE/COMPRESS, i.e. reduce the file size and create a single file from the file system point of view. The complexity should go in the compression algorithm. - Sharding/sending multiple coherent pieces of the same file (zip or not) is a different module and should be handled by specialized and agnostic protocols that do…

Well, 1) is zip with compression into single file, 2) is zip without compression into multiple files. You can also combine the two. And in all cases, you need a container format. The tasks are related enough that I don't really see the problem here.

I meant that they should be separate tools that can be piped together. For example: you have 1 directory of many files (1Gb in total)

`zip out.zip dir/`

This results in a single out.zip file that is, let's say 500Mb (1:2 compression)

If you want to shard it, you have a separate tool, let's call it `shard` that works on any type of byte streams:

`shard -I out.zip -O out_shards/ --shard_size 100Mb`

This results in `out_shards/1.shard, ..., out_shards/5.shard`, each of 100Mb each.

And then you have the opposite: `unshard` (back into 1 zip file) and `unzip`.

No need for 'sharding' to exist as a feature in the zip utility.

And... if you want only the shard from the get go without the original 1 file archive, you can do something like:

`zip dir/ | shard -O out_shards/`

Now, these can be copied to the floppy disks (as discussed above) or sent via the network etc. The main thing here is that the sharding tool works on bytes only (doesn't know if it's an mp4 file, a zip file, a txt file etc.) and does no compression and the zip tool does no sharding but optimizes compression.

Re: Hackers use ZIP file concatenation to evade detection

#49

Post by shreddit »

cyberax wrote: post #28
_pdp_ wrote: post #15

This attack vector has been known for at least 17 years, if not longer. https://gnucitizen.org/blog/java-jar-attacks-and-features/ https://gnucitizen.org/blog/gifars-and-other-issues/

17 years? We played tricks with zip bombs that used this approach during 90-s.

Yeah the 90s are just 17 ye… oh no I’m old

Re: Hackers use ZIP file concatenation to evade detection

#50

Post by PreInternet01 »

exmadscientist wrote: post #43
PreInternet01 wrote: post #38

> To defend against concatenated ZIP files, Perception Point suggests that users and organizations use security solutions that support recursive unpacking Yeah, or, you know, just outright reject any ZIP file that doesn't start with a file entry, where a forward-scan of the file entries doesn't match the result of the central-directory-based walk. There is just so much malicious crud coming in via email that you just…

That's fair, but do realize that sometimes people do have to send around archives from the last century (they got archived for a reason!) or created by eldritch-horror tools that just make weird files (which, sometimes, are the gold masters for certain very important outputs...). And it's kind of annoying when these weird but standard files get silently dropped. Especially when that same file went through just fine y…

Oh, nothing gets dropped silently, but bounced right back with `550 5.7.1 Message rejected due to content (Attachment refused: MATCH-code)`.

And for anything oversized, funny or otherwise non-standard, we offer a very convenient file transfer service.

Post reply on HN