Slashdot Log In
Compromised SSH Keys Lead To Linux Rootkit Attack
Posted by
timothy
on Wednesday August 27, @10:20AM
from the bad-childhoods-keep-on-giving dept.
from the bad-childhoods-keep-on-giving dept.
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."
Related Stories
[+]
Debian Bug Leaves Private SSL/SSH Keys Guessable 670 comments
SecurityBob writes "Debian package maintainers tend to very often modify the source code of the package they are maintaining so that it better fits into the distribution itself. However, most of the time, their changes are not sent back to upstream for validation, which might cause some tension between upstream developers and Debian packagers. Today, a critical security advisory has been released: a Debian packager modified the source code of OpenSSL back in 2006 so as to remove the seeding of OpenSSL random number generator, which in turns makes cryptographic key material generated on a Debian system guessable. The solution? Upgrade OpenSSL and re-generate all your SSH and SSL keys. This problem not only affects Debian, but also all its derivatives, such as Ubuntu." Reader RichiH also points to Debian's announcement and Ubuntu's announcement.
Firehose:Compromised SSH Keys Lead to Linux Rootkit Attack by Anonymous Coward
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
As usual... (Score:4, Informative)
Change your keys regularly, and revoke the key as soon as you have the slightest doubt it's been compromised.
Reply to This
Re:As usual... (Score:4, Funny)
Change your keys regularly, and revoke the key as soon as you have the slightest doubt it's been compromised.
/me gives Redhat a dirty look.
Reply to This
Parent
How is this news? (Score:5, Insightful)
The attack appears to initially use stolen SSH keys to gain access to a system
Ok...so if you get the key to a machine you can get in and abuse an old vulnerability, assuming the machine in unpatched. The rootkit that they discuss is from 2005, so where's the news here? Be careful about your SSH keys and passwords?
Seriously, if there's more to this I'd like to know. The article hardly has more information than the summary.
Reply to This
Re:How is this news? (Score:5, Insightful)
The news is that this is probably fallout from the Debian OpenSSL fiasco, and that people should take it seriously pretty damn quick and get their keys changed.
Reply to This
Parent
Re: (Score:2)
Do you have any evidence for that?
I know that Debian handled that pretty aggressively. Too bad for anyone who somehow missed the memo.
Re: (Score:3, Informative)
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.
and (Score:4, Informative)
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.
Reply to This
Re: (Score:3, Insightful)
SSH is not available remotely on any of my servers. The only way to access SSH is to VPN in, using OpenVPN.
All SSH traffic is blocked at the firewall.
Re: (Score:3, Funny)
Dude, that's like building an electronic voting machine and putting anti-virus software on it.
No, wait...
Re: (Score:2, Funny)
Condoms are only effective at reducing relative risk vs unprotected connections by about 70 to 85% - source [wikipedia.org]. As always, the only safe way is abstinence! Not that anyone around here will listen to that; I bet most /.'ers are in promiscuous mode...
Re: (Score:2)
What, peeking in on others in the neighbourhood having sex?
Re: (Score:3, Insightful)
However abstinence is 90% less fun - source [youporn.com]
not that this has anything to do with the topic but 70-85% indicates they are doing it wrong, with proper usage, assuing that you get actual sex education not abstinence bullshit, that figure should be up to 90-95%
Re: (Score:3, Funny)
Does that make abstinence preconceived murder?
This just in: (Score:5, Funny)
Stolen login credentials leads to unauthorized access of computer resources!
Reply to This
Re: (Score:3, Insightful)
The point is "defense in depth".
If you don't accept SSH connections that aren't coming over your trusted, separately-keyed VPN, for instance, this is pretty moot.
If you've disabled loadable modules, remounted your root filesystem read-only and dropped capabilities to remount read-write (and otherwise hardened against rootkits), this can be pretty moot on that account too.
If you aren't doing those things, maybe you should think about it.
Oh noes!!1! (Score:2)
You mean if someone steals my SSH key, they can then use it to log into my account??? And if that SSH key is in the authorized_keys file for root, or if I have sudo set not to prompt for a password, they could install a rootkit?!?!? Why didn't someone tell me this earlier?!?!?!
Re:Oh noes!!1! (Score:5, Informative)
If you generated that key with Debian within the last two years, anybody can figure it out in minutes, remotely.
Reply to This
Parent
Re:Oh noes!!1! (Score:5, Informative)
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.
Reply to This
Parent
Re: (Score:3, Insightful)
How does the worm know what username to try to break into prior to escalating to 'root'?
Re:Oh noes!!1! (Score:5, Informative)
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.
Reply to This
Parent
Re:Oh noes!!1! (Score:4, Interesting)
so in an ironic twist people using debian are in the safest position.
Reply to This
Parent
New attack vector! (Score:3, Funny)
This may rival the DNS vulnerability.
Reply to This
Debian compromise: probably related... (Score:5, Interesting)
Even the openssh guys don't seem interested in including blacklist support for probably-compromised keys: see https://bugzilla.mindrot.org/show_bug.cgi?id=1469 [mindrot.org]
This means that, since the compromise arose, Debian and Ubuntu distros are safe once patched with the blacklist code. However, for keys generated on Debian/Ubuntu but uploaded to non-Debian/Ubuntu servers, those non-Debian/Ubuntu servers will still be vulnerable unless manually checked. This means: OpenBSD servers, Fedora servers etc.
Have any distros apart from Debian/Ubuntu provided blacklist-like tools for this issue? Any of the *BSDs?
Reply to This
Re: (Score:3, Interesting)
"OpenSSH now has a blacklist feature for weak Debian-generated ssh keys." From: http://www.dragonflybsd.org/community/release2_0.shtml [dragonflybsd.org] Please do just a LITTLE bit of research before posting.
Please do some research before telling someone else to do research before posting.
DragonflyBSD is a fork of FreeBSD and not exactly mainstream so you can hardly accuse me of not being aware of what it said. Further, apart from that remark on the page you linked-to claiming that "OpenSSH contains a blacklist feature",
Deny-hosts (Score:3, Informative)
Reply to This