Flash Zero-Day Attacks WoW

Right now there are a number of reports about a lethal Internet cocktail: an zero-day Adobe Flash exploit and widespread (20,000 domains at the time of writing) domains compromised via SQL injection to spread the drive-by-download attack.  It feels like one of those days when you tell your friends to take a day off from using the Internet.

I was forwarded some links to the exploit and its payload by Ryan Naraine and spent a few hours reversing the exploit, its payload, and the malware that it downloads.  It turns out that the whole attack just steals World of Warcraft passwords, which would have been nice to find out 4 hours ago when Ryan posted it, but I was having fun in IDA Pro instead of Twitter-land and pagination is disabled on the website and I missed it.

Anyway, here is a quick walkthrough:

  1. The flash.swf file exploits an unpatched vulnerability in Flash (UPDATE @ 20080529: It turns out that it was not an unpatched vulnerability, but a vulnerability that was fixed in the Flash update released on April 8th)
  2. The exploit payload uses familiar techniques to lookup API functions by a 32-bit hash value, and uses URLMON.DLL to download an executable to C:\6123t.exe and runs it.
  3. The downloaded executable disables Kaspersky Anti-Virus (what, they don’t have any others in China?) extracts a UPX-packed DLL (Ow.dll) from its resources segment and loads it as a keyboard hook DLL.
  4. The keyboard hook targets World Of Warcraft and uploads captured information to the attacker’s server disguised as HTTP requests.

Overall, nothing too complicated, but there are some funny bits where the downloaded executable calls a ton of GDI functions to retrieve various values and does nothing with the results (am I missing something here?):

CODE:00401714 push 0 ; dwFlags
CODE:00401716 push 0 ; lpSig
CODE:00401718 push 0 ; hdc
CODE:0040171A call GetTextCharsetInfo
CODE:0040171F push 0 ; hdc
CODE:00401721 call GetFontLanguageInfo
CODE:00401726 call GetDoubleClickTime
CODE:0040172B push 0 ; bPrevious
CODE:0040172D push 0 ; hCtl
CODE:0040172F push 0 ; hDlg
CODE:00401731 call GetNextDlgTabItem
CODE:00401736 push 0 ; color
CODE:00401738 push 0 ; hdc
CODE:0040173A call GetNearestColor

Still 20k sites were compromised, a reliable Flash zero day exploit was burned, and the threatcon was raised to steal WoW passwords? I know that the size of the WoW economy rivals many nations, but I still find it somewhat strange.

UPDATE @ 20080528: The Adobe PSIRT is now reporting that the vulnerability is not zero-day, but is in fact a different exploit for the recent vulnerability reported by Mark Dowd.  The exploit that I looked at appeared somewhat different in structure from Dowd’s, but it does use the same corrupt DefineSceneAndFrameLabelData tags and DoABC ActionScript bytecode tags.  It looks like I jumped the gun on this one and it is actually just a different exploit for the same vulnerability.  I have also just found a much more thorough analysis and description of the same exploit that I was looking at on the ThreatExpert blog.


  1. Hi, it might be good to highlight that using current software seems to protect against any risk, even if those two Chinese servers had not already been shut down by the time the story appeared.

    (The “20,000 domains” were about an HTML injection which pointed to the servers in China which temporarily hosted the malformed SWF.)

    I appreciate the update, but could we highlight the need to use current software…?

    tx, jd/adobe

  2. @John Dowdell

    Hi John, thanks for the comment and update. I downloaded the attack from one of the malware sites tuesday afternoon, so they were at least up at that time.

    I wholeheartedly agree with the need to run current software and make sure that it is easy for users to do so. If YouTube asked users to click ‘ok’ to have flash self-update to the latest version, I’m sure the vast majority of users would be upgraded pretty quickly. How about it, YouTube/Google?

  3. anonemouse says:

    It’s been a while since I’ve done any hardcore RE’ing, but I do remember seeing lots of samples with random GDI function calls. I believe they’re meant to ferret out sandboxing, since a sandbox that implements only a subset of the Windows API probably wouldn’t bother with GDI.

    Just a hunch though.

  4. anonemouse says:

    Also, I have to disagree with you on the Youtube Flash NAC idea. What makes Youtube trustworthy? Do we really want to train users to trust a pop-up on a website telling them to ‘download an update here’? How should they know to trust youtube.com and not yutube.com?

  5. @anonemouse

    Re: GDI, I think you are right about that. I submitted the sample to an online sandbox test and it came back with a clean bill of health (Not malware, go ahead and run it!).

    Re: Youtube Flash, I would assume that a well written feature would use signed updates from Adobe. Any website can get the remote flash version, so they could just say, “click this button, which links to https://www.adobe.com/go/getflash” to update to the latest Flash. But Flash already allows some sort of local file writing after the user clicks ‘OK’, install AIR for an example of this. However, you are right that perhaps training users to click somewhere to “update” their software could be a dangerous precedent to set, but with a signature check and proper UI design, it could work I think.


  1. [...] First up is Dino Dai Zovi’s walkthrough: [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 43 other followers

%d bloggers like this: