Application security

5 08, 2014

6Scan Quarantine Technology Defeats Dynamic DNS Watering Hole Attack

waterhole.drinking wateringhole.attack

At 6Scan we are obsessed with simplifying security. After we figured out how to automatically detect and repair website vulnerabilities we set about doing the same for web-based malware. As 85% of all malicious web-based links are hosted on legitimate sites that have been hacked, solving this challenge would provide an unprecedented level of protection for our community.

We decided that quarantining the code, just as an anti-virus product does with malware on a desktop computer, was the best way to immediately protect the website and customers against malicious re-directs and drive-by downloads. But as we developed this approach we also discovered a powerful benefit: by quarantining the code we could quickly reverse engineer its behavior. This allows us to identify its infection techniques and how it communicates with command and control (C&C) servers. We tested these capabilities during our beta deployment, and were able not only to secure a hacked retail website, but to analyze the activity of its infection.

Overview

The customer in this case is a popular online furniture website. They had received sporadic indications of anomalous behavior on their site but were unable to identify any malicious code. They had never been blacklisted by any search engines or browsers, and in fact they had active Google AdWords campaigns running. Despite the continued functioning of their website, they had been infected for the previous 5 months.

After our website scan detected the malware, our agent pinpointed the infection and quarantined the malicious code automatically. This immediate action secured the website and its visitors. Then we analyzed the attack and that’s where it got interesting.

Following Commands

Through log analysis we could see the malware contained a calling script that collects information about each visitor to the website and then sends that information to a C&C server.  The C&C server evaluated the information (user agent, referrer and IP) and directed malware either to launch or not to launch the exploit code. It launched the code only if it was a new visiting IP and the user agent (browser) was Opera or IE 11 or earlier. Browser selection is a common technique to decrease the probability of detection. Considering the site had been infected for 5 months prior to our detection, it turned out to be a highly effective strategy on the part of the hackers.

Hiding in PNG Site

The calling script (the mechanism by which the malicious code on the website communicated with the C&C server) was an encoded PHP function that was embedded in a PNG image on the website. It looked like this:

HideinPNGsite

 

If the C&C server sent back exploit code it appeared as an obfuscated JavaScriptsnippet that created an iframe to another domain.The novelty in this approach was that the domains were generated dynamically and immediately deactivated after a single use—effectively hiding the hacker’s tracks.  All the domains were available via a free dynamic DNS service.

Here’s a snippet of a decoded PHP code:

PHP.Code

 

So, how was the PHP code extracted from the image data and run?

The following is the malware injection code that ran in the nav menu file. The nav file loaded for every page making this an efficient tactic.

InjectionCode

What happens here is that the path to the image file is encoded in the first array (we’ve removed the prefix to keep our client confidential), and then the code is read from the PNG file (which is all chars after the cls::: prefix). The next step is evаl(bаse64_decode which is run to decode the information from the image file, and then the $view, which is where preg_replace is run. As is widely known by PHP coders, running preg_replace with /e flag is effectively equivalent to running the eval() function. The afflicted webserver has been tricked into serving up malicious code to its customers. Because of clever obfuscation the mechanism of the attack is not apparent—at least not until 6Scan quarantined it and analyzed its function.

The Damage Done

Once the obfuscated JavaScript has been loaded onto the site it then probes each visiting browser for vulnerabilities. When a vulnerable application is detected, the C&C server dynamically loads up to 4 exploits which can be used to further compromise the visiting browser as well as the device running it.

Though the obfuscation was rather tough, we managed to decode it to see what exploits are loaded. They included 2 Java exploits, a Flash exploit and an interesting Silverlight exploit  (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0074 ). All of the exploits give the attacker the ability to execute arbitrary code on the victim’s computer.

6Scan Customers Benefit

Our innovative approach to detecting, quarantining, and analyzing malicious code—all in real time—brings benefits to every 6Scan customer. Our automated service puts this power in the hands of even the smallest business and our threat analysis shows how hackers work and enables us to stay one step ahead of the next attack.

29 05, 2014

eBay Security and the “Punching Bag of the Internet”

WebAttacks

Percentage of Breaches by Attack Vector from the 2014 Verizon Data Breach Report

Not only has eBay security been undone by their tolerance for what  The Register referred to as “Rubbish Passwords” — now there are reports of multiple Cross Site Scripting (XSS) vulnerabilities on eBay subdomains.

As the 2014 Verizon Data Breach Investigations Report chronicled, web applications were the top attack vector for successful data breaches in 2013. The report went so far as to dub web applications “the proverbial punching bag of the Internet.”

At 6Scan we block millions of attempts to exploit vulnerable applications every month. Currently XSS is the 4th most prevalent attack we see. While XSS does not pose an immediate threat like an SQL injection does, the security implications are highlighted in the OWASP.org XSS attack definition:

“An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.”

The significance of the attack is not only in access to the vulnerable application, but malicious access to the trusted relationship between user and a given site (like eBay).  We recently wrote about an NFL team with an active XSS vulnerability -it’s in these situations with powerful brands that XSS vulnerabilities can do the most damage. So while eBay chose to downplay the vulnerability with the comment that it’s “not a new type of web application vulnerability on sites such as eBay,” the reality is that the severity of the threat is directly related to the trust of the brand.

Stay safe.