I just love it how old news are recycled with a bit of a flare when they become relevant again. The latest Orkut worm reports talk about the technique that the worm writer has used to distribute its code. Quoting from the original article above: “It then downloads and executes a heavily obfuscated JavaScript”… looking at the code, I was expecting some whiz-bang brand-spankin-new cool-as-ice JS that you can’t even watch without eye protection.

There is nothing new in traffic selling sites; in fact this growing business is almost as old as search engines. This huge market was adopted by hackers in order to transform desktops and sites under their control into cash making zombies. Sites that run crimeware-affiliation-networks are nothing new and we have been covering these for a long time both in this blog, as well as in our regular publications (Malicious page of the month, and the Trends Reports), but we just had to highlight this one...

Rateitall.com has a permanent XSS hole which was used by criminal group(s?) to insert malicious code to the popular rating site.

We have started seeing malware being hosted on more "legitimate" hosting sites that usually provide an easy SMB hosting for a low monthly fee.

Spyware Sucks published a post about a site hijacked by a malicious advertisement. Once loaded, this advertisement redirects the browser (through 3 other domains) to "malware-scan.com", a notorious fake anti-malware program.

Lately a couple of research papers related to the Flash cross-domain ability have been published.
A) Cross-Domain Data Access via Flash [CDDAF] Reference by Cenarius (available in Russia only :)
B) Cross Domain Hole Caused By Google Docs by Billy (BK) RiosA) Cross-Domain Data Access via Flash [CDDAF] Reference by Cenarius (available in russian only :)
B) Cross Domain Hole Caused By Google Docs by Billy (BK) Rios

Whoops. It happens even to the best of the best. You try to close all the cross-site-scripting (XSS) holes in all of the dynamic pages distributed all over your domain, but forget the main page...

Ok, I have just read the latest in “IFRAME Security” articles and had to write something about it. While going through my usual RSS feeds, I stumbled onto this article, which tries to summarize why “iframes are a security risk”. Not to pick on the specific article, but this is not the first time that I have seen this approach. More notably, we have lately been faced with a barrage of sites that are detected by some AV engines as having a virus on them, when the detection is usually named “xxx-IFRAME-xxx”.

Usually a week or two after MCRC detects a malicious domain, webmasters blogs are filling with complains and “surprised faces” about the existence of code they didn’t author in their web site pages.

So our Malicious Page of the Month for September is out now. Going over the details of the document, I wanted to re-visit an old habit I had back in the days of putting code to the test – especially when the code in subject is simple, and has been signature to hell by every security vendor already… You guessed it right – code obfuscation (or more precisely – the de-obfuscating function).

Coincidence or just sheer luck, but I just happened to stumble upon this article announcing that Google has come up with a widget that serves advertisements, and quoting the source: “A variety of web technologies can be used to create the ad, including Flash and HTML to author it, and RSS, images, video, and audio among other media times to provide the content”.

When we here at the MCRC are publishing our quarterly trends reports (http://www.finjan.com/Content.aspx?id=827), we are always facing the possibility that what we have been working on and predicting that would become the next issue with web security, isn’t really going to happen.

Dangling pointers are pointers that do not point to a valid object of the appropriate type, or to a distinguished null pointer value in languages which support this. It can be caused when an object is deleted or de-allocated, without modifying the value of the pointer, so that the pointer still points to the memory location of the de-allocated memory.

The Storm Worm guys are still playing mind games (a.k.a Social Engineering). In his first book, “The Art of Deception”, Kevin Mitnick introduces several methods social engineers use in their attacks. One of the simplest ways is to directly ask the victim. It appears that most people will naively give away information, or just do the things the attacker asks them to do.

The Storm Worm criminals continue to play games. After changing from e-cards to photos and fake YouTube links, they are now trying to convince their victims to download fake codec in order to “play a video”.

This is a bit off-the-beaten-path of this blog's usual in-depth hardcore security posts. I was going through some of the support related emails that have some relevance to the areas I'm responsible for, and found a pretty interesting correspondence between an avid blog reader (for privacy I'm not going to mention his/her name), and one of our support personnel. The thing that caught my attention was a very alarming subject line - "What are you trying to do - infect me with a Trojan?".

Legitimate packers and encoders have a long history of malicious use. A great example for that is UPX, which is one of the most used executable packers by malicious executables. This trend now also takes place in the web environment.

One of my favorite’s code obfuscation tools is Dean Edwards' js packer, unfortunately it seems that many attackers share this view with me and facilitate the tool to "pack" their code, aiming to bypass security products.

If you have an email account, you probably received at least one of those e-cards with links to nasty websites, in the last couple of months.

Or how a contact may get too close for comfort... It's finally here. August 14th, and we are finally in liberty to talk about the vulnerability in the Vista Sidebar Contacts Widget.

So it's been a really hectic couple of days here in Vegas. We are here (myself and 2 members of MCRC - Aviv & Amir), running between presentations, and handling booth/media traffic.

Are you a music fan? The cyber criminals bet you are. This is why they now hack more and more music groups fan/official web sites, and inject malicious crimeware. Our Q2 2007 Trend Report shows examples of two of those web sites that were hacked by criminals. The following are examples of two more sites.

Do you think that tons of media coverage is enough to wipe out a malicious website? If your answer was yes, think again.

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.

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 washongton post, WebSense, TrendMicro, so eventually even Slashdot picked up on it.

How to spread malicious code without being caught? Or should we say, taking advantage of not-so-smart bad guys…

In the tradition of our previous trend reports, MCRC are proud to announce the Q2 Trend Report. This report is dynamite! We are covering advanced techniques used by attackers to hide their code

According to Sans’ diary entry, the malicious site google-c[REMOVED]r.com is masquerading as a Google service. We have actually monitored this trend for quite a while, and have encountered more malicious sites which use this same behavior. The following are some examples we have came across during our research.

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

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.

Mig[REMOVED].com is a biggest news site targeting Russian speakers in Israel.

Walla mail is an Israeli web mail provider

Examining dynamic code obfuscation is fun. You take a strange looking script that was found in the wild, analyze it with your home-made debugging tools, and a few minutes later you find yourself staring at a nice looking malicious exploit. This was my assumption when I first observed shwab.info. This site is using comment spamming and other black-hat SEO techniques to persuade users into visiting its malicious pages. One of the malicious pages is using a very simple dynamic obfuscation script:

The iframe (a-z*)!.biz (a-z)!.com guys are everywhere, and they are not missing a 0-day since RDS.

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??? ;-) ).

We are seeing situations where security vendors, when unable to handle code analysis, rely on “scrubbing” scripts and replacing “suspicious” functions with bogus function names. Provided that the security appliance also injects the interpretation of these bogus functions, the vendor is basically assuming security responsibility at the client side, thus “admitting” their technology could not cope with the detection and blocking tasks at the gateway.

We have just finished working on a new monthly released paper that will focus on a new "page" (dubbed "Malicious Page of the Month"). This month we have analyzed an AJAX attack vector found by our labs in the wild.

According to SecurityFocus: "Attackers may exploit this via a malicious page to spoof the contents and origin of a page that the victim may trust. This vulnerability may be useful in phishing or other attacks that rely on content spoofing."

Today I encountered a site (http://life.[REMOVED].info/css3/) that contains what seems as a new/different version of the web attacker toolkit. As in the said toolkit the first page (which is, of course, home encoded) checks for the client browser, installed plugins and patches. Following the client identification the page is being redirected to an appropriate exploit page.

Finally, an MCRC blog where you can read what our MCRC members are working on, new developments in web security and general blurbs.