Saturday, January 18, 2014

Cookie Bomb or let's break the Internet.


TL;DR I can craft a page "polluting" CDNs, blogging platforms and other major networks with my cookies. Your browser will keep sending those cookies and servers will reject the requests, because Cookie header will be very long. The entire Internet will look down to you. 

I have no idea if it's a known trick, but I believe it should be fixed. Severity: depends. I checked only with Chrome.

We all know a cookie can only contain 4k of data.
How many cookies can I creates? Many!
What cookies is browser going to send with every request? All of them!
How do servers usually react if the request is too long? They don't respond, like this:


If you're able to execute your own JS on SUB1.example.com it can cookie-bomb not only your SUB1 but the entire *.example.com network, including example.com.
var base_domain = document.domain.substr(document.domain.indexOf('.'));
var pollution = Array(4000).join('a');
if(confirm('Should I Cookie Bomb '+base_domain+'?')){
  for(var i=1;i<99;i++){
    document.cookie='bomb'+i+'='+pollution+';Domain='+base_domain;
  }
}
Just set lots of 4k long cookies with Domain=.example.com so they will be sent with every request to *.example.com.
All requests will be ignored, because servers never process such long requests (the "Cookie" header will be like half a megabyte).

Victim is sad and crying. No more blogspot. No more github.io. Such sad user. Not wow.

It will last until the user realizes he needs to delete his cookies. Not all human beings are that smart though.

Who can be cookie-bombed?
  1. Blogging/hosting/website/homepage platforms: Wordpress, Blogspot, Tumblr, Heroku, etc. Anything having <username>.example.com with your JS.
    You don't need government to ban blog platforms anymore - use cookie bomb. (Joke)
  2. Subdomains serving your HTMLs, even if they're created for user input you can cookie-bomb entire network and "poison" other subdomains with it: Dropbox, Github.io
  3. Content Delivery Networks. Ouch! You can poison *.CDN_HOST.com and break scripts/CSS on all websites using this CDN.
  4. System sandbox domains like GoogleUserContent.com. When I poison it - Google Translate, GMail attachments, Blogspot images - entire Google ecosystem goes crazy.
  5. Use it along with other attacks (XSS, Header injection, HTTP:// cookie forcing)

Proofs of Concept




Tip for hackers: you can "block" some exact path by specifying ;path=/some_path in the cookie bombs attributes. Your personal censorship!
Tip for browsers: limit amount of cookies on .example.com or send only sane number of them, but i'm not sure it's a pragmatic way.
Tip for admins: instead of sub1.example.com use sandbox.sub1.example.com, which will limit impact of the cookie bomb to .sub1.example.com zone.
Tip for users: if you was cookie-bombed remove "bombs" here:


22 comments:

  1. God says "Do a better job training your Markov chain walker!"

    ReplyDelete
  2. I remember something like that from here http://sirdarckcat.blogspot.mx/2009/04/how-to-use-google-analytics-to-dos.html

    ReplyDelete
  3. Ahahah, ingeniously simple.

    ReplyDelete
  4. Egor, I've read your article and think that the problem was solved already by most servers.

    http://stackoverflow.com/questions/686217/maximum-on-http-header-values

    ReplyDelete
  5. @Denis: this is not an attack on the server, but on the user's web browser. If you can lure a user to your username.github.io website you can set cookies on their browser that will render *.github.io unusable until they clear their cookies.

    If you're willing to cookiebomb your own browser, try the github.io proof of concept linked above (safest way to do it is to start a private session). In my testing it breaks Chrome and IE, but not Firefox.

    ReplyDelete
  6. "Blogging/hosting/website/homepage platforms: Wordpress, Blogspot, Tumblr, Heroku, etc."

    WordPress.com is not vulnerable because users cannot upload or execute arbitrary JS.

    ReplyDelete
    Replies
    1. Custom Styling through CSS is possible on WordPress.com (which I assume the author is refering to), but due to the security risks associated with running custom Javascript, no user-JS is ever run on a *.wordpress.com or *.wp.com domain name. Sites with an Enterprise domain can run JS, but it's sandboxed to their domain only through special mapping and only outputting JS when it's safe (for us) to.

      Delete
    2. weird, i will check. i know tumblr, blogspot and all others support it

      Delete
    3. diaspora too does support custom js

      Delete
  7. Hehhe. Cool just for prevensive reasons not for attack :). Thanks.

    ReplyDelete
  8. My god, the age old (and often useless) advice of clearing one's cookies may actually be relevant again someday soon.

    ReplyDelete
  9. I see listing allowed domains as a part of CSP directive.

    ReplyDelete
  10. seems like Safari is fine.

    ReplyDelete
  11. Is there anyway we can write nginx module to ignore the cookie, or at least write a basic response to neutralize the cookie by setting Set-Cookie: minimized_cookie_size, hence subsequent browser requests won't continue bombing the planet. User will just treat it as temporary hiccup and probably blame the ISP for that ;-)

    ReplyDelete
  12. Regarding cloud front, it seems the only way to mitigate the issue is to use your own custom asset.yourdomain.com subdomain. But you will bump into SSL issue. Some browsers (e.g. Chrome and IE) won't allow https host to serve non https assets. And cloudfont charge a fortune to install your own SSL (http://aws.amazon.com/cloudfront/custom-ssl-domains/)

    ReplyDelete
  13. "Tip for admins: instead of sub1.example.com use sandbox.sub1.example.com, which will limit impact of the cookie bomb to .sub1.example.com zone."

    I think this is not effective. Browsers use publicsuffix to get effective TLD for cookies. So sandbox.sub1.example.com can still set a cookie for .example.com.

    ReplyDelete
    Replies
    1. No, it isn't true.

      Delete
    2. i am not sure. It would be jumping through 2 subdomain zones, and must not be allowed by RFC

      Delete