· 9 mins read
Share this

Note: This is an archived page and this type of exploit no longer works This site is NOT meant to be an attack site!

The Inspiration

I, like many people, have been closely following a lot of the chaos happening around the recent Wikileaks dump, and was particularly fascinated by the DDoS attacks by activists on either side. One tool specifically caught my eye in the midst of the attacks, however: the JS LOIC. The tool works simply by constantly altering an image file’s source location, so that the browser is forced to continuously hammer the targeted server with HTTP requests. Not a sophisticated or technically interesting tool by any means, but conceptually interesting in that it only requires a browser to execute one’s portion of a DoS attack. While the concept itself is not all that new, it got me thinking about the implications of such browser based DoS attacks. Clearly, it opens the door for the creation of a DDoS botnet without ever having to actually exploit the hosts participating in the network; all that is required is to get some Javascript to run in the participants’ browsers.

As if the JS LOIC concept didn’t have serious enough implications on its own, though, researchers from Attack & Defense Labs recently presented a much more effective DoS attack vector at Blackhat Abu Dhabi, which relies on Web Workers and Cross Origin Requests in HTML5. This attack, though it only works in HTML5 browsers, is supposedly capable of performing between 3,000 to 4,000 requests a minute under real world conditions, which is a significant improvement over the simple but functional img tag reload attack. In my tests, the HTML5 attack clocked in at ~1500-2000 requests/minute, with the img reload attack hovering around 600 requests/minute.

In addition to these DoS worries, I have also been uncomfortable for awhile now about the increasing use of and reliance upon URL shorteners for sharing links. While we can somewhat trust larger names in the field such as bit.ly, it seems that the marketplace for these services is becoming increasingly populated with more and more obscure shorteners. This is quite worrying, as people it encourages people to trust all the shortened links they happen to come across, even ones they’ve never seen before, and acquire a false sense of security in the knowledge that it will take them to the destination advertised by the text. However, as most relatively savvy people should know, this is certainly not always the case. A malicious shortener could essentially take you anywhere it pleased, and the user would be none the wiser.

D0z Me Please

With these issues in mind, I began wondering: what would happen if I mashed them all together? Enter d0z.me: a proof-of-concept URL shortener that, while getting users to their destinations, also covertly attacks an arbitrary server.

The concept is quite simple, really. Attackers go to d0z.me and enter a link they think could be popular/want to share, but also enter the address of a server that they would like to attack as well. Then, they share this text with as many people as possible, in as many places as possible. Extensive use of social media sites is probably a must achieve the best results.

When users click on the link, they appear to be redirected to the requested content, but they are in fact looking at the page in an embedded iframe. This is identical to how those rather annoying Digg and Stumbleupon toolbars work, except the embedding is invisible to the user (minus the location URL in the toolbar). While the users are busy viewing the page, a malicious Javascript DoS runs in the background, hammering the targeted server with an deluge of requests from these unsuspecting clients. If these clients continue browsing from that page, we can maintain our DoS in the background the entire time.

Clearly, this attack is dependent on getting a significant number of users to view a given link in a short amount of time, and, hopefully, keeping them on the page as long as possible. There are two main scenarios for garnering such traffic: one, tricking users into viewing the link and staying on it through whatever means necessary, and two, a concerted effort by a large number of users who willingly join the DDoS by following the link.

Scenario number one requires that the malicious attacker first come up with some content that he/she thinks will/could become popular; finding said content, of course, is not always an easy task. One possible vector is through the use of online games. Such games tend to keep users on the site for extended periods of time, lengthening the time of DoS. If one could find/make a game popular enough, and spread it through this link, then a significant amount of traffic could be achieved. Another possibility is a variation on what we have come to know as the free iPad scam. Tell users that if they open a link and stay on the page long enough, they will win a free iPad. This could be surprisingly effective, given how successful such offers have been in the past. A third possible way to exploit this technique could be a malicious rick roll of sorts: promise one thing, deliver another ridiculous/hilarious other thing, and hope that people find it funny and spread it quickly to as many people as possible.

Scenario two seems more similar to what we are currently seeing behind the Wikileaks-related attacks. If leaders convince enough of their followers simply to “open this link to win”, it is conceivable that a very large number of people would chose to do so. However, this particular method (URL shortened link) is much more troublesome than current methods as, in such a scenario, there would be little way for authorities to determine whether or not a participant was intentionally or inadvertently involved in the attack. It is possible that some participants may have simply been curious or tricked into clicking the link, providing plausible deniability for any would-be attacker.

Both of these attacks, of course, can be mixed together in a hybrid style attack, which is the most likely form that it would take in a real DDoS. It is not completely clear to me what results a possible attack could achieve, but it seems likely that, given a dedicated userbase, one could use this method with a decent level of effectiveness. In addition, it would give intentional attackers a shield of plausible deniability to hide behind in case their IP address was singled out as an attacker in the DoS.

Implementation Details

As it is, the HTML5 attack and the img reload attack are both basically invisible in Chrome unless you’re looking for them. I had to open Wireshark, the Javascript console, or my server logs to verify that the DoS was actually functioning correctly. Firefox is pretty noisy about the tests, though, as the img reload attack causes the page to appear to be loading indefinitely, and the HTML5 web worker threads chew up processor time.

I haven’t spent much time trying to solve these, but if someone knows a fix, I’d appreciate your help. I have also done a little messing around with different ways of keeping the user on the page, but atm have not had much success without resorting to extremely annoying and only minimally effective techniques. I am releasing the code under the GPLv3, and, as always, welcome any advice that people have. As it’s been a couple years since I’ve done much web application work, please be gentle.


Mitigating these types of attacks is not exactly straightforward. As with all DoS attacks, there’s only so much one can do to prevent them. If an attacker simply has more bandwidth than you have, as they would if they got enough people to click these links, then it’s pretty much game over regardless until you can get the attacks blocked at the ISP level. As these attacks do not rely on spoofed packets, and appear, at least at a passing glance, to be legitimate traffic, filtering it is also somewhat difficult.

The HTML5 CORS attack, according to A&RL’s research, can be blocked if your server doesn’t allow cross origin requests by making a rule in your WAF that blocks all requests with Origin in the headers. However, given enough people doing this attack, it could become overwhelmed regardless.

You can find more about mitigating DoS attacks on Google.

From an end-user’s perspective, all you need to do to avoid joining a DDoS is to be careful about following suspicious URL redirector links, and use something like NoScript.

A few final notes:

Firstly, this site is NOT meant to be an attack site, or to help support either side in the whole Wikileaks debacle. I don’t want any part in the current cyber skirmishes. It is merely a demonstration of some things that I found interesting and wanted to work on.

Secondly, I am not responsible for how this site or this code is used. You should only be testing this on sites you own and control, and if you aren’t, chances are that you are breaking the law. You, the user, are responsible for knowing the relevant laws in your area, and acting accordingly.

Thirdly, to the researchers who first reported on the HTML5 DDoS vector, thanks. Quite interesting research. I owe you a beverage of your choosing sometime :P .

Finally, yes, to all you a-holes out there, I know, it would be ironic/funny to dos a site that is demonstrating a dos attack. Please don’t. I know you can, and that it would be trivial to do, as this server isn’t exactly hardened. Let’s just save each other the time and hassle and say that you win, theoretical attacker. Congratulations.


Best VPN
Join Newsletter
Get the latest post right in your inbox.