Hacker News Reader

Comment by curiousgal | Hacker News Reader

Is there a way to automatically send this to SSH spammers/directory scanning bots?

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 nice gzip HTTP response...

Does it work with gzip?

Not sure, but let's see if I can try without crashing my laptop.

EDIT: nope, steaming doesn't work, the zip relies on the fact it contains many files, and gzip assume there is only one big blog.

EDIT 2: tried with zlib but it expects a different header. So my guess is you really need to open it as an archive.

gzip and zlib (and tar) are "streaming" formats, the essay notes that "streaming" zip libraries are not affected as this bomb exploits the relationship between the central directory and the individual files.

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?

You can make some limited deflate bombs, but they are nowhere near as massive as this one.

You don't need a zip file; just send the other side a gzip response with an endless amount of '<div>' inside. I've had some fun with that and some bots truly just stop responding after about 8 minutes of downloading div tags with no end.

Put it wherever in a "secret.zip" file? If you have the logs, just add a dummy page that they usually scan (/wp-admin or whatever) that automatically makes the client download the file.

SSH however works with zero trust. Clients are protected from bad servers just as servers are protected from bad clients. It shouldn't be possible to send a file. If it is, it is a serious ssh vulnerability.

It's not about downloading, it's about unzipping.

Most bots won't unzip a file they download.

But they will deflate a SSL packet.

That would be something new! A website crashing your browser because http or tls compression is sending „zip bombs“.

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, even then, will it infuriate your CDN provider and put you at risk of getting your account shut down.

My fit of vengeful glee has therefore been somewhat ablated for the time being.

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.

I put, as a test and for fun, a "Disallow" entry in my robots.txt (with a campy name to be honest) and not a single crawler hit that dir in more than three years, don't know if others had the same experience.

I was suggesting Disallow to make sure Google doesn't request it ;) I don't know if any bots look at robots.txt to see potentially interesting URLs. I do when I take a better look at sites, but I usually don't qualify as a bot.

My experience is that most bots just hit the usual suspects, /wp-login.php, /phpmyadmin/ etc, regardless whether they are in robots.txt or not.

> My experience is that most bots just hit the usual suspects, /wp-login.php, /phpmyadmin/ etc, regardless whether they are in robots.txt or not.

Yeah, basically what I see in my logs. To be more clear, the disallow is for a non existent path in the document dir. I somewhat expected to find at least one script to actively crawl it, but it makes sense, as no sane people would put secrets on a website and protect them with a robot.txt... ^__^;

Thank you (both you and GP)!

SSL packets do not use the zip container format which this targets, though. They only use the deflate compression algorithm.

You may be interested in an SSH tarpit like Endlessh [1].

[1]: https://github.com/skeeto/endlessh

This specifically exploits peculiarities of the PKZIP archival format (in combination with DEFLATE). SSH compression doesn't use zip, so unless the scanning bots also start downloading and processing / decompressing files they find on your honeypot, this is not going to apply (you can still use normal compression bombs to try and crash them: https://hackaday.com/2017/07/08/dropping-zip-bombs-on-vulner...)

Just add a file named "passwords.zip", or "creditcard_numbers.zip".

Hmmm.. wouldn't it be nice to add this to a honeypot webserver? if someone's looking for wp-login directories, just return zblg.zip. It would be nice if there's a 10TB option of about 0.5 - 1mb.

Facebook accesses links shared in private messages... not sure if they'll unzip it

Reply on news.ycombinator.com