Slashdot Mirror
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."
Change your keys regularly, and revoke the key as soon as you have the slightest doubt it's been compromised.
Karma cannot be described by words alone.
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.
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.
Stolen login credentials leads to unauthorized access of computer resources!
"Obscenity is the crutch of the inarticulate motherfucker." - cloak42
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?!?!?!
God invented whiskey so the Irish would not rule the world.
This new attack relies on an attacker compromising login credentials. Then, the compromised login is used to install a rootkit on the target system.
This may rival the DNS vulnerability.
Palm trees and 8
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
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?
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
I have sucessfully computed a easy and 100% affective plan to stop this attack I have cleared the cookies, defragmented the memory drive, emptyed the recycle bin and set the Internet security zone to 'high'. Last off all I downloaded the latest Linux Kernal and extracted it to C drive.
Now it will not affect me i advice everyone else just follow these simple steps and you will be safe to.
This is a standard attack. The only thing SSH specific is that many users set up their accounts to be able to do password-less ssh login. Incidentially I do this to, since I am running mostly identical installations at both ends anyways. The only additonal risk (if any) is that an attacker does not need to wait until you do a login (ans sniff your password), but can go ahead immediately.
Side note: I do not think this has anything to do with the recent debin vulnerability. For that one you do not need to steal credentials.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
See subject, all this talk about checking if keys could be affected, but how does one do that? E.g. gcc.gnu.org should be very interested in this, as all access is handled by ssh keys, and getting every gcc contributor to change their key sounds like an uphill battle, whereas forcing the few affected should be easy enough.
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 It's worth looking into as an extra layer of security.
If you don't know what you're doing, you can't make mistakes.
Last year's Debian Project Leader, Sam Hocevar, is a senior member of the Gay Nigger Association of America. Sam can be found, along with several Pakistani terrorists, on IRC in #gnaa on NiggerNET (SSL on irc.gnaa.us port 6697).
See here:
http://commons.wikimedia.org/wiki/Image:Gnaa-logo.png
Not only does the GNAA seek to destroy Slashdot and Wikipedia (honorable goals), but they are very experienced with using botnets for fun and profit.
NEVAR 4GET: The Aliens come from France!
-=/\- Jizzbug -/\=-
Whenever I install a new distro, I compile a new kernel on it. The default kernel is normally very bloated -- most of loaded modules are not even used by hardware,and it is also weak on security. Atleast this has been the case with Ubuntu. Finally, custom kernel is be very strong on security.
Even veals have more autonomy!
DenyHosts 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.
U.S. Computer Emergency Readiness Team (CERT) has identified a potentially disastrous new security flaw in the 2.6 branch of the Linux operating system. This flaw, if exploited, can allow a machine to be compromised completely and a new rootkit called "Ubuntu LiveCD" can be used to make whatever changes the attacker wishes to the Linux operating system.
We've found that if an attacker can gain physical access to the computer they wish to compromise, they can insert this rootkit CD into the drive and press the reset button on the computer. They can then boot from this CD and use this new rootkit to do whatever they wish to the system. After a reboot, the Linux operating system comes back online and is completely compromised.
CERT is currently investigating new means to fix this rather serious flaw in the Linux operating system.
Just disrupt the deflector shield with a tachyon burst.
How is Debian being led by a GNAA member off-topic?!
Let me spell out the scenario for you:
"Hello, I'm Sam Hocevar. You might remember from such movies as Gayniggers From Outer Space. I am running for Debian Project Leader. I am from France. I work for the GNAA, we sell botnets to Russian gangsters."
A year later...
"Somehow a predictable pseudo-random number generator crept into our SSL/SSH packages, and Debian boxen can now be taken over by botnets. We are working to remedy the situation. My name is Sam Hocevar, and I approve this message."
Now do you get it? See how on-topic that is?
Hey! Who WOULDN'T trust their operating systems to botnet operators??!?
-=/\- Jizzbug -/\=-
The GNAA is a hacker group that runs botnets.
Only lamers and trolls think GNAA is a trolling group. (All hackers are trolls, but not all trolls are hackers. Put that in your Venn Diagram and smoke it!)
Wake up, retards!! DURRR
"Hello, my name is Sam Hocevar, I run botnets and Debian."
-=/\- Jizzbug -/\=-
Any SSH daemon listening on the public network should already be locked down to a basic level (denyhosts, changed port, IP-based access controls) in any case. I guess some installations will not be able to implement all of these but they are in the minority.
I'd take an educated guess at the vast majority of SSH daemons being used for remote administration; at the very least the controls mentioned above should be in place! Sure, this won't make you invulnerable, but the default denyhosts configuration alone (iirc) will limit the number of keys an attacker can try before he is locked out and an admin is notified.