There are some Linux system administrators out there who should be glad, very glad, they don't work for me because I'd be firing them today.
Why? Because the U.S. CERT (Computer Emergency Readiness Team) is reporting that Linux systems are being successfully attacked by crackers using compromised SSH (Secure Shell) keys. Once a system has been cracked with an illegitimate SSH key, the cracker uses local kernel exploits to gain root access and a rootkit called "phalanx2" is installed.
Once in place, phalanx2 steals more SSH keys from the compromised system. These keys are then, of course, sent to the attackers, who will use them to try to compromise other sites and... Well you get the idea.
So, why am I ticked off? Because to get those SSH keys in the first place they had to be vulnerable to capture. And, guess what? In the last few months there have been two occasions when it's been revealed that certain Linux distributions were wide open to attack.
The first time was when Debian, thanks to some really fouled up development thinking left OpenSSL on Debian, and related distributions like Ubuntu, wide open for attacks from September 17th 2006 until May 13th 2008. OpenSSL provides SSL (Secure Socket Layer) and TLS (Transport Layer Security) protection. It's used through Linux internally and in network communications for 'secure' transactions.
Then, much more recently, Red Hat's RHEL (Red Hat Enterprise Linux) and Fedora were briefly compromised. In these cases, Red Hat says some, not many, but some OpenSSH packages had been messed around with.
"No problems," said Red Hat. Funny that a few days later we're seeing successful SSH attacks on Linux servers isn't it?
OK, at this point, we don't know which, if any of these publicly acknowledged security problems, has lead to the current rash of attacks. I do know one thing though. First, that if system administrators had been awake at the switch they would have already set things right on both their Debian/Ubuntu and their Red Hat/Fedora boxes.
It's not like there was anything obscure about either of these security flops. You'd need to be deaf, dumb, and blind to have missed these stories and negligent to have not fixed any potential problems.
OK, so let's say you did manage to blow it. What do you do now?
Well, first you make sure that your systems have had the necessary fixes installed if you're not sure they have been. Next, according to CERT, you can see if you have a case of phalanx2 with the following steps:
" "ls" does not show a directory "/etc/khubd.p2/", but it can be entered with "cd /etc/khubd.p2".
" "/dev/shm/" may contain files from the attack.
" Any directory named "khubd.p2" is hidden from "ls", but may be entered by using "cd".
" Changes in the configuration of the rootkit might change the attack indicators listed above. Other detection methods may include searching for hidden processes and checking the reference count in "/etc" against the number of directories shown by "ls".
If, lucky you, you have a case, CERT recommends that you disable key-based SSH authentication on the affected systems; perform an audit of all SSH keys on the affected systems, and, oh boy won't this be a lot of fun, notify all key owners of the potential compromise of their keys.
What's lucky about this? You're lucky that I'm not your boss or your next step would be finding another job. Hey try this phrase out: "Would you like some fries with that?" If you can say that, you may have a challenging and exciting future in the fast-food industry.
Linux really is more secure than most operating systems, but, as the security mantra goes, "security is a process, not a product."
Some security breaches you can't stop. If your CEO insists on keeping his passwords on a post-it note on his display, there's not much you can do. But, for attacks like phalanx2, where simply being aware of recent major security problems and updating systems would have stopped the assault in its tracks, there is no excuse.