A blog which tries to demystify computer security, point out the half-truths and misinformation which floats around about this subject and hopefully reduce the hype created by semi-informed people. It also has some useful tips from time to time.

First time here? I hope that you find something interesting and useful. Check out the most popular pages or the categories I most frequently post in:

Thursday, March 26, 2009

The idea is not new: get a lot of users to view a given webpage, to DDoS the webserver / backend (depending where the bottlenecks are). If I recall correctly, some student asked the visitors of his website to continuously refresh the page of his university and got charged for it.

As many have remarked at the time (a) the university had some weak webservers if it caved to such simple methods and (b) this can be done automatically with Javascript or Flash and would be very hard to track down.

Imagine the following scenario:

The attacker inserts arbitrary Javascript or Flash content on one or more medium-to-high traffic websites. This can be done multiple ways: one can hack into CMS’s and modify the content of the articles to include the code in the articles. There are many vulnerable sites out there. Or, an even simpler solution is to buy placements for Flash banner ads and include the code in them.

The code (a) looks up a DNS name (this makes the attack targetable) (b) launches N “threads” and starts sending requests to the given website

Such attacks would be very hard to diagnose. The requests would come intermittently from a wide range of IP addresses. Even if you could get your hands on such a computer, you couldn’t find the source of the requests easily (it’s not like the computer is infected with a malware you can find by scanning the files on the hard-disk). It can be also very sneaky, randomly executing (or not) or using geotargeting to select a subset of computers. These techniques are already in use by malicious advertisements (“malwertisements”) which are currently used to try to sell you rogue AV products. An other reason which makes finding the source hard, is the fact that AFAIK XMLHttpRequest does not send the referrer header. An other way to get rid of the referrer header is to make the request from a HTTPS site (browsers do not send referrer in this situation to avoid information leakage).

What can you do? Not very much. Prepare for the DDoS. Have a contingency plan (like a backup location in a different IP space and pointing your DNS entry there). You might be able to differentiate the requests from “normal” requests, but even so, the volume of requests can bring down the machine at the TCP level. And please, please secure your website. We have enough unsecured websites already!