Malware Attack Exploiting Flash Zero Day Vulnerability

It's been a while since we've last witnessed malware attacks using zero day vulnerabilities, and the latest one exploiting a zero day in Adobe's flash player is definitely worth assessing. The current malware attack has been traced back to Chinese blackhats, who are using a zero day to infect users with password stealers, moreover, one of the domains serving the Adobe zero day has been sharing the same IP with four of the malware domains in the recent waves of massive SQL injection attacks, indicating this incident and the previous ones are connected. According to Symantec :

"Preliminary investigation suggests that the DeepSight honeynet may also have captured this attack. We are looking into this further. Currently two Chinese sites are known to be hosting exploits for this flaw: wuqing17173.cn and woai117.cn. The sites appear to be exploiting the same flaw, but are using different payloads. At the moment these domains do not appear to be resolving, but they may come back in the future. Network administrators are advised to blacklist these domains to prevent clients from inadvertently being redirected to them. Avoid browsing to untrustworthy sites. Also, consider disabling Flash or use some sort of script-blocking mechanism, such as NoScript for Firefox, to explicitly allow SWFs to run only on trusted sites. "

The Internet Storm Center also made an announcement and assessed a malware domain that was using the exploits in this case play0nlnie.com (125.46.104.172), next to Adobe's Product Security Incident Response Team (PSIRT) original announcement of the vulnerability. What about the original hosting sites for this exploits? Are they still active and serving it, what are the detection rates of the exploits and the malware served, and are there any other domains that should be blocked, also responding to the same IPs.

Let's assess the campaign using the Adobe Flash Player SWF File Unspecified Remote Code Execution Vulnerability. At count18.wuqing17173.cn/click.aspx.php (58.215.87.11) the end user is receiving a look looks like a 404 error message, however, within the 404 message there's a great deal of information exposing the exploits location and participation domains, which you can see attached in the screenshot above. In between several obfuscations we are finally able to locate the exploits serving host, as there are multiple exploits this particular campaign is taking advatange of, in between the Adobe Flash Player one :

0novel.com /real.js
0novel.com /rl.htm
0novel.com /lz.htm
0novel.com /bf.htm
0novel.com /xl.htm
0novel.com /flash.swf
0novel.com /flash1.swf

Let's get back to the second domain which is not returning a valid 403 error forbidden message, woai117.cn (221.206.20.145) which has also been sharing the same IP with kisswow.com.cn; qiqi111.cn; ririwow.cn; wowgm1.cn, among the domains used in the ongoing SQL injection attacks. Once the binary located at woai117.cn /bak.exe was obtained and sandboxed, it tried to download more malware by accessing woai117.cn /kiss.txt with the following binaries already obtained, analyzed and distributed among AV vendors :

117276.cn /1.exe
117276.cn /2.exe
117276.cn /3.exe
woai117.cn /bing.exe

Detection rates for the exploit, the obfuscations and the malware binaries obtained :

Sample obfuscation
Scanners result : 3/32 (9.38%)
F-Secure - Exploit.JS.Agent.oa
GData - Exploit.JS.Agent.oa
Kaspersky - Exploit.JS.Agent.oa
File size: 35767 bytes
MD5...: 11d2b82a35cd37560673680f25571bac
SHA1..: 687066c90bb44fee574f2763041ee80dfee4d5bf

A sample flash file with the exploit
Scanners result : 2/32 (6.25%)
eSafe - SWF.Exploit
Symantec - Downloader.Swif.C
File size: 846 bytes
MD5...: 1222bf4627894cb88142236481680d03
SHA1..: bbf59d9e6610e6f982a7ce7fc9e9878ffd3bfe70

The malware served
Scanners result : 18/32 (56.25%)
MemScan:Win32.Worm.Otwycal.T; a variant of Win32/AutoRun.NAD
File size: 25229 bytes
MD5...: 6be5a7b11601f8cb06ebba08c063aa09
SHA1..: 95d266e2e04e27a923467f483c23818c38ebe19e

The password stealers
Scanners result : 19/32 (59.38%)
Trojan.PWS.OnLineGames.WOM; Win32/TrojanDropper.Agent.NKK
File size: 42268 bytes
SHA1..: 7dfd51e96269f8d53354dd4c028d0c9481ebf4c8

Scanners result : 13/32 (40.63%)
W32/Heuristic-159!Eldorado; Suspicious:W32/Malware!Gemini
File size: 108172 bytes
MD5...: a0383dd1571af5e2f104e1f7d6df7a67
SHA1..: be5b9b00ce9e378e545fa4f1e67160f20ba82ad2

Consider blocking flash by using Flashblock for instance, until the issue is taken care of :

"Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on a webpage and blocks ALL Flash content from loading. It then leaves placeholders on the webpage that allow you to click to download and then view the Flash content. "

It could have been worse, as "wasting a zero day exploit" affecting such ubiquitous player such as Adobe's flash player for infecting the end users with a rather average password stealer is better, than having had the exploit leaked to others who would have have introduced their latest rootkits and banker malware.

UPDATE - 5/28/2008

Consider blocking the following domains currently serving the malicious flash files :

tongji123.org
bb.wudiliuliang.com
user1.12-26.net
user1.12-27.net
ageofconans.net
lkjrc.cn
psp1111.cn
zuoyouweinan.com
user1.isee080.net
guccime.net
woai117.cn
wuqing17173.cn
dota11.cn
play0nlnie.com
0novel.com

UPDATE - 5/29/2008

Zero day or no zero day? It appears that the exploit used in this campaign is an already known one, namely CVE-2007-0071, and this has since been verified by multiple parties who were assessing the incident. Some related comments :

Flaw Watch: Why Adobe Flash Attacks Matter
"Thursday, however, Symantec backtracked after Adobe released a statement denying that the matter concerned a new flaw. In a progress report posted to the official Adobe PSIRT blog, David Lenoe said the exploit "appears to be taking advantage of a known vulnerability, reported by Mark Dowd of the ISS X-Force and wushi of team509, that was resolved in Flash Player 9.0.124.0." In an update to that blog entry, he said Symantec had confirmed that all versions of Flash Player 9.0.124.0 are not vulnerable to the exploits. Symantec Senior Researcher Ben Greenbaum acknowledged the flaw was previously known and patched by Adobe April 8, though the Linux version of Adobe's stand-alone Flash Player version 9.0.124 was indeed vulnerable to the attack."

Potential Flash Player issue - update
"We've just gotten confirmation from Symantec that all versions of Flash Player 9.0.124.0 are not vulnerable to these exploits. Again, we strongly encourage everyone to download and install the latest Flash Player update, 9.0.124.0. To verify the Adobe Flash Player version number, access the About Flash Player page, or right-click on Flash content and select “About Adobe (or Macromedia) Flash Player” from the menu. Customers using multiple browsers are advised to perform the check for each browser installed on their system and update if necessary. Thanks to Symantec for working very closely with us over the last 2 days to confirm that this is not a zero-day issue, and to Mark Dowd and wushi for originally reporting this issue. "

More information on recent Flash Player exploit
"This is not a zero-day exploit. Despite various reports that have been circulating, the Flash Player Standalone 9.0.124.0 and Linux Player 9.0.124.0 are NOT vulnerable to the exploits discussed in conjunction with the previously disclosed vulnerability Symantec posted on 5/27/08. Symantec originally believed this to be a zero-day, unpatched vulnerability, but as their latest update on their Threatcon page indicates, they have now confirmed this issue does not affect any versions of Flash Player 9.0.124.0."

Followup to Flash/swf stories
"On closer examination, this does not appear to be a "0-day exploit". Symantec has updated their threatcon info, as well. We have yet to see one of these that succeeds against the current version (9.0.124.0), if you find one that does, please let us know via the contact page."

Why was the possibility of finding one that succeeds against the current version of Flash considered in ISC's post? Because with no samples distributed by Symantec verifying the zero day, the way the exploit serving flash files were generated at the malicious domains on a version basis (WIN%209,0,115,0ie.swf for instance), and with everyone trying to figure it out in order to obtain the malicious flash file for the latest version in order to verify its zero day state, this timeframe resulted in the delay of assessing the real situation.