iRules: Content Scrub rule for the Adobe Flash Exploit

After reading most of what's available on the Adobe Zero Day Exploit, and getting an idea of how it propagates (Flash and JavaScript inserted via an SQL injection attack), I turned to iRules guru Colin for some help crafting an iRule that might stop a site from serving up infected content to a user. This is particularly helpful for those who are running a BIG-IP but who aren't running a web application firewall like ASM (Application Security Manager) and may have been inadvertently infected.

After looking through the screen capture of some JavaScript that attempts to load the malware from one of several sites, it appears that scanning the response for one of the malicious domains would be the easiest way to catch a page that's been infected with this code. (This is similar to the way in which we can use iRules to prevent sensitive data from being served up to users.)

From another blog on the subject

Google search reports approximately 20,000 web pages (not necessarily distinct servers or domains) injected with a script redirecting users to this malicious site. A wide variety of legitimate third-party sites appear to be affected. The code then redirects users to sites hosting malicious Flash files exploiting this issue. [emphasis added]

Dancho Danchev's most recently updated post on the exploit suggests blocking the following domains known to be hosting the malicious Flash files (as of 5/28):

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

Blocking the domains is great for your internal users, but because the exploit is run from the client's browser this doesn't seem to be a great help for your external customers, particularly if you happen to be a Web 2.0 site. What we want to do is (a) find out if a page references one of the domains hosting malicious content (which would indicate the page is likely infected) and then (b) do something about it.

In this case, we're just going to tell the user we can't deliver the page and write a log message to get the attention of the security guys.

when HTTP_RESPONSE {
  HTTP::collect
}

when HTTP_RESPONSE_DATA {
  switch -glob [string tolower [HTTP::payload]] {
    "*0novel.com*" -
     "*dota11.cn*" -
     "*wuqing17173.cn*" -
     "*woai117.cn*" -
     "*guccime.net*" -
    "*play0nlnie.com*" {
      HTTP::respond 200 content "The server is currently unable to serve the requested content. Please try again later."
      log local0. "Adobe Flash exploit infected page found. Server IP: [IP::server_addr]"
    }
  }
  HTTP::release
}

I've not included every domain in the iRule, but you get the picture. If we detect a malicious domain in the page, we're not going to serve that page. Period.

This won't stop the original SQL injection attack that infects your site, that'd be handled by a different iRule or product (BIG-IP ASM. If you're running a BIG-IP and don't have this product module, you should seriously consider it as it can prevent SQL injection attacks like the one being used to infect sites with this exploit). What this will do is tell you if you're one of the sites currently infected, and prevent your site from passing it on to your users.

Because despite what our mothers told us, it isn't always nice to share.

Imbibing: Coffee

Thanks again to Colin for applying his iRule ninja skillz to this problem.