Is there a way to automatically send this to SSH spammers/directory scanning bots?
Facebook accesses links shared in private messages... not sure if they'll unzip it
A better zip bomb
31–40 of 138 posts
Re: A better zip bomb
#32Earlier quoted context omitted.
How can you for instance verify the checksum of the file when it's deleted?
Wouldn't the decompression fail in that case?
The idea is to publish the checksum of the archive separately. After downloading the archive you can calculate its checksum and compare with the published checksum. If they differ you known something is up (possibly bad).
When a browser helpfully decompresses the archive you can no longer perform this check.
Re: A better zip bomb
#33Re: A better zip bomb
#34Is there any way to detect these things before unzipping them?
Whenever you download any untrusted file and attempt to parse or unpack it (and this includes zips, tarballs, PDFs, even images) your program should fork off some kind of sandbox which limits CPU time, memory, disk space, and access to local resources such as the filesystem and system calls.
There are various sandboxing technologies from using simple rlimit, or a cgroup, or even running a full VM (see libvirt-sandbox) depending on the threat level and the amount of effort you want to put in vs the perceived risk.
Re: A better zip bomb
#35Earlier quoted context omitted.
Not sure if your post is sarcastic but if not it already exists: https://blog.haschek.at/tools/bomb.php Usually aimed against bots though: https://hackaday.com/2017/07/08/dropping-zip-bombs-on-vulner...
Interesting. My immediate thought was, "that's awesome", followed by a plan to implement it on my own website, which gets regularly scanned for vulnerabilities. But then two questions sprang to mind: 1. Does this eventually get your domain marked as potentially harmful in Firefox/Chrome/other browser? 2. What happens if you're fronted by a CDN like Cloudflare? I mean, I assume nginx won't be screwed over by this but,…
1. You put it in a URL marked as "noindex-nofollow". Google will avoid it. You are supposed to only serve the page to identified spam bots anyway.
2. You create an exception so that they never cache the page and don't proxy this exact URL.
Re: A better zip bomb
#36Pretty powerful! Lots of breakage with things that touch this file. Simply downloading it in Chrome caused issues, Chrome began extracting it to a temp folder (presumably for some malware scanning?) and quickly started filling the disk. Windows 10 then began doing the same thing for Windows Defender, but some sane limits aborted it after a few seconds.
If windows defender breaks scanning when it encounters a zip bomb, could that be used to mask malware later in the file?
Re: A better zip bomb
#37Pretty powerful! Lots of breakage with things that touch this file. Simply downloading it in Chrome caused issues, Chrome began extracting it to a temp folder (presumably for some malware scanning?) and quickly started filling the disk. Windows 10 then began doing the same thing for Windows Defender, but some sane limits aborted it after a few seconds.
If windows defender breaks scanning when it encounters a zip bomb, could that be used to mask malware later in the file?
[deleted]
Re: A better zip bomb
#38Earlier quoted context omitted.
SSH has some kind of compression, so if you can write a Twisted ssh server sending the file as a compressed ssh packed. For detection, fail2ban provides a plugin architecture that allows it to do any action once it noticed an abuse, so you could switch the regular ssh implementation with you tricky one on the fly. Fun project. One should also do a lua nginx plugin for that: aggressive crawler ? Comment spammer ? Take…
This file exploits the zip container format, not the actual compression algorithm. SSH only uses the latter, not the former, so it is not applicable.
Would it be possible to do it just exploiting the algorithm?
Re: A better zip bomb
#39Earlier quoted context omitted.
Why would Chrome automatically begin unzipping the file? I'm afraid to even download it now...
Safari always unzips any downloaded archive, wraps it in a folder and puts it into ~/Downloads. I prefer this functionality as most of the time I do want to unarchive it. I can rearchive it later (or remember to use another browser) when I need to.
It's not always, there's an option to turn this off in the Safari Preferences
Re: A better zip bomb
#40Earlier quoted context omitted.
Interesting. My immediate thought was, "that's awesome", followed by a plan to implement it on my own website, which gets regularly scanned for vulnerabilities. But then two questions sprang to mind: 1. Does this eventually get your domain marked as potentially harmful in Firefox/Chrome/other browser? 2. What happens if you're fronted by a CDN like Cloudflare? I mean, I assume nginx won't be screwed over by this but,…
1. You put it in a URL marked as "noindex-nofollow". Google will avoid it. You are supposed to only serve the page to identified spam bots anyway. 2. You create an exception so that they never cache the page and don't proxy this exact URL.
> 1. You put it in a URL marked as "noindex-nofollow".
Better yet, mark it Disallow in robots.txt - to see "noindex, nofollow", they'd still need to request the URL, running the risk to be served with the bomb.
> 2. You create an exception so that they never cache the page and don't proxy this exact URL.
They work as reverse proxies on host-basis, I don't think you can exclude a single URL. CF at least will never cache text/html (unless specifically told to), but I don't know whether they will unpack (and possibly cross-compress to a better suited compression algorithm) the content while transmitting.