Posted on 09/03/2012 10:05:45 AM PDT by Ernest_at_the_Beach
Closer inspection of the infection revealed deep network penetration that the installed antivirus applications were completely unable to cope with. The chief financial officer of the company relies on cloudy applications that require Java-in-the-web-browser. Contrary to early reports that we should only fear Java 7, this beauty crawled in through a fully up-to-date Java 6 browser plugin and installed some friends.
I have no idea what the initial vector was beyond the swift appearance and disappearance of some malicious Java archive files; the primary delivery mechanism scrubbed itself clean (along with significant chunks of the browser history) right after it downloaded its payload onto the compromised Microsoft Windows PC.
The payload: a software nastie called Sirefef. This itself is actually irrelevant; even Microsoft Security Essentials can find and kill most variants. The purpose of Sirefef is to serve as the staging component for the coup de grace: the highly sophisticated Zeroaccess rootkit (Sirefef downloaded some other friends too, but once the rootkit is dealt with, they are easily dispatched.)
Zeroaccess is a nightmare. It creates a hidden partition to run components from, deletes the BITS and Windows Update services, infects system restore and then removes the system restore interface from Windows. It locks you out of various sections of your file system it has decided to secrete backup copies of itself into. (C:\Windows\Temp, C:\Windows\System32\Config\Systemprofile and so forth.)
Zeroaccess knows all the standard tricks; it hides itself from Trend Micro's virus scanner Housecall, kills industrial-strength bleach Combofix (attempting to run this tool will freeze the system), resists cleaning by SurfRight's Hitman Pro, Symantec's resident AV and so forth. If you delete the hidden partition after booting from a Linux Live CD, chances are you didn't get every last remnant of the thing and it will be back in due time. It also prevents remote support app Teamviewer from starting properly with Windows.
If any residue of the rootkit lingers, or if Sirefef and/or its downloaded friends remain, they will all download and reinstall one another and we get to play whack-a-malware one more time. Bonus points were awarded for exploiting known Windows 7 vulnerabilities to infect every other machine on the network; that was a nice touch that really made my Friday.
So what's the solution? It turns out that some combination therapy kills the Zeroaccess variant in question. The solution I have settled upon is this:
If you are infected with Zeroaccess, exercise extreme caution. Someone is actively versioning this rootkit. I detected at least three different variants on one network alone. More to the point, the little friends that serve as satellite malware are also seeing some rapid evolution; what worked for me today may not work a week from now.
This incident should serve to underscore exactly how serious the Java exploits in question are. If you can, uninstall Java. If you must use Java, keep it as up-to-date as possible and see if you can disable or remove the plugins for your browsers. (In an attempt to help resolve the current crisis, Ninite is offering free access to the pro version for a limited time; it can really help with the updating.) If you absolutely must use Java-in-the-browser then it's time to start taking security very seriously; break out the tinfoil and start making some shiny hats.
Java-in-the-browser absolutely must be treated as "already compromised". There is no wiggle room here. Do not under any circumstances run Java in the browser on any production system or any client system in which any other application is used. Go buy another Windows licence and put Java inside a virtual machine.
Ring-fence the virtual machine by placing it on its own VLAN and subnet. Keep that virtual machine's traffic as separate from the rest of your network and system as you possibly can: Java-in-the-browser is a live grenade and you can't afford to have it go off inside your network. If you can, deploy the virtual machine from a managed template; the ability to destroy it at the end of the day and revert to a "known good" is a huge advantage when dealing with a threat of this magnitude.
Even if Oracle gets its act together and solves the immediate issues, this is only the latest in a long line. Java is simply is not developed with an adequate "security first" approach; Oracle is used to dealing with large corporations, not consumers. It doesn't have the experience to fight these kinds of rapidly escalating arms races, and it shows.
There isn't time to wait for Oracle to overcome its corporate inertia. It is time for systems administrators to act. It is our duty to depopulate Java with extreme prejudice. ®
Thanks for posting this antihelminthic procedure. Well-written too.
Later read!
Bump for later.
If you have Windows 7 or God forbid Vista, doing a system restore to an earlier date also seems to work.
I’ve ran across a few of these lately. What fun!
Ping.
fyi
Technical paper: The ZeroAccess rootkit under the microscope
bookmark
read later
No Idea...but doesn’t look easy.
BOOKMARK.
bookmark
I was wondering when someone was going to turn the spyware root-kits into a virus. One or two you can fix, 200 at a time will be a problem and if it can cross subnets, look out.
So, what’s the skinny? Should we not be running Java?
Hey, Ernest, I don’t have Sun java running on mine, but I did disable it off of my mom’s business pc, thanks so much for the heads up on this ^^
These people need to be put up against a wall and shot. And then the video put on YouTube for all the world to see.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.