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

26 of 79 comments (clear)

  1. As usual... by koh · · Score: 3, Informative

    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.
    1. Re:As usual... by Westech · · Score: 3, 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.

  2. How is this news? by Shade+of+Pyrrhus · · Score: 4, 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.

    1. Re:How is this news? by Goaway · · Score: 4, 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.

    2. Re:How is this news? by Goaway · · Score: 2, 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.

    3. Re:How is this news? by ozphx · · Score: 2, Informative

      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

      --
      3laws: No freebies, no backsies, GTFO.
    4. Re:How is this news? by mvdwege · · Score: 2, Insightful

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

      Mart

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
  3. and by extirpater · · 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.

    1. Re:and by MarkTraceur · · Score: 3, Funny

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

      No, wait...

    2. Re:and by Nick+Ives · · Score: 2, Funny

      Condoms are only effective at reducing relative risk vs unprotected connections by about 70 to 85% - source. 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...

      --
      Nick
    3. Re:and by RiotingPacifist · · Score: 2, Insightful

      However abstinence is 90% less fun - source

      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%

      --
      IranAir Flight 655 never forget!
    4. Re:and by mhall119 · · Score: 2, Funny

      Does that make abstinence preconceived murder?

      --
      http://www.mhall119.com
    5. Re:and by cbiltcliffe · · Score: 2, 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.

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
  4. This just in: by Cocoronixx · · Score: 5, Funny

    Stolen login credentials leads to unauthorized access of computer resources!

    --
    "Obscenity is the crutch of the inarticulate motherfucker." - cloak42
    1. Re:This just in: by cduffy · · Score: 2, 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.

  5. Re:Oh noes!!1! by Goaway · · Score: 4, Informative

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

  6. Re:Oh noes!!1! by GiMP · · 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.

  7. New attack vector! by betterunixthanunix · · Score: 2, Funny

    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
  8. Re:Oh noes!!1! by MMC+Monster · · Score: 2, Insightful

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

    --
    Help! I'm a slashdot refugee.
  9. Debian compromise: probably related... by daveewart · · 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

    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
    1. Re:Debian compromise: probably related... by daveewart · · Score: 2, Interesting

      "OpenSSH now has a blacklist feature for weak Debian-generated ssh keys." From: http://www.dragonflybsd.org/community/release2_0.shtml 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", there's nothing to suggest that OpenSSH itself actually contains any such blacklist management.

      My research: There's nothing in the OpenSSH ChangeLog at ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/ChangeLog which mentions blacklisting and there's nothing in the source tarball either. I've looked (both the core distribution and the portable version).

      It may be that DragonflyBSD includes blacklist management, but if so, they didn't get it from OpenSSH.

      I raised the bug https://bugzilla.mindrot.org/show_bug.cgi?id=1469 because I thought that such a feature should be included. If the OpenSSH developers were interested in supporting this, I'm sure they'd have (a) commented on the bug and (b) written the code or used some of the contributed code. They may well have good reasons for not including this, but they haven't commented either way.

      --
      "If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
  10. Re:Oh noes!!1! by Chatterton · · Score: 4, 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.

  11. Re:Oh noes!!1! by RiotingPacifist · · Score: 3, Interesting

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

    --
    IranAir Flight 655 never forget!
  12. I am invulnerable to this attack! by Anonymous Coward · · Score: 2, Funny

    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.

  13. Deny-hosts by johndmartiniii · · Score: 3, Informative

    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.
  14. Use DenyHosts by metallurge · · Score: 2, Informative

    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.