CloudFlare servers are constantly being targeted by DDoS attacks, from attempted DNS reflection attacks to L7 HTTP floods involving large botnets. Recently, an unusual flood caught our attention - a massive influx of HTTP requests issued against one of our customers.
The request that triggered the alarm was a POST request with a legitimate-looking header and a User-Agent identifier indicating it was issued by a real browser. The request included an Origin header, suggesting it was part of an Ajax (XHR) cross-origin call. Furthermore, the Referer header pointed to a website issuing these queries against our servers - a crucial detail in understanding the scope of the attack.
Browser-based floods have been rumored as a theoretical threat for some time. In 2010, Lavakumar Kuppan proposed abusing browser HTML5 features for DoS attacks. Later, Jeremiah Grossman and Matt Johansen suggested web advertisements as a distribution vector for malicious JavaScript. A paper published this year discussed the theoretical cost of such an attack.
The difficulty in creating these types of attacks lies not in crafting the malicious JavaScript but in effectively distributing it. Until now, I hadn't seen many sizable browser-based floods - that is, until this unusual flood caught our attention.
The source of the flood was traced back to a website, which we'll refer to as "the attack site." The page looked like a link farm or ad aggregator, with blinking and shouting banners centrally on a page. Upon closer inspection, it loaded three small JavaScript files, one of them being called count.js. This file contained some innocuous document.write statements followed by an obfuscated code snippet.
Further analysis revealed that the malicious script launched an XHR in a loop, sending requests to a targeted domain at a rapid pace. The script also employed a clever method of detecting Internet Explorer 9 and older using the if(!+[1,]) syntax.
The logs revealed a stunning peak of over 275,000 HTTP requests per second, making it one of the largest browser-based floods we've seen. Upon further analysis, we found that the flood was coming from a single country: China (99.8%), with a small percentage coming from other countries.
Interestingly, our system was able to extract the device type from the user agent, revealing that 80% of the requests came from mobile devices - a significant proportion considering the scale and complexity of the attack.