Sunday, 17 November 2013

DDoS attack from Browser-based Botnets that lasted for 150 hours

Browser-based botnets are the T-1000s of the DDoS world. Just like the iconic villain of the old Judgment Day movie, they too are designed for adaptive infiltration. This is what makes them so dangerous. Where other more primitive bots would try to brute-force your defenses, these bots can simply mimic their way through the front gate.

By the time you notice that something`s wrong, your perimeter has already been breached, your servers were brought down, and there is little left to do but to hang up and move on.


So how do you flush out a T-1000? How do you tell a browser-based bot from a real person using a real browser? Some common bot filtering methods, which usually rely on sets of Progressive Challenges, are absolutely useless against bots that can retain cookies and execute JavaScripts.

The alternative to indiscriminately flashing CAPTCHA’s for anyone with a browser is nothing less than a self-inflicted disaster - especially when the attacks can go on for weeks at a time.
To demonstrate how these attacks can be stopped, here's a case study of an actual DDoS event involving such browsers; an attack which employed a swarm of human-like bots which would – under most circumstances - result in a complete and total disaster.

Browser-based Botnet: Attack Methodology
The attack was executed by an unidentified botnet, which employed browser-based bots that were able to retain cookies and execute JavaScript. Early in the attack they were identified as PhantomJS headless-browsers.
PhantomJS is a development tool that uses a bare-bone (or "headless") browser, providing its users with full browsing capabilities but no user interface, no buttons, no address bar, etc. PhantomJS’s can be used for automation and load monitoring.
The attack lasted for over 150 hours, during which we recorded malicious visits from over 180,000 attacking IPs worldwide. In terms of volumes, the attack peaked at 6,000 hits/second for an average of +690,000,000 hits a day. The number of attacking IPs, as well as their geographical variety, led us to believe that this might have been a coordinated effort, involving more than one botnet at a time.
More than one Botnet?
Throughout the duration of the attack we dealt with 861 different user-agent variants as the attackers constantly modified the header structure to try and evade our defenses. Most commonly, the attackers were using different variants of Chrome, Opera and FireFox user-agents.

Facebook Open URL Redirection vulnerability

Hacking Facebook - Facebook Open URL Redirection vulnerability Security Researcher Dan Melamed discovered an Open URL redirection vulnerability in Facebook that allowed him to have a facebook.com link redirect to any website without restrictions.

An open URL Redirection flaw is generally used to convince a user to click on a trusted link which is specially crafted to take them to an arbitrary website, the target website could be used to serve a malware or for a phishing attack.
An Open URL Redirection url flaw in Facebook platform and third party applications also exposes the user's access token at risk if that link is entered as the final destination in an Oauth dialog.

The Facebook Open URL Redirection vulnerability exists at landing.php page with "url" parameter, i.e.
http://facebook.com/campaign/landing.php?url=http://yahoo.com
This URL will always redirects user to the Facebook's homepage, but it is sufficient to manipulate the "url" parameter assigning a random string:
http://facebook.com/campaign/landing.php?url=asdf
In reality the above URL generated a unique "h" variable and passed the url parameter to Facebook's Linkshim (l.php):
http://www.facebook.com/l.php?u=asdf&h=mAQHgtP_E
Once noted the redirection process, Dan Melamed explored the way to exploit the mechanism to bypass the restrictions on redirection and loaded an arbitrary link.

Japanese word processor 'Ichitaro' zero-day attack discovered in the wild .

Japanese most popular word processing software 'Ichitaro' and Multiple Products are vulnerable to a zero day Remote Code Execution Flaw Vulnerability, allowing the execution of arbitrary code to compromise a user's system.

According to assigned CVE-2013-5990malicious attacker is able to gain system access and execute arbitrary code with the privileges of a local user.
The vulnerability is caused due to an unspecified error when handling certain document files. "We confirm the existence of vulnerabilities in some of our products." company blog says.

In a blog post, Antivirus Firm Symantec confirmed that in September 2013, they have discovered attacks in the wild attempting to exploit this vulnerability during, detected as Trojan.Mdropper, which is a variant of Backdoor.Vidgrab.

Researchers mentioned that Backdoor.Vidgrab variant was used as a payload for a watering hole attack exploiting the Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2013-3893), which was patched in October 2013.

Hacker 'Pinkie Pie' successfully compromised Chrome on Nexus 4 and Samsung Galaxy S4

A Mysterious Hacker who goes by the "Pinkie Pie" handle is rewarded with $50,000 USD for hacking into the Google Chrome browser for Nexus 4 and Samsung Galaxy S4.
At Information Security Conference PacSec 2013 in Tokyo, during the HP's Pwn2Own contest, a zero-day exploit showcased by "Pinkie Pie", that took advantage of two vulnerabilities:
  • An integer overflow that affects Chrome.
  • Chrome vulnerability that resulted in a full sandbox escape.
For successful exploitation, you have to get your victim to visit a malicious website e.g. clicking a link in an email, or an SMS or on another web page. He demonstrated this zero-day attack with remote code execution vulnerability on the affected devices.