Forgot your password?
typodupeerror
Security Encryption Software Linux

Compromised SSH Keys Lead To Linux Rootkit Attack 79

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Compromised SSH Keys Lead To Linux Rootkit Attack

Comments Filter:
  • As usual... (Score:4, Informative)

    by koh (124962) on Wednesday August 27, 2008 @10:24AM (#24765043) Journal

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

  • How is this news? (Score:5, Insightful)

    by Shade of Pyrrhus (992978) on Wednesday August 27, 2008 @10:26AM (#24765071)

    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.

    • by Goaway (82658) on Wednesday August 27, 2008 @10:31AM (#24765155) Homepage

      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.

      • 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)

          by Goaway (82658)

          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: (Score:2, Insightful)

            by mvdwege (243851)

            So you don't have any evidence. The quote you give is as much speculation as your original post.

            Mart

        • Re: (Score:1, Insightful)

          by Anonymous Coward

          *I* don't have evidence for this, but the weak version wasn't just weak but RIDICULOUSLY weak -- 65536 keys. An exaustive scan can be done against these!

          • Re: (Score:2, Informative)

            by ozphx (1061292)

            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

    • by rtb61 (674572)

      At a guess, some government systems that are not updated as often as they should be, not as well maintained as they could be or even not as securely configured as they should, say, banking and finance Linux, ISP, etc. install, were successfully attacked. As such a warning has to be issued to remind other slack admins to update their systems.

      As for where the stolen SSH keys were originally obtained, a certain Olympic event springs to mind, so the effort might be fairly wide spread and a concerted attack t

  • and (Score:4, Informative)

    by extirpater (132500) on Wednesday August 27, 2008 @10:27AM (#24765091)

    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: (Score:1, Funny)

      by Anonymous Coward
      I placed a condom between my ethernet cable and my NIC. This seems to have blocked all incursions.
      • Re: (Score:3, Funny)

        by MarkTraceur (1329579)

        Dude, that's like building an electronic voting machine and putting anti-virus software on it.

        No, wait...

      • Re: (Score:2, Funny)

        by Nick Ives (317)

        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...

        • by mikkelm (1000451)

          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%

          • by mhall119 (1035984)

            I think he was saying that it provides 70% to 85% _more_ protection against (infect|pregnancy)? than using nothing. However, using nothing isn't a 100% guarantee of becoming (infected|pregnant)?, so if unprotected leaves you with, say, a 50% risk, then protected would leave you with between 7.5% and 15% at risk (85% to 92.5% safe) .

            If my math is right, which I won't vouch for.

            • It's ammusing that its the christains say "abstainance is the only way" yet their own beliefs say otherwise. Dont they have some adaption of the Isis virgin birth myth?
        • by StikyPad (445176)

          As always, the only safe way is abstinence! Not that anyone around here will listen to that

          You're joking, right? Our userbase are the poster children for abstinence. "Abstinence through disciplined self-stimulation," that's our motto. Hell, I'm married and I've been abstinent for as long as I can remember. (Which actually isn't that long thanks to a rigorous diet of beer.) What was I saying?

    • Re: (Score:3, Insightful)

      by cbiltcliffe (186293)

      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.

    • by mi (197448)

      change your ports other than 22, this won't stop a full port scan but good against lamers scanning for port 22.

      That's as good an argument as the one, that a heavier car protects their occupants better in case of an accident, and that we should thus all drive SUVs and other heavy vehicles...

      Once everyone (or just noticeable number of people) put their sshd on a different port, nmap-style quick scanners will become part of the toolkits and quickly proliferate among "the lamers". Oh, and you'll be forced to

  • by Cocoronixx (551128) on Wednesday August 27, 2008 @10:29AM (#24765123) Homepage

    Stolen login credentials leads to unauthorized access of computer resources!

    • by meist3r (1061628)
      Breaking News: Burglar steals key to gate, breaks fence, now faced with front door lock and armed owner.
  • 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)

      by Goaway (82658) on Wednesday August 27, 2008 @10:34AM (#24765209) Homepage

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

      • Sounds a little exaggerated. Unless you mean "minutes" in the loosest sense, as in anywhere from 0 to 10^3000 minutes.

      • by rew (6140)

        The good thing is that besides generating better keys after the patch, patched debian systems will refuse to authenticate on a broken key!

        Thus, your broken keys become useless, and you're forced to generate new ones. Moreover, if there are "old" users on a system that no longer actively login on a system, they wouldn't notice the key no longer working. However, the patched system will refuse to authenticate the broken key.

        Hmm. come to think of it, there remains a risk of people copying bad debian keys onto

    • Re:Oh noes!!1! (Score:5, Informative)

      by GiMP (10923) on Wednesday August 27, 2008 @10:45AM (#24765379)

      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: (Score:3, Insightful)

        by MMC Monster (602931)

        How does the worm know what username to try to break into prior to escalating to 'root'?

        • Re:Oh noes!!1! (Score:5, Informative)

          by Chatterton (228704) on Wednesday August 27, 2008 @11:54AM (#24766493) Homepage

          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.

        • by GiMP (10923)

          I know know what this worm is doing exactly, but it could try random usernames, or simply usernames identical to that the key was stolen from (if stolen from local user eric, try remote user eric). A really smart worm would even check the known_hosts file, to direct its attack to the most likely hosts to contain a matching public key.

          • by GiMP (10923)

            Sorry, I meant to write, "I don't know what this worm is doing exactly".

        • by mzs (595629)

          It is a worm so the trick is spreading. It can get very far by trying the same username for all the hosts in the known_hosts file even if it cannot get root. It can also look at /etc/passwd for other users and try to spread that way to other hosts. If it can get root with a local exploit, it can look at everyone's known_hosts for more places to try and spread to. Also with root it can look in the comments of the keys and log files for more targets and usernames. Basically if it can get to 1% of the hosts th

      • Re:Oh noes!!1! (Score:4, Interesting)

        by RiotingPacifist (1228016) on Wednesday August 27, 2008 @11:55AM (#24766497)

        so in an ironic twist people using debian are in the safest position.

    • by mzs (595629)

      No if you have a user that logs in via ssh keys and that user generated the keys on an affected Debian box, an attacker can get in. Then they use a barrage of local root exploits to gain root, not a passwordless sudoer.

  • by betterunixthanunix (980855) on Wednesday August 27, 2008 @11:00AM (#24765651)
    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.
  • by daveewart (66895) on Wednesday August 27, 2008 @11:48AM (#24766385)

    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?

  • by Anonymous Coward

    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 ste

    • by Ant P. (974313)

      If an attacker can sniff your login password during an SSH connection, you're already fucked anyway.

  • 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.
  • Deny-hosts (Score:3, Informative)

    by johndmartiniii (1213700) on Wednesday August 27, 2008 @02:24PM (#24768667) Homepage
    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.
    • Easier tricks for us...

      1) Move the external SSH port to some other port number. Easy change. A minor road-block, but one that works well at cutting out about 99% of the attack attempts. Plus, if they have to port scan the server to find the SSH port, it gives you an opportunity to detect the scans and shut them down.

      2) Don't allow root to login over SSH. You'll still see a lot of people who haven't disabled that...

      3) Force users to use SSH keys to authenticate (no password-based authentication).
  • Use DenyHosts (Score:2, Informative)

    by metallurge (693631)
    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.
  • 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 t

  • 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

"The pyramid is opening!" "Which one?" "The one with the ever-widening hole in it!" -- The Firesign Theatre

Working...