Lately, one of the websites under my protection was being DDoSed by a well-known trouble-making party whose name shall not be released and stay anonymous. Another party that is monitoring the web for threats against our websites notified me that a DDoS was currently being  started. It seemed that the attackers were spamming a link to an automatically starting WebLOIC via mail and tricked others with a variation of methods to open the URL so that they would automatically participate in the DDoS.

Let’s move to the technical side: it was a pretty small DDoS, with about 50MBit/s – we probably wouldn’t have noticed as it just looked like a normal traffic spike and did not endanger the availability of the website at all. We’ve handled much larger legitimate traffic spikes for that site already.

A quick investigation showed that WebLOIC was being used and was ‘hosted’ on a nopaste service. Requests looked like this:

GET /?id=1300380622178&msg=We%20Are%20Legion! HTTP/1.1
Host: XXXXXXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://xxxxxxxxx.html

Quickly checking out the referer gave me the sourcecode; the id consists of a timestamp and the request id. The ‘msg’ is a user-changable text, but ‘id’ is javascript-generated.

How to block it?
– Use a regular expression for the query string (very easy)
– Block users with a referer from that nopaste service (very easy, too)
– Block users that do more than X connections within a minute (easy if you have a decent firewall), side-effects might cause large NAT gateways from mobile providers to be blocked, but that’s better than being completely offline, right?

Where to block:
– block as early as possible: in your DPI firewall, web application firewall or loadbalancer
– *not* in every single webserver

Having Fun:
As the WebLOIC runs in the attacker’s browser, there are lots of possibilites:
– redirect attackers to a site known to be monitored by the FBI (explosives, terrorism etc.)
– CSRF, make them post something on a service like facebook or twitter (#iDDoS-site.tdl) and search for their posts. Kindly ask them to stop.
– redirect the attackers to do lots of google searches – they will quickly be blocked by google services
– send a gzip-encoded stream that consumes lots of cpu time and memory on their side, this might even crash the browser
– ‘reflect’ the DDoS to somewhere else (sending 301/302 redirects is pretty low-bandwidth for you)

So in total, WebLOIC was a good idea, but right now rather inefficient and its usage might have unwanted sideeffects… 😉