I’d like to bring up the recently discovered and still fairly ill-defined strain of malware dubbed the “random js rootkit” to our web friends out there. It is a quick lesson for the uninitiated in just how vicious the “bad guys” out there are in this day and age, and how you really need to be looking at the overall picture for securing your applications.
We here at onelittlewindow are known for being outspoken about trying to raise consciousness in the area of securing web applications. But really, underlying that message is one of a broader nature — that really, security is everyone’s responsibility. Just because you are not a “security person” doesn’t mean you can turn a blind eye, at least not without consequences.
To repeat the dogma, a system is only as strong as its weakest link, and so everyone using an information system has the ability to adversely (or positively!) impact security. So does every technical part of the chain.
All the effort in the world put into validating input and encoding output does no good if someone can walk right into your server and change your code, or the very fabric of what the underlying operating system does. And, interestingly enough, like so many others big hacks that hit the news, this “new” attack may not even be so new, but just a new incarnation of an older one that’s been done before.
The current iteration of what is being called the “random js rootkit” was first spotted in December of ’07, by the security monitoring company Finjan among others. Here’s a quick rundown:
The rootkit is placed on a Linux server through unknown means. Once the bad actor has established a foothold, they are setting up a small web server, which adds javascript to the web sites on the Linux box that weren’t there before.
The newly-added javascript then “does bad things” — it requests additional code from the server, and will try a variety of browser and OS exploits to install malicious code on the client computer. Finjan reports seeing up to 13 different exploits being tried on one pass by the malware.
Now, this may seem very similar to a variety of other attacks where websites try to “do bad things” — so why the hubbub? Why is this one different? Because it shows a variety of the ways malware is evolving, all wrapped into one efficient package:
- Randomization: The javascript being served is unique for request made to the web server, and is not repeated. Thus, most signature based detection methods are going to fail, in terms of an IDS or Antivirus signature blocking the download of the hostile code.
- Resident only in memory: The javascript being served up does not actually reside on the server — it only resides in memory, along with the working parts of the malware on the server itself. So, if someone does go and try to track down any traces of the malicious files, they won’t be there anywhere that a normal user or administrator would think to look for them. (yes, it does appear that it builds itself from binaries that are on the hard drive, but one has to know where to look for them. It’s not up to Joanna’s standards yet
)
- Obfuscation techniques: The rootkit web server serving up the javascript keeps track of client IP address, and only tries to exploit each client once. So, the first time a client hits the site, it is served the hostile javascript, and the exploit is attempted. On later trips, the IP address of the client that hit the site is seen coming back again, so the server does not try serving the hostile javascript again. *poof* — The attacker has vanished into thin air. Even if the client machine has sufficient resources to allow someone investigating to pinpoint the source, the javascript that was downloaded is apparently gone when someone goes back looking for it. An investigator trying to retrieve the malicious code from the same or another client will find it no longer there because a unique instance was used, and only once. An investigator on the server will have no concrete evidence of what the client claims, as the hostile javascript is never evident on the file system.
So, you have a trusted web site that you allow javascript for, with completely innocent content. That site then proceeds to serve up a unique set of attack code to every new client that comes along, which attacks once and is never seen again, and after that can’t be found on the site from either the client or server side.
Of course, to make things even better, if the client is successfully exploited, it has a trojan installed on it that adds it to a bot-net. And, as stated earlier, no one actually knows how this is getting on servers in the first place, and from what can be told from the little bit seen when a server is attacked, the attackers manage to log in without any issue on the first try. Rumors of an “unknown” root exploit are going around, but due to the fact that outbreaks of this have been somewhat localized (supposedly only to some hosting providers), a contending and far more believable theory is that whoever is behind this current scheme got ahold of a database of root passwords for several hosting providers, and is taking advantage of virtual hosting environment structure to use this to knock over large numbers of sites.
In going with the “this is everyone’s problem,” a fair bit of scant information on this topic has come from the CPanel mailing lists, forums, and blogs – those of you who are not familiar, CPanel is a hosting control panel used by a lot of hosting companies for their virtual hosting packages. From the little information that has been released, a large amount or all of the servers compromised have been running the CPanel software, and so the CPanel software group has been investigating this on behalf of their customers, even though there is no direct indication that a problem with CPanel has been involved. So far Finjan and other have identified how the malware works, but if someone has figured out how it gets on the boxes, no one is talking yet. And, if some of the web hosting forum banter is to be believed, some administrators have seen the payload before, so the actual “random js” part is not new, it’s just actually being noticed for the first time this time around.
The moral, without going on too much of a soapbox? Being online in this day and age is almost criminally easy — but if you are going to have content on your systems or applications that is sensitive in nature, it is your responsibility to worry about security and privacy, no matter where you are in the food chain. Make sure that your servers are patched and locked down, that your hosting and software providers respond to issues and have good methods for response and feedback, AND be aware of all the implications of what you do with your code, your application structure, and data that people entrust to you. And even then, bad things may still happen, and the community needs to work together to solve the issues.
I’ll post again if there is any happy resolution on this story.
Some links:
- CPanel security note
- CPanel blog entry
- Finjan Press Release
- Finjan White Paper (registration may be required for download, the one in question is the January 2008 offering):
- That this is “nothing new” talked about in forums
In the media:
And, I like to think that my contacting the handlers at SANS ISC is partially responsible for this post though they had already touched on the topic here and here.