Errors Not Slowing Down Gumblar Attacks

As we reported a few weeks ago, a new wave of Gumblar attacks began in early October. More recently, there's been some discussion about the new Gumbar attacks breaking WordPress and certain other PHP websites. The error results from a poorly modified file to include the javascript. An example of the error is below:

Fatal error:  Cannot redeclare bm7b4() (previously declared in
/homepages/12/d90203023/htdocs/blog/index.php(1) : eval()'d code:1) in
/homepages/12/d90203023/htdocs/blog/wp-config.php(1) : eval()'d code on line 1

The actual path and redeclare function varies. The bug appears to be a typo of an l (lowercase L) as opposed to a 1 (numeric one). The script tests for the existence of "$blah1" (numeric 1) variable, but creates "$blahl" (lowercase L).

In other cases, an error similar to the following can result (again, path will vary):

Warning:  base64_decode() has been disabled for security reasons in /home/balasmee/public_html/images/image.php on line 1

If you search Google for either error, there will be tens of thousands of hits. Many of these are just forums or blogs discussing the error, many are the actual error itself. Unfortunately though, these errors are having no impact on the viability of the latest Gumblar attacks. Here's why.

There are two sets of compromises involved with the current round of attacks. The first involves compromised sites that are now acting as actual malware hosts. The second involves compromised sites injected with iframes that point to those malware hosts.

In a typical Web malware outbreak, there are only a few malware hosts. But because the Gumblar attackers have this botnet of backdoored websites at their disposal, there are now thousands of malware hosts. This makes stemming the flow of the attacks (i.e. shutting down the hosts) nearly impossible.

The fatal error occurs only on the compromised site that is acting as malware host. And that fatal error actually has a big upside - it at least alerts those particular site owners to the fact that their website has been compromised and hopefully they will at least take the necessary steps to properly secure their sites before bringing them back online. But it's almost a moot point. In thousands of other cases, the error doesn't occur and those backdoored sites continue to act as malware hosts.

In the second set of compromises, the attackers are injecting iframes that load the malware from the compromised hosts. (In some cases, the iframe injected site can also be acting as a malware host). The iframe is generally injected between the closing head tag and opening body tag of the html source. This causes it to be ignored by typical search engine spiders (hampering ready discovery of the compromised sites through SERPs) while still being easily rendered by the browsers. In other cases, the injection is done before the opening html tag, which again gets ignored by typical search indexers.

Because ScanSafe filters Web traffic in realtime on behalf of our customers, our data is reflective of actual user experience. And the data is sobering. The success of these latest Gumblar attacks is considerable - in October 2009, 28.8% of all ScanSafe Web malware blocks were the result of the latest Gumblar attacks - double the amount observed in the May 2009 outbreak of Gumblar. The latest run of Gumblar has been highly successful for the attckers, all because the malware itself is being hosted on thousands of other compromised sites.

ScanSafe STAT security researcher Gregg Conklin contributed to this report.