Thanks ever so much Java, for that biz-wide rootkit infection Right on cue, Java has responded to my hatred in kind. Shortly after I awoke to discover my previous article denouncing the language had been published, a client called to inform me his computer had contracted some malware. Java has, if you'll forgive the anthropomorphization of a bytecode virtualization engine, decided to exact …
Given the complex web of how things are run in Windows, who knows what happened to allow infection? The user running this was not an administrator on the local PC. How then did this get the kinds of privs nessecary to install a rootkit? Browser glitch? Did it pop up a "run escalated" box? (Users says no, but...they're a user...)
I have no idea how something crawling through Java could install a rootkit on a non-administrative user. And yet, it did. So is this something that uses multiple vulnerabilities in multiple products, or is there a whole new zero-day at work here that we just don't know about?
I'm open to thoughts on this.
"And how would Java do that?"
In ancient times users could register a callback to WM_TIMER, when the timer expired the subroutine would run as intended, but ... at system priority. Something like that still in there or maybe one can smash the stack of the JVM and get it to do interesting things outside of the sandbox?
People worry too much about The Hardware, me think. I would worry much more about the wetware, like having the RIAA send me lawsuit rich enough to bail a bank, the local po-lice arrest me as a child pornographer, or a "hacker", or a "terrist" mocker of the London olympics. That sort of thing - all perfectly possible by just compromising my user account.
Arbitrary code running is BAD.
Oh? Do tell. It is an actively versioned bit of malware, so it is a moving target for everyone. But in my experience, is MSE can kill it, it isn't all that relevant. MSE cannot however kill rootkits like Zeroaccess. They are a threat.
Sirefef will be isolated by and contained by MSE unless we're talking about the very latest greatest variant. It won't get a chance to download buddies. Unfortunately, whatever the primary vector was murdered MSE before installing Sirefef.
Try it in practice. You'll sing a different tune. MSE cannot kill a single rootkit under active development. It can eliminate very old rootkits. Anything actively maintained will go through MSE like a hot knife through butter. It won't even see them, let alone be able to defang them.
FFS man, don't come in here and spread propaganda; we're actually trying to help people cope with real world issues here. This is not the time or the place for you pro Microsoft crap; especially when so much of it is half truths wrapped in outright lies. The lack of context in everything you’ve ever written in the comments section of The Register is appalling.
Please astroturf elsewhere.
"Try it in practice. You'll sing a different tune. MSE cannot kill a single rootkit under active development."
What would you recommend? In the repair shop I work in we've found it generally far better than the alternatives - Avast is good but can miss stuff MSE kills, AVG (my previous fav) may slowly waddle up to it but probably not, and Norton is absolute proof the machine is infected. Not sure on Eset. Trend seems good but expensive.
Would love to hear your thoughts.
(In case you're wondering, I like 3 things about MS s/ware: system restore (when it works), MSE, and that all the issues pay my wages - but I'd give that up in a heartbeat for a world without MS!)
Fucked if I know. MSE seems "as good as the rest." Every malware vendor has gaps in coverage. I like Avast and MSE because they don't don't seem to stpe on eachother's toes, so they can coexist. I prefer using multiple overlapping scanners on high-importance machines. Otherwise...prayer?
Nothing offers complete coverage. So we need to be ready with the re-install. Personally, I periodically run one-shot "second opinion" scanners such as housecall, even when they aren't resident. I don't trust any one scanner to find malware, so I throw the kitchen sink at things and hope it works.
The problem is more than partly 'the cloud'. I've seen several large projects in the last year using Java to dish up some awful cloud based whizzyware where the departmental buyers largely bypassed IT to get the latest snakeoil. They won't be responsible for the endless security nightmares, update aggro, version conflicts and poor performance of the craptastic Java platforms they paid for however, no matter how many warnings they get.
Sure, it's not one size fits all, but it's a damn good argument for forcing world+dog to run their "real environments" on a virtual with the underlying host being something safe that just serves as a launcher to said virtual.
Push comes to shove, you bring the sucker down, mount it's drives on a clean (and loaded with "heavy artillery") special purpose virtual and proceed to happily clean the bugger.
Worst case scenario, you already have your backup (the old HD image files) and can just start transferring data files from the compromised virtual to a new clean one.
Back in the NT4 days, making ppl use virtuals for "daily use" would have been torture. Nowadays, any halfway recent box will handle it just fine.
Happy, cause that's what a small investment in extra RAM and HD's made me...
Malware depends on an ecosystem, and at the moment Windows is so pervasive that it is an easy target. Given the move to browser-based apps, surely it would make sense for companies to split their desktops into three types - Linux, Windows and MacOS. Then any malware infection will only affect a third of their operation.
If everyone did this, then malware would have a much harder time, just as real infections struggle to spread if much of the population is immunised.
As a side issue it would also finally put those eternal questions about relative vulnerability and TCO to rest - just imagine all the real life comparisons free of sales/fanboi spin.
The whole article is great apart from 'Download and run Symantec's Zeroaccess removal tool.' I'd never install ANYTHING by Symantec super bloat loada crap doesn't work wont install. If ou're doing this you've enogh problems and spyware without installing MORE by Symantec!
I don't know enough about the need for Java and hence the risk implied by this article. Is 'Java' the same as 'Java script'? What is 'java in the browser' and how do I eliminate it if I need, at the same time, to retain 'java' on Windows (various generations) and LInux to run some applications?
Basic guidance would be appreciated.
So obviously you decided it was via java because you saw some jar file in a temp directory somewhere. Is this article reads like spin against java
Anyone running a machine that a company depends on should ensure that sensible user permissions are n place and virus checkers are up to date. Without these you might as well give up. Blaming a java browser plugin is just trying to distract from the underlying issue, the initial vector could be anything, true, even the java plugin. But if it had such a catastrophic affect as you made out then someone isn't doing their job properly.
The user was not runnign as admin. Their antivirus was up to date. Their browsers were up to date. Their browser extentions were minimalistic. Jars showed up and then dissapeared; shortly thereafter the system was pwned.
If you have a different attack vector for that, I am all ears.
So the evidence says there's an attack that can get around good security practice measures wit downloads various additional payloads and cleans up after itself. Either fairly well but not well enough (if it came via java), or well enough that the author didn't find it (if it isn't).
Either the attack is an unknown java exploit, or an unknown exploit with some other aspect of the system. There doesn't seem to be any evidence that the malicious jars introduced sirefef, they could just as easily have been additional payloads that may or may not have run.
I can't name the non-java exploit that could have caused this, but neither has the author named the java exploit that could. I'm not saying that this is definitively not caused by a problem with java, but there doesn't seem to be any real evidence that there is.
Here is a much simpler version of Trevor Pott's advice.
1.Use a non-admin account for your daily work.
2.Use a non-admin account for your daily work.
3.Use a non-admin account for your daily work.
4.Use a non-admin account for your daily work.
5.Use a non-admin account for your daily work.
6.Use a non-admin account for your daily work.
7.Use a non-admin account for your daily work.
8.Use a non-admin account for your daily work.
9.Use a non-admin account for your daily work.
10.Use a non-admin account for your daily work.
11.Use a non-admin account for your daily work.
12.Use a non-admin account for your daily work.
Java runs in user-space. Delivering a Windows-only rootkit requires admin access to the desktop. Do the math.
Yes, and the math leads to two words: PRIVILEGE ESCALATION. Hijacking something in the OS that already has admin access to get the rootkit in place. Unfortunately, privilege escalation is something that can occur in ANY OS (yes, even you, Linux--where did the term "rooting" come from?) with some chink in the code (and since programmers are human and some malcontents are patient, determined and/or motivated, odds are something will be found).
I work for a company where we still have to use Windows XP.
The Designed for Windows spec from over a decade ago requires applications to behave for non-admins.
as has been noted, there had to be multiple exploits here.
maybe - one in java to allow native code execution, alternatively its lack of sandboxing might have been sufficient to allow the next step via valid windows api calls
probably - a windows privilege escalation exploit that allows a user to run as admin
certainly - a service exploit to run user level code to spread across the network
it is possible that there was no privilege escalation bug used, but it certainly sounds like there was. I thought these were getting rare. Could someone in IT comment on that? I'm a dev, I create these sorts of problems with sloppy code, not solve them. I do remember an old redhat 5 privilege escalation exploit that you could go from a user shell to a root shell with only seven lines of typing.
I wish I had a definative answer for you. I am 98% certain the initial attack was delivered through java in the browser to a non-administrative user. Then what? What does it execute? Is it using a java-native escalation, or some other exploit? How the hell did that bit of fail break out of its sandbox?
Then it ate itself. To me, this is the biggest indication that there was an unknown zero-day being used. The author of that malware did not want to initial payload to be examined by security companies. There are holes in the logs; I only even know that Jars appeared and dissapeared because I had a completely separate app on debug for a completely different reason. (Trying to debug something inovlving Office 365.) It caught the logs thrown by MSE before it was anhiliated (and all of it's logs, browser history etc) with it.
Something crawled in through Java. Then it ate itself, the anti-virus packages, the logs and installed new friends. The user was not running as admin. So I don't really care if it used a native flaw in Java to escalate privs enough to do that, or if it cascaded other flaws once the userspace code had been delivered. Java was the initial vecotr, and windows cracked like an egg after that.
Something crawled in through Java. Then it ate itself, the anti-virus packages, the logs and installed new friends. The user was not running as admin.
"ate anti-virus packages" and "not running as admin" are mutually exclusive. Links, or it didn't happen.
Are you sure the user in question didn't have some form of privileged access on the compromised PC? Maybe "Power User" access? I've seen too many pieces of poor advice published that I would not be surprised if this stupid advice was followed and then propagated through Group Policy, quite deliberately, just to make some broken gotta-have-this application work because said admin was pressured into taking the quick and lazy approach.
Your rant flies in the face of over nine years of experience dealing with this very problem. Am I just lucky? Why hasn't this happened to me, or my clients, or co-workers when the machines I dealt with all had the latest Java, the latest Flash, and the latest Readers, and so on?
Every time I try to run anything that my affect a system configuration, Windows asks for administrator's credentials. The user is not a member of "Administrator" or "Power Users," only "Users." This is verified by taking the time to trace all the domain memberships, how they interact, and what privileges those security groups have on the local computer. The user itself does not have specific permissions on the local machine. Everything I can see points to the user account not having any administrative privileges on the local PC whatsoever.
I do not rule out the possibility that someone may have tweaked some obscure setting in the registry of the local computer before I took over administration of this system that somehow allowed this to occur despite the fact that the user appears in every other way to be unprivileged. Without going over the registry with a fine toothed comb, I cannot possibly know for sure. I do know that no extant GPOs exist that cause any such weirdness. The system is also an off-the-shelf HP consumer-targeted system; there is always the possibility that it simply shipped with a bizarre/obscure registry tweak that nobody is aware of.
That said, I have done the legwork on this. I wouldn’t be posting an article claiming that the thing crawled in through Java without being pretty damned sure that this is exactly what happened. I also don’t claim that it exploited the latest discussed vulnerability; I have absolutely no idea which vulnerability it exploited; for all I know it exploited a vulnerability that is a true zero-day and completely unknown outside the blackhat community.
I have determined that the browser in use at the time was Internet Explorer 9. I have gone over the IE9 settings; unless the malware in question changed the settings post-infection, it is entirely default. That should not allow Java, Flash or anything else to break out of a sandbox in usermode; and yet, it happened.
Look, as far as I can tell, this system is an off-the-shelf HP client system from about 2 years ago. It was attached to a domain run by an administrator that was pretty damned “by the book.” The GPOs and other configurations are pretty clear. WSUS automatically clears critical, security and definition updates for immediate install, and the user was diligent about keeping Java, Flash, etc up to date. Nobody played around with anything obscure because it simply was never required in this environment. It is as close to “off the shelf” as you can get for an SME install.
That’s what’s so scary about all of this. I would like to be able to write a “well damn it Jim, such and such happened because users are stupid” article. They get nods and smiles and sympathy from the readers instead of vicious personal attacks from a pool of internet piranhas.
Indeed, I have one such client that got slapped by their own stupidity on the same weekend. Nothing up to date, everything unmaintained, didn’t listen to my “disable java in your browser now” cries, and they run every user as local administrators. They got predictably pwned, but that’s not exactly interesting. (I like the billable hours, though!)
No, the guys that did it “by the book” and then got run over by something that crawled in through the internet are interesting. The CFO in question is a pretty honest guy; I asked him if he used a USB key, CD or anything in recent memory and no, he had not. I’ve checked every other vector I can think of, and nothing presents itself. So either something crawled in through Java and then broke out, or I.E. itself has a truly abominable zero day.
If I.E. has a zero day, the self-immolating Jars make no sense; why would Java anything be used as an intermediary there? Creating malware that requires something like Java be installed narrows your target availability unless Java itself is part of the vulnerability package you are exploiting to get the toehold into the system. This looks and smells like a Java vulnerability being exploited, probably in combination with something else. (http://arstechnica.com/security/2012/08/microsoft-defense-bypassed-in-2-weeks/ ???)
This is the first time I’ve seen a malware attack on a system that is reasonably properly defended. There is no obvious way this could have or should have occurred. If anyone has a better explanation I’m all ears on this; but I’ve spent an entire long weekend looking for obvious vulnerabilities in configuration and found none so far.
Now whilst I'm not a sys-admin (officially) I am the de facto sys-admin for friends and family and I suspect at some point in the future I will get "the phone call" and have to clear up a similar mess without resorting to nuking from orbit (the concept of backups will never make it into the domestic arena no matter how much I nag). So thanks for the all the tips - looking forward to my next battle.......... (not).
Sir,
I don't know if there are awards for perseverance in the face of malware based adversity but if somebody does create one you will have my nomination.
I would have given up, f-disked and started again long before working out the process you have described in your article. If that wasn’t possible I may even have considered joining the foreign legion or signing on to a pacific crab boat.
AC? Because I work in the industry and "should" be made of sterner stuff.
Two things: 1) I don't get physical access to the system for another couple of days. 2) I write a sysadmin blog, and my readers are important to me. If I can figure out how to kill the damn thing, maybe I can help someone stuck in a bad situation. If it helps just one guy stuck on the wrong end of a Teamviewer session, it's worth my Friday. :)
MSE flagged them as malicious, and this was logged. I had an app trawling writes to standard windows events at the time making a second copy, so it caught them being flagged as such. By the time I looked at the computer (about 15 minutes later) the Jars were gone, along with most of MSE, Avast, the Windows logs, browser history and so forth.
So these jars showed up, MSE caught them as bad, but wasn't able to kill them. The rest you know. The following is what was seen:
Java/CVE-2011-3544.gen![insert a letter here]
Exploit:Java/CVE-2012-1723
Exploit:Java/CVE-2012-4681[insert letter here]
Exploit:Win32/Java (no qualifier?!?)
Now, CVE-2011-3544 and CVE-2012-1723 should not have affected a fully patched copy of Java. CVE-2012-4681 is just new enough that I can believe it might have been exploited if the user had “patched but not rebooted” or some such. Install logs for this system say that Java was up to date (Java 6u35).
What’s curious is seeing these together within a second of one another followed by the system going crazy. MSE lagged detection of CVE-2012-4681 by a day…so my working hypothesis is that the user went to a site that took a shotgun approach to Java exploits, at least one of which worked. (There may even have been more exploits to come; it is entirely possible that the payload went off before all the detections had been completed.)
The payload that worked nommed all the evidence, except for my little logger which caught the mentions of the files that shouldn’t have actually been an issue. Now, you can flog me all you want for the one stupid thing I actually did during this exercise, but I think making the call that “this crawled in through Java” is backed by reasonable evidence.
What I should have done was immediately image the system at a block level and get the image to Symantec/Kaspersky/etc with alacrity. Assuming the malware didn’t dban the blocks where it was stored, someone could have lifted the thing off of the recently deleted blocks and we might know more about it. Sadly, I got the call pre-coffee and simply set about trying to kill the thing. By the time I realised that I might actually be dealing with something totally unknown, it was too late; I’d made so many system changes that imaging the thing was likely pointless.
So this is why I say that Java is the most likely candidate. Nothing else was untowards on this system. It looks to me like someone out there has an updated Blacole toolkit with some terrifyingly new exploits in hand and is using it with abandon. That said, I am not a security expert. I do not work for Symantec, Kaspersky or any of these other firms. I can only look at the evidence I have and say “well, this looks like the attack vector, this looks like the end result, here’s how you nuke the buggers.”
I can only hope that by laying out a “how to kill it” in my post, someone is helped. If along the way a little bit of awareness is raised about the fact that Java in the browser is bad for us all, so much the better.
Frankly, I don't think Java needs to be singled out as "the only bad thing to run in your browser." I think that any extensions in a browser need to be vetted for necessity. That includes Flash, Silverlight, .net, various toolbars and more. Shrinking the attack surface is always a good idea.
In the case of Java, I have a particular hate on because of the frequency and severity of exploits, combined with the abysmal response from Oracle regarding patches. This gets combined with the sheer unavoidability of the product and the versioning issues that can and do crop up in real world use. It makes me ornery. Doubly so when the issues I described in my post – and the subsequent comments – occur.
So if I hath insulted the almighty JVM, please accept my apologies. It sure looks to me like it is at fault here. I can’t even blame the user for this one, and that bothers the hell out of me.
I just finished a bout with Zeroaccess (A, B & C) but it did not manage to proliferate on my network and I know why although not as clearly as I'd prefer to. Hopefully we'll get some better info about how it mobilizes itself at some point because after reading your account I'm surprised I got off as easy as I did.
We have some very sensitive data that we simply cannot afford to have compromised (by any threat) and as such we have a hyper-paranoid firewall setup that involves multiple levels of scanning, not only for inbound connections and downloads but also for intranet packet exchanges. It requires a herculean effort on the part of the firewall(s) in terms of memory and processing but it stopped zeroaccess dead in its tracks; it managed to infect the ONE system on the network that was excluded from the inbound AV scrubbing. Ironically, it was the CEO that managed to infect himself because he complained that his internet wasn't as zippy as he'd prefer and so demanded that he be left with ONLY the end point protection of his choosing.. Symantec, because he said MSE wasn't good enough :}
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
