I think i found a way to stop this.
Can you please confirm if it still works if you change the following.
Put on always sandbox AND untick file and registry virtualisation on the D+ policy.
This seems to break the spawn of the java.exe that’s part of the IE parent to a new process java.exe that is the callback to the exploit server.
I will now make a clean install and verify on stock config also.
My win7 VM is broken now lol. I will create a new VM with win7 and will test this :-TU
Just retested with a clean install stock config it needs the following to prevent the exploit.
You have to put Java.exe on Always Sandbox as Untrusted else it won’t block.
No additional restrictions needed.
Beware I tested this on Win XP, x86, Administrator & Java 6u27.
No clue if java is still 100% functional tough.
[b]
[attachment deleted by admin]
Well just tested a legit Java site and it does break the functionality.
Best protection for this version is setting java.exe to run ‘Always Sandboxed’ on the Defense+ Computer Security Policy.
Sandbox restriction level “Partially limited” restricts most of the things the exploit can do with this single exploit.
It is no longer able to get e.g. process list running this setting, but is still able to make e.g. screenshot.
It can still download and upload files, where file uploads will end up in c:\vritualroot because of the sandbox visualization.
That won’t cause much harm cause they won’t become active on next reboot.
[attachment deleted by admin]
Would be even harder if the sandbox is hardened with start/run/internet access restrictions and/or a (system-wide) default-deny mechanism is in place (eg. LUA + SRP). But then the exploit may not work in the first place - did you manage to find out what exactly is the payload? Is it a PE executable?
EDIT: also, Sandboxie has protection against simulated keyboard/mouse input - I’m not sure if this would prevent the mouse/keyboard from being taken over or at least prevent eg. files from escaping the sandboxed browser:
http://www.sandboxie.com/index.php?SBIE1304
Regardless, almost anything is possible (but hard) when it comes to bypassing security software (or even to life in general haha) - proving/demonstrating that it’s possible is completely different to making claims though.
Also, I suspect Comodo would be unable to block exploits like this without being too “noisy”. Of course, any decent Classical HIPS (or Firewall in this context) can be configured to block or mitigate exploits like this.
From what I have seen it’s a Java applet, it spawns an other Java.exe that ‘exits’ from it’s parent (IE).
Then it uses the that java.exe in it’s security context that’s also the process that does the new call to the webserver.
In this case the firewall will alert 2x first for loading the webpage, and second for the exploit connection to Metasploit.
So containing that java.exe in as less permissions as possible will also limit it’s capabilities.
How do you mean by spawning another Java.exe? Is this Java.exe new code or existing code?
It’s a .class file.
IE loads the URL, downloads the .class file, IE->java executes it and silently that java.exe spawns a new java.exe which spawns a new java.exe the previous exits and the latest java.exe is a siingle process on it’s own now. That then makes the call to the control server.
Firefox gave no warnings, but what about Chromium-based browsers (since Chrome prompts the user to run Java).
Oh and what about IE9?
If you could, or tell me more about it. Cheers. 
I tried Ronny’s method of sandboxing java, and it does indeed work :-TU
IE9 is the same as FF, bypass no alerts. Chrome will alert you that the installed java version is outdated, which is good
The question is whether it would still be susceptible to this:
Probably Sandboxie would be resistant to it because of this:
http://www.sandboxie.com/index.php?SBIE1304
Would the default configuration of CIS also block simulated mouse/keyboard input or is a tweak necessary?
What happens if you run your browser in cis sandbox? I would assume no alerts but will the intrusion be gone on reboot?
In any case it will be gone on reboot if the attack stays like it is, the attack channel is opened by java.exe and there is no ‘build-in’ autostart for this example.
But in real-life situations there will be a second stage attack to make sure that additional malware will be able to be started after boot.
If you run sandboxed this will probably be contained unless there is a second stage attack vector against the sandbox technology used, so the attacker has to find out which sandbox your running and has to use an exploit to ‘jump out of that sandbox’ to get to a level that a third stage attack could enable him to install something that survives a reboot.
Starting a RAT could be a possibility to ‘disable’ the security software so they could continue attacking to the stage they have reboot survivability.
wow…I use sandboxie plus Comodo D+ (I think CIS automatic sandbox is not enough for certain kind of malwares, waiting for 6.0)…and I thougt this was an inexpugnable combo…but as far as I read, it is possible in theory to break this wall. Mmmm…this is an alarming matter… :-\
Nice find, It would be good to see how Spyshelter and Online Armour do against this one.
…and PrivateFirewall…
Tested Spyshelter, it get’s bypassed. Kind of expected this as spyshelter is not designed to block these kind of things. U might be interested in a new video i will post tommorow. I will be testing Spyshelter - Zemana Antilogger - keyscrambler in a new video against a rat. Will see if they really prevent keylogging, screen logging, webcam logging, and few other things. Will test CIS too. Will be interesting
Nice! can’t wait.
Could you please tell me what settings you tested SpyShelter on??? Was it Auto allow - high security level??? Under settings >>> Security >>>
Thanks
Shaun