CERT: Linux servers under 'Phalanx' attack
Stolen keys unlock back door
Attacks in the wild are under way against Linux systems with compromised SSH keys, the US Computer Emergency Readiness Team is warning.
The attacks appear to use stolen SSH keys to take hold of a targeted machine and then gain root access by exploiting weaknesses in the kernel. The attacks then install a rootkit known as Phalanx2, which scours the newly infected system for additional SSH keys. There's a viral aspect to this attack. As new SSH keys are stolen, new machines are potentially vulnerable to attack.
The CERT advisory makes no mention of the flaw in the Debian random number generator, but that's most likely the starting point for the attack. The flaw caused SSL keys generated for more than a year to be so predictable that they could be guessed in a matter of hours. Debian fixed the flaw in May.
Once a Linux server using a weak key is identified and rooted, it quickly gives up the keys it uses to connect to other servers. Even if these new keys aren't vulnerable to the Debian debacle, attackers can potentially use them to access the servers that use them if both the private and public parts of the key are included. Additionally, attackers can identify other servers that have connected to the infected machine recently, information that may enable additional breaches.
Phalanx2 is a derivative of a rootkit known as Phalanx. According to Packet Storm, Phalanx is a self-injecting kernel rootkit designed for the Linux 2.6 branch that hides files, processes and sockets and includes tools for sniffing a tty program and connecting to it with a backdoor. Phalanx2 is been updated to systematically steal SSH keys.
Fortunately, Phalanx2 is relatively easy to detect. One tell-tale sign: typing "ls" at a command prompt fails to show a directory "/etc/khubd.p2/" even though it can be accessed using the "cd" command. Additionally, the "/dev/shm/" directory may contain files used in the attack.
Several tools, including this one, can be used to sniff out vulnerable keys. CERT is also advising keys use strong passphrases or passwords to reduce the risk of a key is stolen.
"I'm still absolutely adamant this is a problem system administrators should have handled a long time ago," said Bill Stearns, a security researcher and incident handler for the SANS Internet Storm Center. "It's a really big issue. If they haven't figured it out, someone will do it for them." ®
Missing the point
I am sick of this crap. There is a real security problem here that is potentially very very large. And most of what I have read is finger pointing or people suggesting that either "now Linux is as bad as Windows", or it is the fault of bad, lazy people.
Fact of the matter is that this rootkit *is* international, it attacks one of the basic things we've all trusted for the past decade - SSL/SSH - and we all may as well face up to the fact.
So, I'll point a finger at the fules who claim to know the score and who tell us about who's to blame.
I know a *lot* of computer sci people, I know a *lot* of sysadmins, and I know about two or three people who really understand public key crypto when I ask them hard questions. For all you armchair security experts: public key crypto == underpinnings of ssh/ssl.
And, well, if you don't know basic XML syntax, you can go back to school, and good riddance to you.
re: Peter Gathercole, but in re-reading this screed before posting, in fairness only partly:
<rant and="fuck off and die if you don't like it" also="there are some fair points below">
Yes, Windows user as admin is a common thing and a problem. We know that XP makes the first user - if created as part of the install process - an administrator and that is a problem insofar as that user typically is, well, just a user. We also know there is a massive ecosystem (gahhh) devoted to keeping exactly that Windows user safe including liberal use of system modal dialog boxes and idiot-light style pop ups from the system tray. You've gotta be pretty stupid not to notice when your Windows A/V software thinks there is a problem.
But! on Linux there is no such infrastructure. Rootkit hunter apps are not even installed by default AFAICT, and I've used a lot of distros: RH, Fedora, SuSE, Debian, Slackware, Yellowdog.
So - fine. I'm an admin and every box I've built in the past two years was built from a recipe and the recipe included rkhunter and chkrootkit running as cron jobs. I know this because I wrote the recipe. Might I f*ck up and miss a step sometimes? Perhaps, but I go back and check.
You know, I'm careful but I am not perfect and neither is anyone else who raises the "lazy sysadmin" flag. And neither is anyone at all.
Way back in the day, before a lot of you people had outgrown your milk teeth, before kernel modules, it was known and commented on that the monolithic kernel was safe from device driver (read: kernel module) attacks. Don't bother replying with remarks about /dev/kmem: I have not said the monolithic kernel was safe from that. Modules happened anyway, and they had to because else we need distro kernels with support for every possible device - how would you like a 100MB kernel (+/-)? (or, by now in 2008, hundreds of install kernels with limited device support - Slack had maybe two dozen kernels at one point circa the early 90's before modules - I *knew* the hardware in my boxes and still I sometimes picked the wrong install kernel). But I suppose that just makes me a lazy sysadmin, eh?
So, here is a suggestion, and it is not meant as a finger of blame by any means. How about the makers of distros just add things like rkhunter and chkrootkit as standard software, installed by default and updated by default and run periodically via cron, with notifications sent to the "main user".
I'll leave defining the main user to the lazy sysadmin finger pointers - they ought to be able to figure that out, having already defined who's to blame elsewhere.
I do not think that the bulk of Linux users will be any better than the bulk of Windows users at actually ameliorating a detected rootkit.
Windows A/V software has however raised awareness to the point that I, as a sysadmin, do get asked by Windows users if such-and-such a Windows notice or dialog is a problem. I have never been asked by any Linux user about their suspected virus/rootkit/trojan/substitute-your-fave-noun.
People who say it's all up to the admin are either living in a world where the admin *is* actually God or they are dishonest. In academia anybody who can get grant money can build her/his own Linux box, and many do so, and most of them do not ask for support or inform anyone who might have a clue. Outside academia anybody who buys a computer can install Linux and he/she does so if so inclined. And, you know, WTF, why not, it's a free country, right?
How many of you arm chair security experts have, or have considered purchasing, a "Got Root?" t-shirt? How many of you have thought about exactly how very easy "got root" has become? Don't even bother replying - I'll just tell you to download an Ubuntu install image - remember that problem where the first XP user is an administrator? Grunt, grunt, uhhuhuuh, grunt, drool. *Don't* waste my time.
Is it just possible that, at some 5% or 10% market penetration outside the corporate controlled datacentre, Linux is a big enough and so very useful target to the black hats? Or that insofar as it is a multiuser-from-the-network-OS, very easy to install but not so easy to understand, it is far more attractive for black hats than something like Windows? Wake up, a**holes: Linux has grown up. It's time for the users and distros to do so too.
One thing that needs re-enforcing is that unless you have a security hole that allows a non-privileged user across the security divide, it is just NOT POSSIBLE to install a rootkit on a properly run Linux system. Rootkits, by their very nature, need to alter/add code to the kernel, libraries or modules that are used to run the system. And this needs root permissions. This is why it is very important to make sure that you do AS LITTLE AS POSSIBLE as root on a UNIX-like OS.
There are a number of well known ways to try to subvert a user currently logged on as root, but a reasonably savy sysadmin should be able to avoid these (you know, don't browse the internet as root, check that your path does not allow commands from the current directory, make sure that there are no executable script files with world-write, don't read mail as root, keep firm control of the permissions on directories in root's path, all the simple stuff).
If a rootkit cannot be installed, it cannot compromise your system, nor can it get access to SSH keys other than the user it is running as.
Please note that I am not saying Linux is totally secure, there have been, and will be in the future, code and design defects which could allow a system to be compromised. I firmly believe, however, that the open source model allows such things to be identified and fixed much more rapidly than a closed source model. Couple this with an effective notification and patch delivery system, and Linux just is more secure.
Contrast this to Windows, where many people by default use an account with Admin. privileges, or with the security notifications turned off? Asking for trouble as far as I can tell.
But the amazing thing is that the UNIX/Linux security and source model is decades old (I've been using UNIX for 30 years, and the Bell Labs. UNIX V6 and V7 code, and all the BSD code used to be available for inspection and modification to the academic community and others for at least that long). And Microsoft (who, in fact, have been UNIX licensees for at least 24 years - they did the original Xenix port to various architectures, before spinning off the original SCO) just don't seem to be able to learn.
I was called to look into this because the fellow managing those machines was out of town - I consider it a very serious security compromise, and took care of cleaning it up even though they are not 'my' machines.
Believe me, sir, I did not consider it a regular part of the job in either sense!
If my tone in my original post was less than grave, I suppose it is because the event happened a week ago, it's been dealt with.