Exploit for recently-patched Java vulnerability is being integrated into exploit kits

From http://krebsonsecurity.com/2011/11/new-java-attack-rolled-into-exploit-kits/:

 

Since I refuse to disable Java as the author and some others suggest, I restrict my Java-required sites to the IE Restricted zone, slightly modified from its default settings to allow Java and ActiveX controls and Plugins, the latter of which are restricted to only what I have installed and enabled in the managed add-ons. I'm also using x64 IE with compatible x64 Java and Flash. Java permissions are disabled in the Internet zone.

 

Patching + EMET is all I need for something like this.

 

I thought the websites added in Restricted zone were forbidden to execute stuff?

And, you modified the Restricted zone to allow Java, etc? I'm scratching my head, and you're making it bleed...

The Restricted Sites Zone as the name implies, is to restrict, not to allow. If you want to allow Java, ActiveX and plugins, then you either allow them in the Internet zone or add the domains to the Trusted zone, leaving them blocked for the other zones.

Is there some logic I'm failing to understand? There's been a long time since I last used IE... so, give me some break, will ya...

 

Yes, the logic I use is that the Restricted zone is, as the name implies, more restrictive in other settings than the other zones, including Internet and Trusted. My logic is that although the Java is allowed, the site is restricted in those other areas that it wouldn't be in the Trusted or Internet zones. Hope this makes sense BTW, I don't place any other sites in the Restricted zone; I use it only for Java-required sites.

Nothing wrong with that, and I agree it works fine. I just take these extra steps in an attempt to please those in this forum who are extra paranoid cautious

 

OK. That makes sense, considering you got no other domains there.

 

Yes, the Enhanced Mitigation Experience Toolkit (EMET) HELPS prevent vulnerabilities in software from being
successfully exploited and is designed to work with any software, regardless of when it was written or by whom
it was written. However, some Software may be Incompatible with EMET due to the Risk that Some Applications rely
on exactly the behavior that the mitigations EMET blocks. SO EMET IS NOT INVINCIBLE.

The Enhanced Mitigation Experience Toolkit:
http://support.microsoft.com/kb/2458544


HKEY1952

 

Right, that's the key. For Java-required sites I use the Sites to Zone Assignment list in Group Policy, with a value of 4 to force them to the Restricted zone. I've already got the Internet zone and other IE policy settings set quite restrctively, so this already provides good, general purpose security for everything else. Of course this is augmented by all my other "built-in" security as well, with EMET thrown into the mix

 

The quote you posted isn't about EMET not being effected it's about EMET not being compatible with everything. It's entirely correct.

EMET isn't entirely effective though, not a single mitigation technique on it isn't bypassable on its own. Altogether it makes things quite a lot more difficult and many automated exploits that don't take it into account won't work. Of course some exploits aren't relevant to these mitigation techniques.

 

That is correct, so, EMET is Not Invincible, and, Any Incompatable Software is Not Protected by EMET, and therefore
Vulnerable to Exploit. However, in theory, EMET is next to impossible to penatrate.


EDIT: clarity


HKEY1952

 

No, the incompatible software is protect by EMET, it'll just crash and you'll be forced to remove EMET.dll.

 

Remove the .dll remove the protection.

\END


HKEY1952

 

The exploit is also ineffective against Chrome

 

Well that's odd. This isn't the first time we've seen Chrome stop Java exploits... with no real explanation.

Probably some IPC calls are limited based on their sandbox or some such thing.

 

From Krebs:

This may be one - a BlackHole link posted today:



Since the aim of the Exploit Kits is to provide a mechanism (exploiting a vulnerability) with with to install a trojan (ransomware, banking, etc), any type of security that denies unauthorized executables is good frontline protection against this type of attack, if a user encounters such a thing before a patch against the vulnerability is installed.

EDIT: I got the executable payload and it scans as:

----
rich

 

There is a good reason for Sun automatically checking/downloading/installing Java updates every system startup (by default on Windows PCs with Java SE installed).

 

From Public Java Exploit Amps Up Threat Level:

 

Unfortunately, for some reason, and this is something I hear from a lot of people, and I've seen it mentioned in this forum, is that the update process is somewhat flawed, ending up in Java not being updated.

I don't know if anything has changed, though.

 

Dead right I know people with Java on Vista & it wants to try & update on every boot. It often fails for "some" reason/s

*

What a bloated piece of Constantly badly written, ie: insecure, software it is. I'm glad i don't have it installed, or Ever have Yeah i know lots of us wouldn't get caught out with exploits for it, but that's not the point, Plenty of other people do, due to it's sloppy code year after year

 

Ironically Java is a fairly secure language, the JVM provided by Oracle is just awful.

 

Tried with comodo defence plus( AV turned off)!

- with paranoid settings maximum proactive security
- default settings

 

Nope it hasn't at least from what I seen. I know a several people where the update fails everytime it tries to auto update.

 

From Web malware exploitation kits updated with new Java exploit:

 

From the link MrBrian posted:

It's so easy for them (cybercriminals) just to prey on the complacent.

 

How about the Linux derivatives?