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. ®
Well, I disabled Java just in case.
Well, not really. VMs can add an extra layer of protection via their individual firewalls, anti-malware, etc, but generally if you want the apps to be accessable to the users, connect and store data on the databases, and act like a real service than the VMs are going to need network access like any other machine. And there in lies the danger.
I CAN tell you that machines without a network interface or no way to communicate with the innerwebs are much, much more secure! Of course they’re useless, too...
Javascript is very popular....
i don't think turning off Java on your computer stops this particular nasty stuff working....if I read it correctly.
BFL
To the Wikipedia:
*********************************EXCERPT************************************
A rootkit is a stealthy type of malicious software designed to hide the existence of certain processes or programs from normal methods of detection and enable continued privileged access to a computer.[1] The term rootkit is a concatenation of "root" (the traditional name of the privileged account on Unix operating systems) and the word "kit" (which refers to the software components that implement the tool). The term "rootkit" has negative connotations through its association with malware.[1]
Rootkit installation can be automated, or an attacker can install it once they've obtained root or Administrator access. Obtaining this access is either a result of direct attack on a system (i.e. exploiting a known vulnerability, password (either by cracking, privilege escalation, or social engineering)) or a result of... . Once installed it becomes possible to hide the intrusion as well as to maintain privileged access. Like any software they can have a good purpose or a malicious purpose. The key is the root/Administrator access. Full control over a system means that existing software can be modified, including software that might otherwise be used to detect or circumvent it.
Rootkit detection is difficult because a rootkit may be able to subvert the software that is intended to find it. Detection methods include using an alternative and trusted operating system, behavioral-based methods, signature scanning, difference scanning, and memory dump analysis. Removal can be complicated or practically impossible, especially in cases where the rootkit resides in the kernel; reinstallation of the operating system may be the only available solution to the problem. When dealing with firmware rootkits, removal may require hardware replacement, or specialised equipment.
Contents[hide] |
The first documented computer virus to target the personal computer marketplace, discovered in 1986, used cloaking techniques to hide itself: the Brain virus intercepted attempts to read the boot sector, and redirected these to elsewhere on the disk, where a copy of the original boot sector was kept.[1] Over time, DOS-virus cloaking methods became more sophisticated, with advanced techniques including the hooking of low-level disk INT 13H BIOS interrupt calls to hide unauthorized modifications to files.[1]
The term rootkit or root kit originally referred to a maliciously modified set of administrative tools for a Unix-like operating system that granted "root" access.[2] If an intruder could replace the standard administrative tools on a system with a rootkit, the intruder could obtain root access over the system whilst simultaneously concealing these activities from the legitimate system administrator. These first generation rootkits were trivial to detect by using tools such as Tripwire that had not been compromised to access the same information.[3][4] Lane Davis and Steven Dake wrote the earliest known rootkit in 1990 for Sun Microsystems' SunOS UNIX operating system.[5] Ken Thompson of Bell Labs, one of the creators of Unix, subverted the C compiler in a Unix distribution and discussed the exploit in the lecture he gave upon receiving the Turing award in 1983. The modified compiler would detect attempts to compile the Unix "login" command and generate altered code that would accept not only the user's correct password, but an additional password known to the attacker. Additionally, the compiler would detect attempts to compile a new version of the compiler, and would insert the same exploits into the new compiler. A review of the source code for the "login" command or the updated compiler would not reveal any malicious code.[6] This exploit was equivalent to a rootkit.
The first malicious rootkit for the Windows NT operating system appeared in 1999: a trojan called NTRootkit created by Greg Hoglund.[7] It was followed by HackerDefender in 2003.[1] The first rootkit targeting Mac OS X appeared in 2009,[8] while the Stuxnet worm was the first to target programmable logic controllers (PLC).[9]
That SpyHunter link in post #40 doesn’t work.
http://www.spywareremove.com/download-spyhunter-scanner/
Left it bare so it could be seen where it goes.
Bflr
The bug that is causing this is in the Java runtime from Oracle (formerly Sun).
If you want to avoid it, you need to uninstall the Java runtime (JRE).
It is not being caused by having Javascript enabled in the browser.
Javascript != Java!
The chief financial officer of the company relies on cloudy applications that require Java-in-the-web-browser.
The chief financial officer of the company relies on cloudy applications that require Java-in-the-web-browser.
Not necessarily.
Java applets can be launched from the browser, and appear within the browser window. But the Java runtime environment (JRE) is executing complied Java bytecode downloaded from a server.
These days, "cloudy" applications are more likely to be using Javascript in the browser (which is a different language, downloaded by the browser and interpreted by the Javascript engine within the browser) and Java on the servers, using Java 2 Enterprise Edition (J2EE).
You can uninstall the Java runtime environment (JRE) and Javascript will still execute within the browser, assuming Javascript is enabled.
Likewise, you can disable Javascript in the browser, and Java applets and applications will still execute, assuming you have the JRE installed.
Java applets running in the browser never really took off. Most applications, such as a financial application that a "CFO" would use, would use Java on the *servers*, but that doesn't require Java in the browser.
For example, my company uses Oracle ERP (accounting) software. It uses Java on the application servers, but there is no requirement for Java on the users' PC's. But it does require Javascript to be enabled in the browser.
Javascript is now technically known as "ECMAScript", and that is a better name for it, to show how utterly different it is from "Java".
Java is to Javascript as Car is to Carpet... The only thing in common is the first few letters of the name.
Here is another explanation.
How to disable Java in your web browser
**************************************EXCERPT*****************************************
By now you have probably heard about a new Java vulnerability that is been actively exploited on the Internet. I do not want to rehash all that has been said, and would like to suggest articles on ZDnet and Securelist for that which should provide you with an overview of the threat. Only that much: only Java 7.x is affected by the vulnerability.
****************************************************
However according to the article this thread started with,,,,,more than just java version 7 is suspect....
I have tried to clean up the links...i think I got them working.
My rule of thumb - if you don't need Java, uninstall it.
Most people do not need it. The only thing I have ever seen it used for by casual users (and I am in the software development field and I don't even have it installed) is little online mortgage calculators, some online games like Minecraft, or cable modem speed tests.
And if you are not sure if it you need it, uninstall it anyway. You can always download an re-install it. It will be obvious when you need it.
There has been discussion that it is not so easy to disable in IE 8 or IE 9. These instructions supposedly work.
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.