LWN.net Logo

CERT warns about SSH key-based attacks

CERT has sent out an advisory on key-based attacks being used against Linux systems. "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." There's no talk of where the original stolen keys come from. CERT's advice includes disabling key-based authentication, which, of course, runs counter to the advice given to those trying to defend against brute-force password-guessing attacks.
(Log in to post comments)

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 15:29 UTC (Wed) by skitching (subscriber, #36856) [Link]

Presumably the "stolen SSH keys" come from another system compromised by Phalanx2, ie the attackers can follow a "chain" of authentication credentials.

The advice does not state that *all* key-based authentication should be disabled, just "the affected systems", once a compromise has been detected.

And the main issue appears to be ssh keys without passphrases; I don't see any suggestion in the report that it is also capturing passphrases entered by users. However it isn't entirely clear to me from this report what the rootkit is doing; it is clearly meant to stay resident for some time (bothering to hide itself) so it must be doing something other than just a one-time-scan of the local filesystem. I wonder what...

From the report:
* Disable key-based SSH authentication on the affected systems, where possible.
* Perform an audit of all SSH keys on the affected systems.
* Notify all key owners of the potential compromise of their keys.

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 16:13 UTC (Wed) by epa (subscriber, #39769) [Link]

I don't see any suggestion in the report that it is also capturing passphrases entered by users.
Even if this particular rootkit doesn't, it's pretty clear that a rootkit can, and some day will. Use passphrases for your keys, but never forget that once an attacker has root on your system, you've lost.

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 16:28 UTC (Wed) by NAR (subscriber, #1313) [Link]

I wonder if it has anything to do with the recent Fedora and RedHat problems...

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 16:31 UTC (Wed) by pr1268 (subscriber, #24648) [Link]

Possibly, but my impression is that this kind of attack has been possible for a long while. Perhaps the recent events with RH/Fedora raised the collective awareness of such an attack...

Phalanx2

Posted Aug 27, 2008 16:39 UTC (Wed) by arjan (subscriber, #36785) [Link]

I wonder what vector Phalanx2 uses to enter the kernel.. does anyone have information about phalanx2? (I could only find the original phalanx with google)

Phalanx2

Posted Aug 27, 2008 17:00 UTC (Wed) by epa (subscriber, #39769) [Link]

It says Phalanx2 is a rootkit, which means you need to already be root to run it. So I suppose it can enter the kernel pretty easily with insmod or whatever.

Phalanx2

Posted Aug 27, 2008 17:05 UTC (Wed) by arjan (subscriber, #36785) [Link]

ok let me clarify my question; I wonder what they use to get root, and I wonder what phalanx2 does ... both

Phalanx2

Posted Aug 27, 2008 17:07 UTC (Wed) by skvidal (subscriber, #3094) [Link]

To get to root here are a couple of easy options:

1. sudo, if they've sniffed out your password anyway
2. vmsplice if you're running an older kernel
3. the root password, if you've su'd.

there are lots of ways, once someone has local access, to lie in wait for you to input a password.

Phalanx2 - details?

Posted Aug 27, 2008 18:05 UTC (Wed) by charlieb (subscriber, #23340) [Link]

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 17:44 UTC (Wed) by realgeek (guest, #53605) [Link]

Using password authentication isn't horrible; I use IPTables rules to temporarily drop packets from source IPs if they send too many syn packets to port 22 in a given period of time. It seems to do a good job of discouraging brute force scripts.

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 17:49 UTC (Wed) by jordi (subscriber, #14325) [Link]

Sounds like you reimplemented fail2ban. However, botnet have been observed to distribute the attacks in an attempt to workaround these attacks. You might find you get a ton of login attempts each coming from different IPs. In that case, your script or fail2ban are defeated.

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 17:59 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

Tarpit them?

tarpit who?

Posted Aug 28, 2008 4:09 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

You suggest "tarpit them." Which "them." If "they" are coming from all over the place.

Tar pitting is useful for tying up the network connections of a relatively small number of attackers (old-fashioned spam cannons) with moderate resources from each of a large number of distributed defenders. It's, in some ways, the reverse of a DDoS. Good for connections which would normally carry some non-trivial amount of data (such as SMTP/spam).

Tar pits are useless for traffic which has trivial amounts of data (ssh authentication) and are mostly useless against botnets (each bot in the net has thousands of available sockets). One machine trying to spew lots of spam has to content with its own inherent limitations --- it can have at most a few thousand concurrent network connections active (theoretically up to about 64K; but far smaller than that in practice). However, 100K machines each able to make 10K connections and you aren't going to have any impact with your tar pits. You need roughly at least 10 times as many tar pitters as attackers to achieve the right cost/benefit.

On my systems I use a combination of whitelisting, port knocking, and fail2ban to minimize the attack profile. I whitelist my designated administrator's client IP addresses (and some small address blocks in some cases), use a port knock sequence in front of my main ssh port, those are further protected by fail2ban along with the couple of non-standard ssh ports on which my daemon listens. On some systems (where "normal" --- non-admin --- users are intended to access their ssh services I just use fail2ban without the port knocker ... but those are running only ssh gateways --- users have to bounce through them to other systems behind them and don't have direct shell access to the gateway itself. Those require keys or one-time pads, no re-usable password permitted on them.
(Additionally those have lockout penalties for reserved accounts and non-existent accounts, to further reduce the risks of brute force attacks.

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 20:30 UTC (Wed) by arjan (subscriber, #36785) [Link]

solution against a distributed attack is a distributed defense ;)

also.. the anti spam guys have a pretty good list of IP addresses that make up botnets.. wonder if that can be tied to the anti-ssh-sploit tools

CERT warns about SSH key-based attacks

Posted Aug 27, 2008 21:44 UTC (Wed) by ttelford (subscriber, #44176) [Link]

There is a distributed defense. One such product is "denyhosts", which keeps a database of "offending" IP addresses uploaded from participating denyhosts users. While this can technically also be used to form a denial of service attack, most admins would rather deal with denial of legitimate users than admission of bogus users.

CERT warns about SSH key-based attacks

Posted Aug 28, 2008 2:03 UTC (Thu) by bcl (subscriber, #17631) [Link]

This report seems kinda, umm, dumb. How is this any different than an attack using weak passwords to get a local account and then applying local exploits to gain root? It isn't.

The attacker has to have some way to get into the account and access the key in the first place. I don't see anything new here.

CERT warns about SSH key-based attacks

Posted Aug 28, 2008 7:30 UTC (Thu) by frankie (subscriber, #13593) [Link]

Well, don't forget the recent weak keys issue for all keys generated on debian etch and derivatives. There's always the possibility that personal weak keys are around and can be guessed. Debian/Ubuntu servers are now safe by proper upgrading, but who knows about all others and personal keys?

CERT warns about SSH key-based attacks

Posted Aug 29, 2008 16:31 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

This report seems kinda, umm, dumb. How is this any different ...

The report doesn't claim there's anything novel or surprising about the attacks. It simply reports that they're happening. CERT does things like that.

CERT warns about SSH key-based attacks

Posted Aug 29, 2008 8:32 UTC (Fri) by csamuel (✭ supporter ✭, #2624) [Link]

This is nothing new, at the Cluster Security Workshop at CCGrid 2005 in Cardiff
Stuart Schechter presented an invited keynote on "SSH and Cascade Security
Failures", following on from the large SSH based compromises of 2004.

In it he presented an analysis of 2,000 users known_hosts files and ssh keys. Of
those 2,000 less than 40% were protected by a pass-phrase. Of course back then
the entries in known_hosts weren't hashed either, so an attacker had a ready made
list (sorted in a vague order of recentness) of systems to go and prod!

CERT warns about SSH key-based attacks

Posted Sep 4, 2008 18:07 UTC (Thu) by chrisV (subscriber, #43417) [Link]

"In it he presented an analysis of 2,000 users known_hosts files and ssh keys. Of those 2,000 less than 40% were protected by a pass-phrase. Of course back then the entries in known_hosts weren't hashed either, so an attacker had a ready made list (sorted in a vague order of recentness) of systems to go and prod!"

So you have a number of machines' /etc/ssh/ssh_host_* keys available to you. But the answer to that is to disable host based authentication, not public key authentication, which was apparently the proposal in the advisory. Disabled host based authentication is also the default ssh configuration.

This advisory seems to be about nothing more than stolen pass keys, which presumably must have been obtained in the first place by weak passwords on the same machine to which the pass keys relate (and on which password authentication was also allowed), or by some other vulnerability in the target machine apart from ssh.

If so, in the case of the first the best advice is to disable password authentication in the first place. On the second, if you have a machine facing the web with known vulnerabilities, then someone taking your passkey is the least of your worries.

CERT warns about SSH key-based attacks

Posted Sep 4, 2008 22:48 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link]

No, he was saying that 40% of the 2000+ *users* private keys were not protected by
a passphrase.

He wasn't talking about host keys (asides from the users known_hosts file)..

CERT warns about SSH key-based attacks

Posted Sep 4, 2008 22:56 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link]

Sorry, that should be 60% were not protected, not 40%..

ENOCOFFEE

CERT warns about SSH key-based attacks

Posted Sep 5, 2008 13:37 UTC (Fri) by chrisV (subscriber, #43417) [Link]

Perhaps I was too selective in my quoting. I was as much commenting on the "Of course back then the entries in known_hosts weren't hashed either, so an attacker had a ready made list (sorted in a vague order of recentness) of systems to go and prod". I thought from that that you were suggesting that the public keys in the known_hosts file gave rise to pass key authentication vulnerabilities, which they do not.

Attackers can prod as much as they like, but on a system with pass key only authentication it will do them no good at all. Even without a pass-phrase, it would take centuries to crack a properly formed RSA/DSA key. A pass-phrase might be useful in the case of a stolen private key (say, a lost laptop), but that's about it.

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds