Category Archives: Finjan

The impact of just 5 random letters…

Posted on by
Reply

We have been watching in amazement the impact our latest Malicious Page of the Month had on the industry and media.
From coverage at Fox Business News, and the Washington Post, all the way to the more “traditional” security outlets such as SecurityFocus, SC Magazine and bloggers such as Dancho Danchev.

The scary thing is the non-media related impact – we are still seeing a tremendous amount of domains (and sites) that are still compromised. Just a quick preview of the ongoing research we are putting into this – we are getting closer to getting to the root (no pun intended) cause of the problem that seems to affect Linux webservers (and this time it may not be a cPanel related issue for a change).

Looking forward to posting an update soon as we make progress in cracking this one.

And the winner for “top virus” of 2007 is…

Posted on by
Reply

Not a virus. Not even a malware. Neither is the runner up… It’s the method of how malware is populated.

According to a report, the most common malware attack in 2007 is the notorious IFRAME.

top_virus_2007

On our monthly and quarterly reports we provided more in-depth analysis of such top-ranking IFRAME and obfuscated code.
In Finjan’s terminology, the top-ranked virus IFRAME is not a malware or a virus, it’s more like how criminals are directing users’ browsers to a malware. Interestingly enough – the runner-up is “Mal/ObfJS” – Obfuscated javascript, again no a virus or malware but a simple technique to hide exploits from signature matching inspection.

How come? Well, remember that signature-based solutions are in a dire need to be able to stop the more common techniques employed by attackers (we have actually started to report on them during 2006), since the detection technology is limited in detecting the obfuscation and evasive techniques – typically signaturing the de-obfuscating portions of the script.

This has led to the recent reports of false-positives by multiple AV vendors lately, as active-content is becoming more and more complicated, and the ways to express an action in interpreted code are very complex – meaning that signatures in this realm are almost obsolete (you can see the honorary mention of the “DF” function (Mal/FunDF) in the 10th place, which is a signature on a specific de-obfuscating function – again, no mention of any malicious action taken by it, it’s just that it had it’s 15 minutes of fame when it was used by toolkits to deliver actual malicious code…)

Looking forward to 2008 I really hope that the industry as a whole will not be lagging behind the attack vectors as it did in 2007, and new and improved engines would enable end-users (especially consumers who do not benefit from the more sophisticated solutions offered to enterprises) to have better protection when using the internet.

I know what my new-year resolutions are – do you?

New Orkut worm takes us back in the wayback machine

Posted on by
Reply

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. Alas, I was greeted with the good-ole’ “packed” obfuscation (see pdp’s post in it):

orkut001

This brings us back to our August post on obfuscators (that are obviously easily detected and processed by us) which talked about the “packed” strand of JS obfuscation…

Hope that the industry will bring in something more exciting in the next wave of malicious code ;-)

IFRAME is a security risk???

Posted on by
Reply

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

Scrutinizing the mere existence of an IFRAME element (as we all remember – a standard HTML element), sounds pretty bad. Now, we were asking ourselves, how come this has become a security threat? The answer is simpler and more alarming that you might have thought – we are shooting the messenger (excuse the pun…). Simply because an IFRAME element exists (or is dynamically created) in a page, does not mean that it contains malicious content. But since old-tech security products are having a hard time detecting web-bourne crimeware and malware these days (dynamic code obfuscation, evasive techniques, etc…), they set their radars to shoot down the iframe elements. What’s next? Script tags…

Just to set things straight – the security model we should be looking at should detect actual malicious code in real-time. The source (URL, Domain, etc…) should not matter, and neither should  the looks (iframe, packed code, etc…). By analyzing the true intent of the code, one can be certain that the security policy sought after is really implemented.

That’s it for this week’s rants-and-raves, see you next week in the Greek ICT conference in Athens…

Playing with obfuscators – teaching an old dog new tricks…

Posted on by
Reply

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

So here are the basics – index.php is a highly malicious page being served by a crimeware toolkit somewhere (see the MPOM for the specifics). It contains a de-obfuscation function (df) and a call to it with a long parameter that looks like garbage, but then open up to some nice exploit code.

Running it through our friends at VirusTotal – here is what comes up (not a competitive analysis, no one is responsible for the results, etc, etc…):

Playing002

OK, that’s pretty decent – 15 out of 32 (database unreachable is not a malicious detection – on previous runs it came up with nothing)… Now, wondering what makes these things really tick, let’s neutralize the malicious part of the file. Let’s just completely make it useless – and pass an empty string to the de-obfuscating function. This should obviously not be blocked, since the end-result is non-malicious, and these obfuscators are being used for harmless code as well.

Playing001

Aha! Someone does not like this coding… So what really happened is that the de-obfuscation function is the one being scrutinized, and not the malicious code that end up running on the machine. So to our final step in the game – play a bit with the function, make it look nice and just change a couple of parameter names. No functionality change, just a bit of cosmetics (function name change to asda, 2 parameters changed names, code got through tidy…):

Playing004

Conclusion – don’t believe everything you see… it may actually not be that bad… just make sure you take a close look at what’s really going on under the hood