Java-based Web Attack Installs Hard-to-detect Malware in RAM

The pcworld.com article cited above, quoting from the original research by Kaspersky, omitted an important fact (not unusual for the mainstream media): what type of code initiated the attack? I didn't have time until this evening to poke around and find some other information. I came across the original Kaspersky article; a few important points:

A unique 'fileless' bot attacks news site visitors
http://www.securelist.com/en/blog/687/A_unique_fileless_bot_attacks_news_site_visitors

(I've bolded the two statements above)

The pcworld.com article mentions neither "javascript" nor "i-frame." Why not? The initial attack code is the clue to understanding the complete exploit.

So, some questions are obvious:

1) Was javascript necessary for the users who were infected at those sites with the malicious Adfox Teasers? And, wouldn't white listing javascript per site have prevented the attack code from even starting, meaning no redirect to the site with the Java exploit?

2) Wouldn't having i-frames disabled, or white listed, have also stopped the attack at the gate?

No real damage was done until the 'Bot' learned that the compromised computer had e-banking, since the purpose of the attack was to find such computers and download to disk a banking trojan. That part of the attack is surely nullified with proper execution prevention in place.


----
rich

 

It's not really about whether or not we would be effected, it's just interesting to see how attacks are evolving. If everyone whitelisted Javascript I'm sure we would just see more whitelisted sites hacked or some other method of delivering content used.

 

You miss my point.

I've complained for years that the mainstream media (like pcworld.com) selectively quote from researchers, and in most cases, leave the reader without the complete story (in this case, the type of attack code.)

It may be interesting to see how attacks are evolving, but one needs all of the details of the attack in order to decide for her/himself what preventative measures to take.

By the way, malware running in Memory isn't really new:

CodeRed Worm
http://www.symantec.com/security_response/writeup.jsp?docid=2001-071911-5755-99&tabid=2

'Slammer' attacks may become way of life for Net
http://news.cnet.com/2009-1001-983540.html

----
rich

 

No, it's not new, but it's not common. Reporting that an iframe used javascript seems kind of silly, that's typical and unimportant. The article focused on what made the attack different.

I guess details would have been nice but I don't think the purpose of teh article was to break down thsi specific attack but to point to the actual interesting part of it.

 

That's true. But, there's a reason why millions of Windows systems get infected - unware users.

So, is JavaScript needed? Do most people know what the heck a website is made of? I got my doubts about that. They just see an "interface". They want that "interface" to be functional. That's it.

Iframes? Same deal. How can anyone block/allow something they don't know it exists?

Cybercriminals are counting on the fact the millions of users are unware of things like that. Which is why their tricks work.

And, like Hungry Man said, and I agree, if everyone knew this and whitelisted Javascript, etc, then you'd see way more legitimate websites getting compromised, that's for sure. Then the whitelisting approach would be no longer as effective as it is nowadays.

If whitelisting works nowadays for JavaScript, etc., it's only because of security through obscurity - millions of people aren't aware of such things and that they can whitelist them, and therefore cybercriminals don't have to adjust their methods either.

 

You folks are missing my point.

I have no interest in what someone does as far as securing her/his system, nor in what anyone understands about how web pages work, nor in that "Cybercriminals are counting on the fact the millions of users are unware of things like that."

That is a user's problem.

The point I made is, that when I read an article that describes an attack, I want all of the information about that attack. The pcworld.com article didn't do that, which relegates it to the dustbin of sloppy, inadequate journalism.

Better just to link directly to the Kaspersky analysis and let the reader get all of the facts.

I did not state that anyone should disable javascript. I only asked rhetorically if doing such in this case would prevent the attack from even starting.

To do so is an individual decision, and shouldn't bother anyone, it seems to me.

The article (and many others) gave the obligatory preventative measures (keep software updated, use an uptodate Anti-virus program). Nothing wrong with that, but with all of the facts revealed, the reader realizes that it's possible to stop the attack at the Adfox Teaser stage.

(In a previous post, m00nbl00d mentioned that AdBlock Plus/other would block it.)


"Just the facts," please!


----
rich

 

OK...

The PC World article does link to the orginal (Kaspersky's article). Which is why I don't get all the fuss about it.

PC World is not a security blog or something like that. It's a website that any ordinary people may actually visit. Don't you think for a second any such people would lose interest in the article if they started to talk about that kind of technical stuff?

No one said you stated people should disable JavaScript.

In one of my previous posts, I did mention that the attack came from an hijacked advertising network, and that something like AdBlock Plus/other would block it.

These are facts.

For instance, would it make any difference if an exploit used obfuscated JavaScript code, and PC World mentioned it? For millions of users it would be like Uh .

And, the PC World article does mention the following: Instead, it was served to their visitors through banners displayed by a third-party advertising service called AdFox.

Maybe they should have mentioned that users could use something like Adblock Pus... but then again, they may feel the same as you: I have no interest in what someone does as far as securing her/his system, nor in what anyone understands about how web pages work, nor in that "Cybercriminals are counting on the fact the millions of users are unware of things like that."

 

Thanks - I had that in my notes, and meant to mention that. I edited my post to include it. (Should pcworld.com have included that as a preventative measure?)

pcworld.com doesn't have to go into a detailed analysis. But mentioning that javascript starts the exploit in the Ad banners is no more technical than mentioning the Java exploit, as it does:

I would guess that ordinary people would be more aware of the term "javascript" than "rogue DLL (dynamic-link library)."

They could have included that the Ad banner's code consisted of javascript that redirected the user to the site with the Java exploit. That would make it clear what the threat of the Ad banner is, just in the way it describes the DLL loading into the Java process.


----
rich

 

I get that you want the "in-depth" analysis. I want it too. But that's what the whitepaper is for. PC-World has to balance getting the information out of there and making it accessible. That means keeping it short.

I agree that it would not really hurt to say it was loaded up by Javascript, I just think that the focus of the article had nothing to do with the exploit in teh wild itself, rather the method.

Journalism withstanding, it's an interesting exploit.

 

Maybe as one of the preventive measures. It wouldn't hurt mentioning it. Of course, Internet Explorer 9 tracking protection lists should also be mentioned. Some of the lists include Fanboy's (-https://secure.fanboy.co.nz/adblock/ie/fanboy-noele.tpl). There's also a list for Opera, and I believe an addon as well.

These are little measures that an ordinary user could handle very well, IMO.

My take is that they wouldn't be familiar with any. To be honest, I didn't pay much attention to the fact they mentioned DLL. I'd exchange DLL with malicious file.

I would, for instance, change this: The Java exploit's payload consisted of a rogue DLL (dynamic-link library) that was loaded and attached on the fly to the legitimate Java process.

into: The Java's exploited vulnerability allowed to load and attach the malicious file to the Java program itself.

I think it would be more understandable like that. Maybe I'm wrong. lol

I agree that if they mentioned that the compromised ad redirected them to a malicious website hosting the Java's exploit, then users would understand better the true danger of ads.

Not sure if mentioning javascript (or DLL, etc) would be helpful to understand. Maybe users would just ignore it all together, if they started to read something they don't really know what it is about.

-edit-

But yes, if they mentioned "rogue DLL", etc., they could just as well mention the JavaScript part. I wouldn't use either of the terms, though.

 

CodeRed and Slammer were internet worms and because of their small size, they can fit inside single packet sent over UDP or TCP, then buffer overflows, then their code execute and reside in memory and that's why they didn't need to be written to disk.

So, they're both not executable files or dll files per se but like shellcodes running in memory.

While this particular malware's dll can be of any size and not limited by shellcode size limitation. It appears like the way the meterpreter shell dll is loaded. Not in the usual means on which the dll is written to disk first then loaded by the native windows loader but through reflective dll injection, hence, AV's and even AE/HIPS/SRP/Applocker have a hard time detecting or stopping this.
-http://www.harmonysecurity.com/files/HS-P005_ReflectiveDllInjection.pdf
-http://www.darkoperator.com/blog/2009/7/14/meterpreter-stealthier-than-ever.html

 

I'm pretty sure I can't run OpenOffice without it. I always keep Java up to date.

 

Huh. Looks like you're right, I had no idea.
-http://www.openoffice.org/download/common/java.html

 

There was some talk of LibreOffice releasing a Java-free version at one time. Unfortunately, the way LibO is going at the moment I will not be downloading it again for some time (if ever).