D0z.me — the Evil URL Shortener
supernothing writes "DDoS attacks seem to be in vogue today, especially considering the skirmishes over WikiLeaks in the past few weeks. The size of a DDoS attacks, however, has historically been limited by how many computers one has managed to recruit into a botnet. These botnets almost universally require code to be executed on the participants' local systems, whether they are willing or unwilling. A new approach has been emerging recently, however, which uses some simple JavaScript to achieve similar ends. d0z.me is a new service that utilizes these techniques, but provides a unique twist on the idea. Posing as a legitimate URL shortening service, it serves users the requested pages in an iFrame, while simultaneously participating in a DDoS attack in the background. No interaction is required beyond clicking the link and staying on the page. This makes it relatively trivial to quickly mount large-scale DDoS attacks, and affords willing participants plausible deniability in the assault."
Dr Zoidberg: Hurray! I can do no less!!
http://d0z.me/weFZ
No. If you visit the site, it loads javascript on your machine which does the DDOS from your machine. It's not a proxy.
Give me Classic Slashdot or give me death!
You're going to be happy about it.
"All code used on this site is released under the GPLv3, and is available here. "
http://spareclockcycles.org/downloads/code/dosme.tar.gz
Of course, I could be wrong about the referrer being present in requests made from Javascript, but I assume it should be there.
Thats where you're wrong. Hooray for iFrames!
"loads javascript ... which does the DDOS"
And as I keep trying to explain to my friends, letting Some Random Website run whatever random shit on your machine is simply **idiotic**. Really, there's no other way to describe it. It's as idiotic as letting a crack gang have the run of your apartment. You have to be almost wilfully ignorant to not see the issues with the "run anything from anywhere without having the slightest damn idea what it's for" model of security.
I'm sure this is an amazing coincidence, but they're the ones always getting malware, and I never do. They complain about the malware, but show no inclination to listen to me why I try to explain the ways they are getting jacked.
The JS can create and destroy iframes pointed at the site. The browser will then load the site into the iframe, but the security model prevents the referrer field from being present in the iframe to avoid leaking sensitive information (for example, if you load adverts into an iframe while you have a URL with a session ID in it). If this isn't the default, then a silent redirect of the outer frame to an HTTPS URL will do it (aside from a recently-fixed bug in Safari, referrer is not provided to an HTTP URL when it is an HTTPS URL).
I am TheRaven on Soylent News
Because it's an interesting proof-of-concept that DDoS is no longer bound to botnets, as well as proof-of-concept of DDoSing in Javascript.
this is how it shows up in my apache logs:
r00t.me.tld.fail:80 x.x.x.x - - [20/Dec/2010:23:04:08 +0000] "GET /?v=1292886248174 HTTP/1.1" 200 1888 "http://d0z.me/worker.js" "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Ubuntu/10.10 Chromium/8.0.552.215 Chrome/8.0.552.215 Safari/534.10" /?v=1292886251634 HTTP/1.1" 200 1888 "http://d0z.me/worker.js" "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Ubuntu/10.10 Chromium/8.0.552.215 Chrome/8.0.552.215 Safari/534.10"
r00t.me.tld.fail:80 x.x.x.x - - [20/Dec/2010:23:04:11 +0000] "GET
Basically, they have an img tag pointed at the site with an onload function that just keeps reloading the image with a new cachebuster value. If your browser supports HTML5 Web Workers, it also spawns 4 of those and repeatedly AJAXes requests to the site.
It's also painfully obvious that the author isn't fluent in Javascript. The obvious clues being the use of new Array() instead of [] or {} and using setTimeout() with implicit eval instead of passing a function. The initial URL in the img tag is also wrong (it has an extra http:/// prepended.) They also set position: absolute; on the img tag, but don't actually position it anywhere, however, the iframe appears to be on top anyways.
Game! - Where the stick is mightier than the sword!
Well, like any other DDOS, you are screwed. Your ISP won't even help you if you are just a small fry, figuring anything you did to piss that many people off is your own damn fault.
If you are a big customer, and the traffic generated by the DDOS is easily distinguishable from normal traffic (does not look like legitimate web hits) they might help.
It really is amazing that after all these years, there is no DDOS defense.
Sig Battery depleted. Reverting to safe mode.
Interesting proof of concept. How long until someone hacks into a major site, cnn.com, nytimes, etc, and sneaks this code in there? With a little obfuscation it could be buried and hidden pretty easily in the mounds of Javascript most sites are running these days, and be set to activate only when and where the hacker chooses. How long would it take before someone finally figured out what's causing the target to get massively DDoS'ed? Especially if the attacks are staggered, not made to run constantly, and multiple sites are involved at different random times? Virus scan each of the computers involved, and you turn up nothing! No worms or trojans found. Very clever!
Thank you for pointing out the extra http:/// issue, it's been fixed in the live version. Bug leftover from an earlier test version.
The image tag display:block and position:absolute was to fix a bug I was seeing in one of the browsers (don't remember which) that pushed the iframe down slightly. I know the display:block was necessary, don't remember about the position:absolute. That might be a holdover from some other stuff I was messing with.
As for the Javascript, I like using Array() for readability. With the setTimeout, yeah, that was incompetence.
You are indeed correct, I am by no means a Javascript expert, and never claimed to be. I actually mention in the post that web development is not my strong suit, and what few skills I have are outdated. I got the idea for the attack after reading an interesting post by Attack and Defense Labs, and just wanted to hack something together in an hour or two to see if a.) I could reproduce their results and b.) my twist on it was a feasible idea. It seems so far that it was. But yeah, any suggestions you have are definitely welcome. Always love getting input from those smarter than me. Thanks
"All we have is logic and love on our side."
I used similar methods to this to take down multiple ISPs back in the mid-late 90s. When you have enough traffic, you can pretty much choose what their browser does in the background and take down smaller ISPs... Thousands of unsuspecting website visitors all day long trying to load the biggest file I could link to on their server as an image 1x1 pixel or background to some table with a question mark and random trash at the end to cut down on caching. What worked even better once was using their own terrible high cpu usage cgi programming as the 1x1 pixel, that way their cpu was maxed out. It is funny what one pissed off kid can do to a whole ISP or site... Those were the days.
Of course this relies on them not being smart enough to remove the file, add simple apache lines in the config to block referral, etc. Last place that tried something similar to one of my servers had the attack redirected back to them using the apache config and redirects. It did slow my sever a tiny bit but theirs just stopped..
s/©//g
So this bit in .htaccess should suffice to alleviate the DDoS attack?
.* - [F]
RewriteEngine on
RewriteCond %{HTTP_REFERER} d0z\.me [NC]
RewriteRule
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?