Compromised SSH Keys Lead To Linux Rootkit Attack

Tech Groupie writes "The US Computer Emergency Readiness Team (CERT) has issued a warning for what it calls 'active attacks' against Linux-based computing infrastructures using compromised SSH keys. The attack appears to initially use stolen SSH keys to gain access to a system, and then uses local kernel exploits to gain root access. Once root access has been obtained, a rootkit known as 'phalanx2' is installed."

As usual...

[koh]

Change your keys regularly, and revoke the key as soon as you have the slightest doubt it's been compromised.

and

[extirpater]

change your ports other than 22, this won't stop a full port scan but good against lamers scanning for port 22.
And you ip restriction. if you don't have static ip at least block connections outside of your connected isp.
you may also use port knocking protection.
these are not panacea but better than nothing.

Re:Oh noes!!1!

[Goaway]

If you generated that key with Debian within the last two years, anybody can figure it out in minutes, remotely.

Re:Oh noes!!1!

[GiMP]

What it means is that there are apparently some administrators not running Debian that have naively thought that the issue didn't affect them. However, if they haven't blacklisted those keys, they will undoubtedly have some users that generated their keys on Debian, which are vulnerable.

The worm will exploit this to obtain local non-root user access, and through local privilege escalation exploits will obtain root. Then, they will steal the keys stored on the host that might be used to connect out to other hosts. The last part of this is the deadly part, because those keys are not blacklisted, and will thus connect to and infect the hosts that don't have vulnerable-old-debian keys.

What this means for me, as the administrator of a web hosting company that has patched their servers, is that we will undoubtedly see illicit login attempts. With some really bad luck, one of those login attempts might work, despite our patching. Then, we are at the whim of how well we're secure against local privilege escalation.

Re:How is this news?

[Goaway]

No, I just actually read the article.

Details on the attacks â" and targets â" remain scarce but itâ(TM)s a safe bet this is linked to the Debian random number generator flaw that surfaced earlier this year. A working exploit for that vulnerability is publicly available.

Re:Oh noes!!1!

[Chatterton]

With the exploit, breaking the key is a matter of minutes. The worm could try to crack them all hoping to find one generated on a debian box and not updated.

Deny-hosts

[johndmartiniii]

I've been using a package called DenyHosts for about 2 months now. It's in the Debian repos. It just reads the auth.log file and blocks ssh login attempts based on the parameters that you set. It's cut back on my login attempts by about 40% since I started playing with it. It helps a great deal even if you are doing password-less logins, because it will block based on the user, whether it is valid or not, root login attempt, et al. denyhosts.sourceforge.net [sourceforge.net] It's worth looking into as an extra layer of security.

Use DenyHosts

[metallurge]

DenyHosts [sourceforge.net] is a handy little script that watches your ssh port, looking for brute force/dictionary attack attempts. Then it blacklists those IP addresses. You can also set it up to share your blacklist with others, and/or to update your own blacklist with what other users have found.

Re:How is this news?

[ozphx]

It was worse. The only entropy was the process ID.

That means the *likely* seed for longer running system processes was in a subset of the low couple of thousand.

For user processes, well starting low and ending higher would eat up keys like no tommorow. One researcher successfully made an exhaustive scan in around 48 hours on a small cluster :S