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
My implementation of this attack is, at best, a hack job, but was merely meant to illustrate how easy it is to actually implement, how simple it is to launch a DDoS simply by getting people to follow a link, and how seriously our reliance on URL shorteners can affect security. This implementation utilizes two DoS methods: first, of course, is the same method as the JS LOIC (refreshing images repeatedly), and second is the HTML5 vector that was previously discussed. The linked page is embedded via a simple iframe.
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.
Mitigation
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.
Final Notes
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 
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.
====
Performing DDoS attacks with HTML5 Cross Origin Requests & WebWorkers
http://goo.gl/KAjwJThis post is about a DDoS technique I spoke about at BlackHat Abu Dhabi that uses two HTML5 features - WebWorkers and Cross Origin Requests. It is a very simple yet effective technique - start a WebWorker that would fire multiple Cross Origin Requests at the target. This is possible since Cross Origin Requests that use the GET method can be sent to any website, the restriction is only on reading the response which is anyway not of interest in this case. Sending a cross domain GET request is nothing new, you can even do that by embedding a remote URL in the IMG or the SCRIPT tag but the interesting part here is performance. My tests on Safari and Chrome showed that both the browsers were able to send more than 10,000 Cross Origin Requests in one minute.
So simply by getting someone to visit a URL you can get them to send 10,000 HTTP requests/minute to a target of your choice. Now if you pick a juicy target URL, one that would make the server do some heavy processing then just 10,000 requests/minute might overwhelm it. Lets scale this a little, say 60 people visit the URL containing the DoS JavaScript, that is 10,000 requests/second at the target. With just 6000 visitors to this URL we can send around 1 million requests/second to the target. Getting 6000 Chrome and Safari users to visit a particular URL is no big deal really.
Maybe its not that simple, there are few things to consider here. When you send the first request to a particular page and the response does not contain the 'Access-Control-Allow-Origin' header with a suitable value then the browser refuses to send more requests to the same URL. This however can be easily bypassed by making every request unique by adding a dummy query-string parameter with changing values. The number of requests/minute is also a variable. The browser sends a certain number of requests and when it receives the responses for those it sends in the next set of requests and so on. So as the server slows down the browser's requests/minute rating would also slow down. The figure 10,000 requests/minute was clocked against a server located in the internal network, against a target in the Internet it would realistically be between 3000-4000 requests/minute. If the attacker is planning to target an internal server by getting the employees of that company to visit this malicious URL then the 10,000 requests/minute rating would apply.
I am not going to release any PoC as this might probably be a bad time to do that but it shouldn't be very difficult to put together something for testing once you understand how it works. It should be relatively easy to block this attack at the WAF since all Cross Origin Requests contain the 'Origin' header, that way you can differentiate between legitimate and malicious requests.
