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

How to defend your website with ZIP bombs (2017)

blog.haschek.at

Post reply on HN
Print view View original

31–40 of 79 posts

Re: How to defend your website with ZIP bombs (2017)

#31

Post by ivancho »

hannob wrote: post #16

People have been coming up with ideas like that regularly. I'm not a fan. The title says that you can "defend" your webpage, but it is not clear how it "defends" against anything. The only thing you possibly achieve is that every now and then, someone with an automated scanner (which may be an attacker, or may be a security researcher or service) will see his tool crash or consume large amounts of resources. You're s…

No one is really worried, and no time is wasted when the outcome is occasional fun. There's no security holes to fix, there's just a bunch gnats poking at your server and you shoo them away, that's all.

Re: How to defend your website with ZIP bombs (2017)

#32

Post by el_oni »

noobermin wrote: post #26
hannob wrote: post #16

People have been coming up with ideas like that regularly. I'm not a fan. The title says that you can "defend" your webpage, but it is not clear how it "defends" against anything. The only thing you possibly achieve is that every now and then, someone with an automated scanner (which may be an attacker, or may be a security researcher or service) will see his tool crash or consume large amounts of resources. You're s…

It really is only in the world of IT security is this attitude so pervasive, where you constantly blame victims. While defense is a great offense it can't hurt to be an annoyance to bad actors.

unless it paints a target on your back

Re: How to defend your website with ZIP bombs (2017)

#33

Post by inglor_cz »

iforgotpassword wrote: post #4

I've done this without compression but just sending infinite data. On some days I've sent a TB to a single IP address... Might be an idea to combine this. I'd assume the resulting gzip file here contains a repeating pattern that you can generate on the fly?

Was your hosting OK with that? ZIP bombs are light on the "data transferred" front, a TB is pretty massive.

Re: How to defend your website with ZIP bombs (2017)

#34

Post by lifthrasiir »

Retr0id wrote: post #11
iforgotpassword wrote: post #4

I've done this without compression but just sending infinite data. On some days I've sent a TB to a single IP address... Might be an idea to combine this. I'd assume the resulting gzip file here contains a repeating pattern that you can generate on the fly?

Yes, it would be trivial to make an "endless" gzip stream.

And if you need an explicit binary, it is very easy to make one. Prepare a large enough file filled with the same byte (or generate them on the fly), let gzip to compress it, then observe where the zero byte start to repeat. Cut everything after that point and repeat the zero byte from there on. In my system:

    $ head -c 10000000 /dev/zero | gzip -c -9 | hexdump
    0000000 8b1f 0008 530a 659e 0302 c1ec 0101 0000
    0000010 8000 fe90 eeaf 0a08 0000 0000 0000 0000
    0000020 0000 0000 0000 0000 0000 0000 0000 0000
    *
    0002010 0000 0000 0000 db80 0383 0012 0000 4100
    0002020 5fff 23b7 0150 0000 0000 0000 0000 0000
    0002030 0000 0000 0000 0000 0000 0000 0000 0000
    *
    00025f0 0000 0000 0000 0000 0000 0000 0000 e000
    0002600 cb26 3ba5 803e 9896 0000
    0002609
So you can keep the first 0x18 bytes and repeat zero bytes after that, preferably very slowly. (The middle bit is an arbitrary block boundary, while the last bit is CRC-32 and the uncompressed size which the client will never see.) I have also used `-c` option to avoid the original file name in the result, which precedes the compressed data.

Re: How to defend your website with ZIP bombs (2017)

#35

Post by theshrike79 »

cyberax wrote: post #3

TIL today: ZIP bombs are still a thing, 40 years after the first BBS.

Similar things were popular in the DC++ age too.

Some servers required you to have X gigabytes of stuff in your shares, so you just had a zip bomb in your share with the correct size.

It reported the size as 10GB to the server, but actually it took a few kilobytes on disk.

Re: How to defend your website with ZIP bombs (2017)

#36

Post by hannob »

noobermin wrote: post #26
hannob wrote: post #16

People have been coming up with ideas like that regularly. I'm not a fan. The title says that you can "defend" your webpage, but it is not clear how it "defends" against anything. The only thing you possibly achieve is that every now and then, someone with an automated scanner (which may be an attacker, or may be a security researcher or service) will see his tool crash or consume large amounts of resources. You're s…

It really is only in the world of IT security is this attitude so pervasive, where you constantly blame victims. While defense is a great offense it can't hurt to be an annoyance to bad actors.

Can you tell me where in my words you read that I blamed victims? I think you're reading something into it that isn't there.

Re: How to defend your website with ZIP bombs (2017)

#37

Post by 13of40 »

It reminds me of someone I read about from the early web who defended their website against email address harvesting crawlers by adding a dynamic page that threw up some random emails and links, where the links just led back to the dynamic page under a new path on the same host. The crawlers would get stuck downloading millions of fake email addresses until they eventually broke.

Re: How to defend your website with ZIP bombs (2017)

#38

Post by hannob »

foul wrote: post #29
hannob wrote: post #16

People have been coming up with ideas like that regularly. I'm not a fan. The title says that you can "defend" your webpage, but it is not clear how it "defends" against anything. The only thing you possibly achieve is that every now and then, someone with an automated scanner (which may be an attacker, or may be a security researcher or service) will see his tool crash or consume large amounts of resources. You're s…

>You're spending time trying to annoy attackers that you should probably just ignore. s/ignore/block at firewall-level/ To me this article is of relevance nonetheless because It inspires me for messing with AI trainers by crafting an html page ZIP bomb full of ZIP-bomb-like embedded attachments (stylesheets, images, etc).

No, ignore.

WAFs that "block" "attacks" that ultimately should just cause a 404 error are part of the same mindset: That you think you "have to do something" about an attack that you should probably just ignore. They're also part of the mindset that security should mean adding more complexity, which is the opposite of what you should do.

Re: How to defend your website with ZIP bombs (2017)

#39

Post by hannob »

ivancho wrote: post #31
hannob wrote: post #16

People have been coming up with ideas like that regularly. I'm not a fan. The title says that you can "defend" your webpage, but it is not clear how it "defends" against anything. The only thing you possibly achieve is that every now and then, someone with an automated scanner (which may be an attacker, or may be a security researcher or service) will see his tool crash or consume large amounts of resources. You're s…

No one is really worried, and no time is wasted when the outcome is occasional fun. There's no security holes to fix, there's just a bunch gnats poking at your server and you shoo them away, that's all.

If your goal is "fun" then I guess that's fine. But don't pitch it as "defending" your website.

Re: How to defend your website with ZIP bombs (2017)

#40

Post by lifthrasiir »

hannob wrote: post #38
foul wrote: post #29

Earlier quoted context omitted.

>You're spending time trying to annoy attackers that you should probably just ignore. s/ignore/block at firewall-level/ To me this article is of relevance nonetheless because It inspires me for messing with AI trainers by crafting an html page ZIP bomb full of ZIP-bomb-like embedded attachments (stylesheets, images, etc).

No, ignore. WAFs that "block" "attacks" that ultimately should just cause a 404 error are part of the same mindset: That you think you "have to do something" about an attack that you should probably just ignore. They're also part of the mindset that security should mean adding more complexity, which is the opposite of what you should do.

I would like to compare this to dealing with unsolicited robocalls. Most would just ignore them, and it's indeed an unwise choice to accept them. But some try to strategically waste the caller's time by only accepting and doing nothing else. I can't say whether it's beneficial or not, but I can say that it is easy enough to do without worrying too much.
Post reply on HN