Nine Ball attack strikes 40,000 Web sites

http://www.networkworld.com/news/2009/061609-nineball-websense-attack.html?hpg1=bn

 

This is another in the evolution of redirect attacks that show the sophistication of the malware community.

From the networkworld.com article:

Early examples of rejecting a repeat visitor were seen in Google redirect exploits two years ago. The cached files had a random set of characters appended to them:

​

If the user re-connected via Google, or attempted to get the file again during the same browser session, an error displayed:

​

Logging off/back on permitted the reconnection and different characters were appended to the files. Finjan had an article explaining this:

Finjan’s Latest Web Security Trends Report Reveals New Genre of Evasive Attacks
http://www.finjan.com/Pressrelease.aspx?id=1527&PressLan=1230&lan=3

networkworld.com again:

Exploits from several years ago checked for the version of IE/Windows by embedding code directly in the web page. Depending on the return, a specific IE exploit was delivered:

Code:

if (IE_vers.indexOf('Windows 95') != -1) return "95"
     else if (IE_vers.indexOf('Windows NT 4') != -1) return "NT"
     else if (IE_vers.indexOf('Win 9x 4.9') != -1) return "ME"
     else if (IE_vers.indexOf('Windows 98') != -1) return "98"
     else if (IE_vers.indexOf('Windows NT 5.0') != -1) return "2K"
     else if (IE_vers.indexOf('Windows NT 5.1') != -1) return "XP"
     else if (IE_vers.indexOf('Windows NT 5.2') != -1) return "2K3"

In today's exploits, the code resides on the malware server. In order to attract a larger pool of victims, code checks for the browser being used:

• If IE, the version number is also identified and various browser exploits are served up. Most are old, long since patched IE6 vulnerabilities.
  
  
• If non-IE browsers, plug-in vulnerabilities are used because no exploits in the wild target Opera or Firefox. PDF and flash are the most common, and you can understand why, since so many people use those products.

Sometimes a PDF and Flash exploit will target IE and the script code will show ActiveX:

Code:

obj = new [COLOR="DarkRed"][B]ActiveXObject[/B][/COLOR]([COLOR="DarkRed"][B]PDF[/B][/COLOR][i]);

obj = new [COLOR="DarkRed"][B]ActiveXObject[/B][/COLOR]("[COLOR="DarkRed"][B]ShockwaveFlash[/B][/COLOR].ShockwaveFlash");

Otherwise, the code searches for available plug-ins which Opera and Firefox use:

Code:

<script>
name = navigator.[COLOR="DarkRed"][B]plugins[/B][/COLOR][i].name;

if((name.indexOf("[COLOR="DarkRed"][B]Adobe Acrobat[/B][/COLOR]") 
document.write('<iframe src="[COLOR="DarkRed"][B]pdf.pdf[/B][/COLOR]"></iframe>');
</script>

From this we can deduce that disabling scripting and plugins prevents these exploits from succeeding. Here, a redirect to a site to download the PDF file results in a blank window:

​

Depending on other browser configurations, sometimes a download prompt will display:

​

But the remote code execution (drive-by) aspect of the exploit is nullified.

That this is a plug-in and not a browser exploit can be shown by what the firewall catches if the exploit gets that far. Code in the PDF file uses the Reader to connect out for malware:

​

As the networkworld.com article points out, the exploits target the browser (meaning IE) or plugins for the other browsers. Getting the word out that proper configuration of the browser defeats these exploits will reduce the number of potential victims joining a botnet!

----
rich