How does one get infected with this particular nasty? Most system administrators know better than to install software outside of the repositories. How would this thing get on the server in the first place?
Evildoers can now turn all sites on a Linux server into silent hell-pits
An advanced Linux malware strain can automatically hijack websites hosted on compromised servers to attack web surfers with drive-by-downloads. The software nasty targets machines running 64-bit GNU/Linux and a web server, and acts like a rootkit by hiding itself from administrators. A browser fetching a website served by the …
-
-
Wednesday 21st November 2012 07:18 GMT Ben Tasker
Exactly what I was wondering. Going to need privilege escalation to get itself into the kernel, and that's after getting onto the server and being run.
How it gets there is as important as what it does, is it like the recent(ish) Mac malware that was only really a threat if users downloaded and ran it?
It's still an interesting story, but comes across as scaremongering when the infection vector is left out.
Right, moaning over, I'll go back to the article and see if there's a link I can click to find out!
-
Wednesday 21st November 2012 19:49 GMT ElReg!comments!Pierre
Re: route of entry
I guess that in a tagetted, spy-like scenario as the one described, the easiest way would be to put the nasty in a "legit" package by hacking the distro's official repositories (like what happened with FreeBSD recently). Actually that raises another question: does it run as a module (immediate effect, but easier to detect and eradicate) or does it require a reboot ( as a lot of Linux servers are only rebooted for kernel upgrades anyway that would make the malware mostly useless, but harder to detect/eradicate in the one-in-a-million case in which it would actually become active)?
-
Wednesday 21st November 2012 09:13 GMT Nigel 11
Infection route
One route would be any bug in the kernel that allows an attacker to execute code as root. Such bugs usually have a short life, but a rootkit may outlast the bug that allowed it to install itself. Alternatively the bug may at present be known only to the black hats. Another route would be if they managed to hack into a developer's system and build their malware (or a bootloader for their malware) into a released package.
-
-
Tuesday 27th November 2012 21:30 GMT YellowApple
Re: Infection route
Even with a privilege escalation bug, that information is not being provided, making all these scaremongering, FUD-filled articles about "OMG LINUX HAZ A ROOTKIT OMGOMG!!!!!1111one" rather worthless. I run a Debian server. I'd like to know how such a rootkit actually gets onto my machine.
-
-
-
Wednesday 21st November 2012 12:30 GMT h4rm0ny
Re: One route would be ..
"Except it isn't ..."
Isn't what? A possible route of infection? Yes - of course that's a possible route of infection. Do you think that there have never been privilege escalation flaws on GNU/Linux? If so, I seriously hope that you aren't a Linux sysadmin. Do you just never patch your Linux boxes because you believe there are no flaws and thus nothing to fix? All modern OSs have flaws discovered and need fixing.
-
-
-
Wednesday 21st November 2012 09:35 GMT Anonymous Coward
Funny, but all the Android Malware stories have the same basic flaw. You need to be pretty darn stupid and disable things that clearly warn you that you are opening yourself up to problems.
Yet the same sensationalist security companies (that are clearly running some special flavor of Debian called "squeezy") don't care, they just have something to sell you to fix it..
-
Wednesday 21st November 2012 12:27 GMT h4rm0ny
"that are clearly running some special flavor of Debian called "squeezy"
Are you joking? Squeezy is the mainline latest stable release of Debian. I am running it here right now. It's about as far from being a "special flavour" as you can get. Educate yourself before you dismiss other people's work.
-
-
Wednesday 21st November 2012 14:02 GMT h4rm0ny
Re: Bazinga
"Could you please put bazinga at the end in future because I couldn't tell if your a ding bat or being sarcastic"
Funny - I think the same about your post. Squeeze is the current mainline stable build. The AC seemed to think "squeezy" (sic) was some "special flavour" used by Kapersky to discredit Linux (from the context of their post). So are you saying that the AC was right in their paranoia (they weren't) or that I shouldn't have corrected them? I suppose it's possible that the AC was simply mocking the typo of "Squeezey" instead of "squeeze", but given that it was in the middle of a rant about anti-virus labs trying to set up contrived scenarios, smart money is on them just not knowing much about Debian.
Bazinga.
-
-
-
Wednesday 21st November 2012 10:46 GMT Anonymous Coward
How would this thing get on the server?
> How does one get infected with this particular nasty? Most system administrators know better than to install software outside of the repositories. How would this thing get on the server in the first place?
Doesn't matter as long as they've got Linux, malware and rootkit in the one sentence. If it was Windows then it would be referred to as 'computer' malware ..
-
Wednesday 21st November 2012 19:20 GMT El Andy
If only that were true. Alas, as can be seen from the comments on any malware story on the Reg, far too many people actually believe that Linux is magically invulnerable to all these security issues and wouldn't actually think twice about installing a package from somewhere else if they though they needed it. Couple that with the lack of anti-malware software running on most Linux boxes and it's a very credible threat.
-
Wednesday 21st November 2012 21:33 GMT h4rm0ny
What's really depressing is that someone modded you down for that. Meaning they actually think that you're wrong to criticise people for thinking Linux is magically invulnerable. The tragic thing is that back when I first started using Linux, in the days when you had to compile everything yourself, nobody had that attitude. Okay, we knew it was safer than Windows in a lot of ways both because it was more obscure and because back then you had Windows 2000 and XP that didn't have decent security models. But you didn't have this zealotry.
Linux seems to have acquired religious followers. Those of us who actually were around in the early days and probably know more about managing or programming on Linux than a lot of the Linux fan-people, get modded down by those who merely identify with the OS like its some sort of sect. Take Eadon for example - on a previous story they actually tried to make the argument that good programmers are those who develop for Linux, and bad programmers are those who develop for Windows. I struggle to believe someone who would make that argument has any significant experience in the world of programming. But I bet they think their pronouncements on Linux trump any old timer's. Eulampios who is posting here previously argued with me that it was right to misrepresent facts if doing so made Microsoft look worse.
Operating Systems as religion and to Hell with any inconvenient people who remember
LinuxJesus when he was just a man. How depressing.
-
-
Thursday 22nd November 2012 12:18 GMT Vic
> How would this thing get on the server in the first place?
The "full disclosure" list doesn't seem to disclose that, but it does appear that the malware is a kernel module masquerading as a sound driver.
If I'm right in that, then the infection vector must be a social-engineering attack to get an inexperienced sysad to install a driver for a new sound system he's bought. It's not clear how the modprobe occurs to load the kmod into the kernel, but these are the sort of things that tend to get noticed.
Given the nature of the infection, I wouldn't expect to see it on any mainline servers. The actual infection vector is the only thing of interest here, and it appears to be targetted at hobby servers only.
I'm not going to lose any sleep over this unless more worrying information comes to light.
Vic.
-
Tuesday 27th November 2012 21:31 GMT YellowApple
"it does appear that the malware is a kernel module masquerading as a sound driver."
Which begs the question of who in their right mind would need a sound driver on a web server.
No matter how secure an operating system is, not even the most invulnerable system can protect itself against administrator-level stupidity.
-
-
-
Wednesday 21st November 2012 09:13 GMT Bakunin
Re: niginx is not that "popular"
Nginx has been gaining a lot of popularity over the last couple of years as a load balancer in front of Apache. The usage statistics for Debian (only one distribution I know) show quit an uptake. But as the article states, that might be there target "market"
http://qa.debian.org/popcon.php?package=nginx
(By the way, I know the Register was only quoting directly from the Securelist blog, but it's Debian Squeeze not Squeezy. Typo on their part I assume)
-
-
Wednesday 21st November 2012 09:00 GMT K
"intermediate programmer with no extensive kernel experience"
Sounds like they are making this person out to be at the lower end of the "intermediate" skill set (amateur)...
Bear in mind, he probably created one of the more advanced Linux based root kits publicly known - that sounds like somebody with pretty advanced skills to me!
-
Wednesday 21st November 2012 09:11 GMT . 3
It sounds like it's the method of modifying the TCP stack to inject some extra bytes and, perhaps more cleverly, knowing exactly when to do it that is the novel technique.
Given there's no mention of how it gets planted on the server, the OS is pretty irrelevant. Perhaps the developer was just testing it out on some servers he already has access to that happen to all be running Debian. Having it spawning shells and writing temp files is pretty indicative of something not well polished.
-
Wednesday 21st November 2012 11:09 GMT Dave Bell
With all the logging tools and the like, that makes a sort of sense. Aren't there some standard cross-platform libraries involved in this TCP stuff? I know there is libcurl, but that is at a higher level than this seems to be. It does all suggest where the high-value targets in the Linux world are: not user computers but web servers.
When will I get a kernel update because of this?
-
-
Thursday 22nd November 2012 17:37 GMT . 3
What I mean is this: He's written some clever code to modify the functionality of the TCP stack in such a way that it can tell when a new web page is on it's way out and modify it as it passes though without triggering anything watching. He might well be developing this on Linux (as let's be honest, it would be night on impossible trying to debug and test it under Windows), so having some real Linux servers to try it on would be invaluable.
As there's no apparent mention of the method of installation, we can assume he has got root access to these machines by some other means and just gone in and done it manually. It's not a virus if there's no method of installing itself on other machines.
Once the code is perfected, it can be ported to whatever OS is vulnerable to attack, yet still a worthwhile target.
-
Thursday 22nd November 2012 18:14 GMT Vic
> Once the code is perfected, it can be ported to whatever OS is vulnerable to attack
Yes, but you've entirely missed the point I was making.
If you can place your code on a box running kernel version 2.6.32-5, that attack *will not work* on an otherwise-identical OS running kernel 2.6.32-46. The module willl not be loaded, and the attack will fail.
For this to be a widespread infection, the vector would need to install the kmod for every kernel fitted, and would need to monitor the filesystem on a regular basis in case any new kernels were installed. Each new installation would then need to be re-infected by downloading a new module built for that specific kernel.
This is an interesting attack, to be sure, but it's incredibly unlikely to go anywhere.
Vic.
-
Thursday 22nd November 2012 18:51 GMT Anonymous Coward
Or it could do like VMware Workstation/Player does
And compile the module as part of the install process. Granted this requires some extra packages that will not be installed on every server, but the userspace component that does the original install could download what it needs, build the module, then clean up after itself.
For bonus points, it could leave a slightly modified version of an existing startup script to verify the module is still in place. That way if the server's kernel is updated and the module doesn't load, the same build process can be initiated to build the module again for the updated kernel. Just like VMware does, except that it does it when you try to run VMware, rather than in the startup script. But there's no reason it couldn't be done there.
-
Thursday 22nd November 2012 20:00 GMT Vic
Re: Or it could do like VMware Workstation/Player does
> the same build process can be initiated to build the module again for the updated kernel
Yes, that's the dkms route.
It requires dkms to be run on boot, it requires the kernel-dev stuff to be installed, it needs a compiler available.
It's still a very long shot. I don't see this as a significant threat.
Vic.
-
Saturday 24th November 2012 02:32 GMT Anonymous Coward
Re: Or it could do like VMware Workstation/Player does
It would only require dkms if you do it as part of the OS. The rootkit could have a userspace component hidden away that runs on boot to make sure the rootkit module is loaded. If it finds it is not, it would then download what it needs (kernel-dev stuff, etc.) to build itself, re-install the updated module, then delete everything as it would no longer be needed. It could do the download and build slowly over the course of a few hours so as to not draw attention to itself via network traffic, CPU usage or rapidly changing disk usage.
-
Saturday 24th November 2012 10:13 GMT Vic
Re: Or it could do like VMware Workstation/Player does
> It would only require dkms if you do it as part of the OS.
If it's not a part of the OS, it's not an infection...
> The rootkit could have a userspace component hidden away that runs on boot to make sure
> the rootkit module is loaded
That's exactly what dkms does. You can rewrite it with a different name if you really want to split hairs, but what you're talking about is exactly what dkms does.
> If it finds it is not, it would then download what it needs
So you've now got a malicious userland process running on a non-rootkitted kernel. *That* gets noticed.
> It could do the download and build slowly over the course of a few hours
For all that time, it has to do the sort of thing that will trip the intrusion detectors without the protection of a rootkit hiding its tracks. It then needs to install software without root privileges - requiring another privilege escalation vulnerability on the newly-installed kernel - and then load the module. This is not a viable infection route.
Vic.
-
-
-
-
-
-
-
-
Wednesday 21st November 2012 09:14 GMT dssf
How it might be installed?
Maybe it is a service tech, left alone when a distracting, deliberate call to the server cage comes in. Maybe the tech is evil, or is just paid to do the dirty deed. Maybe the attackers hit server cages that do not have cameras. Maybe they have few or no guards physically monitoring the service techs, who then sneak payload into a server via a flash drive or patch disc, then waits for reboot permission so nothing seems suspicous since the actual monitoring tech may be returned and unable to sift the files for illicit code among tens of thousands of lines of code.
Just guessing. Am assuming the attackers gain PHYSICAL access, are granted live permission, and hold threatening power over the visiting tech rep. Again, just guessing.....
-
Wednesday 21st November 2012 12:04 GMT PyLETS
Re: How it might be installed?
No system is secure against someone with physical access and a little determination. BIOS chips can be switched, and EvilMaid type attacks can be made against disk encryption if used to obtain the encryption key. This particular exploit wouldn't even need a reboot if the kernel module is dynamically loadable.
-