Malicious space on MySpace

Last Wednesday (June 13th), SecureBrowsing has alerted us on a “cute” MySpace profile being used as a malicious code attack vector. This is not the first catch by SecureBrowsing, but to see one on MySpace this late into 2007 was a bit of a surprise.

We have been talking about the risks of Web2.0 in terms of user contributed content (actually since our Q3-2006 trends report), and have been watching the space for the upraise (remember Wikipedia) and downfall (sites started paying more attention to the stuff they publish that was directly contributed by users) of malicious code on such sites.

The security violations were found on two different profiles, and contained two different malicious attacks (see below) – the first picture shows a QuickTime exploit that contained a Trojan Downloader, and the second one is a WMA exploit containing – a Trojan Downloader…

MySpace001

MySpace002

The MySpace abuse team was fairly quick to take down the malicious code (in less than 24 hours) – good job guys!

Obviously our customers have been protected from these kind of attacks for a long time, and can fearlessly browse the internet, as well as SecureBrowsing users who got alerted on the specific profile that contained the malicious code in real-time and without the need to update or look up in some kind of database…

Have something to hide? make a lot of noise about it!

There has been a lot of noise on the web over the past few days in regard to the MPack toolkit being used in the Italy region. Everyone has been talking about it vigorously: From the washington post, WebSense, TrendMicro, so eventually even Slashdot picked up on it.

The interesting thing is, no one is actually talking about what MPack can do. They are all saying “oh my god, they are attacking Italian websites by the masses”, “iframes are inserted to benign sites and users are getting infected”, and so on, and so forth. Great. Have anyone bothered to mention the more acute risks of MPack? besides the obfuscated code (a long time de-facto standard in web-bourne threats), and specific exploit delivery (black hat “customer service”), MPack is tracking users IPs and will actually refuse to provide malicious code to an IP who already got it (evasive in order to minimize code exposure).

And on a final note – It’s great to see all the media circling the issue, but please – don’t leave the reader with a block of obfuscated code to look at – show what’s behind it (obfuscated code is so 2006…).

For our FULL analysis of the real threats in MPack (not just the toolkit, but the methodology being used on all toolkits like it) see our Q2 Trend report, and take a look at the Malicious Page of the Month of May 2007 (as I said – MPack is just ONE toolkit, there are more like it, and they all use the same evasive attacks techniques).

Malicious code, exploit vectors or top-programmer job?

What would you say if you saw one of these code snippets in a website you browse to:

dim tass

Set tass = CreateObject(“CnsHelper.CH”)

If IsObject(tass) then

HasCns = true

else

HasCns = false

end if

or:

function winIE5upPlyrDetect(){
var playerAxObj;
var iectlAxObj;
try{
iectlAxObj = new ActiveXObject(“Shell.Explorer”);
}
catch(e){
}
try{

or:

var fs = new ActiveXObject(“Scripting.FileSystemObject”);

try {
//open file, 8=appends to file, true=will create file if doesn’t already exist
var a = fs.OpenTextFile( fileUri, 8, true );
a.Writeline( text );
a.Close();
}

You are probably looking at this and thinking, “ok, what is he going to show us now – some newfangled attack vector, spyware drive-by installer, local system access…”. Guess again.

Sample #1 is coming from Yahoo.com (more specifically http://cn.zs.yahoo.com/func.vbs), and yes – you saw that correctly, is creating the CnsHelper.CH object – an object that multiple sources consider an unwanted AdWare application (see: http://www.trendmicro.com/vinfo/grayware/ve_graywareDetails.asp?GNAME=ADW%5FCNSMIN%2EA, http://www.spynomore.com/bho-hijacker-toolbar-cnsmin.htm, http://www.pestpatrol.com/spywarecenter/pest.aspx?id=453072511, …)

Sample  #2 is unreal. Well, actually it’s real. Real.com. (http://uk.real.com/js/playerdetection.js?rev=9507). This is how a developer tests to see if the browser looking at the page is Internet Explorer…

Sample #3 is the all powerful walmart.com (http://www.walmart.com/kiosk/js/log.js) which, and I’m quoting the code comment right before the function (sit tight):

/**
* Opens a local file and appends a string to it.
* Returns boolean indicating succes of opening/writing.
*/
Right. When browsing the web…

You do the math. Just think now how hard it is to work in such a demanding environment, where the good guys do not always follow the good guys coding manual (what? Didn’t you all get the memo?).

Till next time,

Google’s “Ghost in a Browser”, WebSense, and more…

First things first – big Kudos to Google for their research paper. We at MCRC have found it to be very reassuring for us – now we know we are not the only nuts out there running around in the security arena and wondering how come nobody sees the imminent threats described in the paper.

I’ve recently ran across a blog post on the websense site (http://www.websense.com/securitylabs/blog/blog.php?BlogID=125) which related to the same research paper, and mentioned that the “bad” news is that it does not cover a lot of other attacks out there.

Right, but to completely correct… When you look at the web security field, most of the other attacks mentioned by our colleagues at WebSense, are still web attacks. Having email/IM lure you to click on a link is a web attack, hacking a legitimate site to have malicious code linked/injected into it is a web attack, typos in domain names are web attacks, etc…

My main point is – does not matter where do you get to the malicious code, it’s still malicious code. And if your security solution can handle it, you are protected. End of story.

We have been seeing a lot of various new trends during the past 3 month at MCRC while researching and analyzing attacks, and the common ground for all of them was still the same, no matter where they came from. sponsored links, hacked sites, phishing emails, IM lures, as long as the true attack vector involves the web channel – it’s a web threat and is definitely covered in the Google paper.

Look for our upcoming Q2 trend report where we’ll cover a LOT of interesting trends as I mentioned above… Really cool stuff…

Tying it all up – explosive exploits…

The funniest thing happened yesterday – at a watercooler conversation our CTO informs us of a site that uses techniques from almost all of our trend reports (which means we are right as usual…). The interesting part was that it was one of those “iframe” sites that give you a small iframe html code to put in your website and they’ll pay you “per-infection” (is this thing copyrighted/patented yet??? ;-) ).

Old news…

But – after looking into the code he figured that this is pretty nasty stuff that basically BYPASSES every major security vendor’s detection technology (except for ours of course – and no – it’s not a marketing spin…).

A few hours later we pushed out an “Extra” version of the “Malicious Page of the Month” dubbed “Malicious Page Under Benchmark” to show how the most modern names in security can’t handle a bunch of hackers that publicly spread their exploits.

Check it out at: http://www.finjan.com/content.aspx?id=1367

Be safe…