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.
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.
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.
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 .
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 & WebWorkershttp://goo.gl/KAjwJ
This 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.
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.