digg

Join DiggAbout

The Digg Crew wants to hear your thoughts!
Please take our short survey about Digg and potential feature ideas.

Linux Systems Being Hit By SSH-Key Attacks

informationweek.com — US-CERT on Tuesday warned of attacks against Linux computers using compromised SSH keys. SSH (Secure Shell) is a network protocol designed to provide secure network communication via public-key cryptography. According to US-CERT, the attack appears to rely on stolen SSH keys to gain access to a system

show profanity settings
expand all
  • DeuceDiggalow, on 08/28/2008, -39/+20Oh noes! I guess I better get Vista! *rolls eyes*
    • Huangism, on 08/28/2008, -9/+15***** right! you know you want it
    • leerayIG88, on 08/28/2008, -5/+2I don't have eyes...I have goggles!
  • jamesmcm, on 08/28/2008, -23/+4Just disable SSH when you are not using it, either by stopping the port forwarding if you are behind a router or just stopping the service if not.
    • Onestone, on 08/28/2008, -0/+13Why?
    • mrjit, on 08/28/2008, -1/+19Yes, they are referring to the home Ubuntu user and not the datacenters with thousands upon thousands of *nix servers.
      • jamesmcm, on 08/28/2008, -3/+2Hmm.. I suppose my comment does seem stupid but still - when reading these articles people often want to know what they can do to make sure they are secure.
      • andycr512, on 08/28/2008, -0/+16jamesmcm: Most SSH servers are fine; it's only ones which the keys leaked from which are threatened. It's like saying people should quit using GMail altogether because 3 people who have accounts on it gave away their passwords.
  • smotpoker, on 08/28/2008, -15/+108What a useless article... No mention of how the keys were stolen or where from.

    For the record, ssh keys are not used by default on any distribution I've ever seen and IIRC, Ubuntu (and likely most other desktop distributions) has SSH server disabled by default.

    For the average Linux desktop user this means in order to be affected you have to:
    -Enable sshd
    -Configure ssh keys for specific users/processes
    -Not update your system regularly and then
    -Give those keys out to someone or leave them on a compromised or vulnerable system (ie a system that is also seldom updated and also uses ssh keys and was compromised using the same method)
    • smotpoker, on 08/28/2008, -7/+12-Be running a vulnerable kernel (not sure what sort of exploit or which kernels are affected by it)*
      • Drahkar, on 08/28/2008, -4/+14Its not really a vulnerable kernel. The people in question -have- the keys. They just setup an account and connect to a box with those keys configured. They are trying to make a huge issue out of it like its a code security hole when in reality its a human sucrity hole. If you are dumb enough to give out your key to someone, you deserve to get hacked.
      • elementop, on 08/28/2008, -2/+4Ummm...no. There was a bug in the Debian OpenSSL random number generator that, IIRC, allowed the keys to be stolen in the first place. However, unless you are using one of those of those keys, or if you are using a host that uses SSH keys *to allow connections from* a host that was subsequently compromised due either to the OpenSSL bug or due to keys being stolen due to the OpenSSL bug, then this is an issue.

        In addition, you have to be allowing SSH connections from the attacking machine. On my Linux boxes, I firewall the **** out of them, and only allow SSH from networks/hosts that I trust, which makes it somewhat more difficult to exploit. Certainly not impossible, but generally speaking, the black hats will go after the low hanging fruit (unless you give them a reason to do otherwise).
      • javaroast, on 08/28/2008, -0/+1@elementop "On my Linux boxes, I firewall the **** out of them, and only allow SSH from networks/hosts that I trust"

        And here you hit the nail on the head. I do the same on my boxes and would suggest that most home users follow the same advice. I deny everything on ssh and only allow connections from 4 specific places on my home boxes. Following that advice will save you a lot of trouble over the long haul. It's also an excellent way to stop the frequent brute force attacks dead in their tracks. Default deny is always a good way to start in thinking about security.
      • RoboDonut, on 08/28/2008, -0/+2@Drahkar: Read the article. Specificially, this part:
        "It then uses a local kernel exploit to gain root access"
        and:
        "Once in place, the rootkit steals other SSH keys and sends them to the attacker to facilitate further attacks."
      • smotpoker, on 08/29/2008, -0/+2@Drak

        "Its not really a vulnerable kernel"
        I never said that was how they get access to the system but that is how they are able to get sufficient privs to install the rootkit

        "If you are dumb enough to give out your key to someone, you deserve to get hacked."
        You don't really have to give the key out. Just leaving it on a host that is vulnerable is sufficient.



        1- host gets compromised via a kernel exploit and rootkit is installed
        2- all user dirs are searched for ssh keys
        3- keys are stolen and the hosts they goto are sent to attacker
        4- attacker connects to reachable hosts using the stolen keys
        5- goto 1

        This article failed to mention how the keys were getting "stolen" (not generated). That is why I said it sucks, spent 5 min googling and elaborated on it a bit.

        It is a significant flaw but like I said, successful exploitation reliees on kernel version and carelessness with ssh [keys].
    • RTFishUL, on 08/28/2008, -2/+15and make sure that venus is in line with jupiter during a blue moon.
    • dougmc, on 08/28/2008, -1/+2> What a useless article... No mention of how the keys were stolen or where from.
      The information came from CERT. They've never been about telling you any more than the bare minimum.
      • Knowltey, on 08/28/2008, -0/+2Actually it did say this:

        Once in place, the rootkit steals other SSH keys and sends them to the attacker to facilitate further attacks.

        Also a few days ago there was an article about Red Hat Enterprise Linux having some of their SSH keys stolen by a cracker, possibly related.
      • init100, on 08/28/2008, -0/+1@Knowltey

        "Also a few days ago there was an article about Red Hat Enterprise Linux having some of their SSH keys stolen by a cracker, possibly related."

        It's not related, and you are wrong. Red Hat had an intrusion, and someone managed to sign a few modified (likely trojaned) OpenSSH packages using the Red Hat GPG key. The private GPG key was not stolen though, since it resides in a hardware device from which it cannot be retrieved.
    • ChronicColonic, on 08/28/2008, -2/+20They should rename the site 'InformationWeak.'
    • 0x1B, on 08/28/2008, -1/+6It's a bit of a long shot, for sure, unless you've got a wide-open machine sitting off your cable modem or something.

      I can't find any details about the rootkit, but I wonder if it needs any build tools. Might be good to create a user account which can't log in, call it 'build' or something. Then make sure only root and the build user can use make, gcc, all the libs, etc. Remount /tmp as noexec might help, though they mention the kit creates a directory called /etc/khubd.p2. I wonder if creating a regular, empty file with that same name beforehand and then chmodding it to 000 would work. I don't know if the directory is created or populated as root or whatever. But perhaps it won't be able to overwrite files or some such. Worth a look maybe.

    • AmaDaden, on 08/28/2008, -2/+17"No mention of how the keys were stolen or where from."

      I believe the keys in question are the the ones generated during the Debian SSH issue a few months ago. For Ubuntu if you updated to fix this key issue the updater would (if you let it) regenerate your SSH keys.

      Yes this is getting WAY blown out of proportion. All Linux security is. This is likely do to the "masturbating monkeys" (http://article.gmane.org/gmane.linux.kernel/706950 ... who consider every securtiy hole the-worst-thing-that-has-happened-ever-oh-dear-god-it's-been-10-minutes-why-isn't-it-fixed-yet. Also any linux security bug is a reason for windows and mac people to point and say "look how bad linux security is!"

      Security bugs happen to every program and every OS. They tend to get fixed far quicker then the patch is actually pushed out. I bet this little issue will still be a problem for a hand full of computers in another 5 years just like there are still a few windows 95 computers on the net trying to send Michelangelo (http://en.wikipedia.org/wiki/Michelangelo_(virus))
      • SteveMax, on 08/28/2008, -0/+3Note that the SSH problem didn't happen a few months ago: it was corrected a few months ago. The bug has been there since 2006 (see the exact moment of its introduction at http://svn.debian.org/viewsvn/pkg-openssl/openssl/ ... )

        This means there is a whole lot of compromised machines out there. But this is not a Linux problem, it's a problem with the Debian mentality ("let's fork the code as we want and never talk to upstream about problems, because of course we know their code better than themselves!").
      • qwuinc, on 08/30/2008, -0/+1@SteveMax
        As far as I understand, it's up to the package maintainers how closely they work together with the upstream (and the upstream too!). In this case the lack of communication caused a disaster.
      • SteveMax, on 09/02/2008, -0/+1Exactly, and that is the problem.

        If all package managers touched bases with upstream, a bug found and corrected by, say, Fedora would find its way in Ubuntu; and a stupid move by Debian would be found by the upstream developers quickly and it wouldn't spell disaster.

        See that the "bug" "corrected" by that Debian developer (the uninitialized variables used) was discussed to death in the OpenSSH community. Perhaps it could be better commented ("this function will add the contents of an uninitialized variable to a random seed. Since the contents of an uninitialized variable is basically random, this makes the random generator more robust"), but it was assumed that whoever dealt with the code would at least know the basics of a random generator. What caused disaster was a package maintainer messing with code he didn't understand to keep out a warning from the debugger (!!), code reviewers who also didn't understand the code, no communication with upstream, and no review of the diffs by someone with enough knowledge in years. Even a quick email to an upsrtream developer ("hey, did you know you use an uninitialized variable in function XXXX?") would have stopped this from happening ("Of course we do, how else would we get a known-to-be-random initial seed?")
    • ElectricKetchup, on 08/28/2008, -1/+10>"No mention of how the keys were stolen or where from."

      RTFA to the rescue!

      "SANS Internet Storm Center handler John Bambenek in a blog post said that the weak key vulnerability identified in Debian-based systems a few months ago could be one source of compromised SSH keys."
    • cawpin, on 08/28/2008, -4/+2SSHing to my house to make sure I have all updates applied.....
    • sizzam, on 08/28/2008, -2/+1Fedora installs SSH server by default.
      • dougmc, on 08/28/2008, -1/+3Most distributions do. And it's enabled as well. In fact, most *nix clones also have sshd installed and enabled by default. If they don't, it's probably because they're so old that they have telnetd and ftpd enabled by default instead.

        Even OpenBSD, probably the most secure commonly used *nix, asks if you want sshd enabled at bootup as a part of the installation. (Or at least it used to.)
      • senfo, on 08/28/2008, -1/+2That's true, but that's not the point. The vulnerability affects stolen SSH keys. Most distributions do NOT ship with SSH-key support enabled. It has been years since I have touched a Red Hat (Fedora) machine; however, I do not believe that they ship with SSH-key support enabled, by default. You would have to manually update your sshd config files to enable support. If that were the case, you'd probably already know.
      • init100, on 08/28/2008, -1/+2@senfo

        "I do not believe that they ship with SSH-key support enabled, by default."

        They do, like all distributions I have tried. This isn't a problem though, since key authentication is much more secure than password authentication, which is also enabled by default. Actually, sites that care about security rather quickly turn off password authentication in OpenSSH and instead require a key pair to authenticate.

        Many users use passwords that can easily be defeated by a dictionary attack, and such attempts are very common. I see many of them every day in my SSH server logs, but they all fail since I do not allow password authentication.

        Key pair authentication on the other hand is extremely safe, unless your key is predictable like with the Debian OpenSSL key generation flaw discovered earlier this year. With proper unpredictable keys finding the right key will take an eternity. The attacker would have to guess the right private key, out of 2^1024 or more (if you use larger key sizes than 1024 bits - I use 2048 bit keys) keys, to successfully break into such an SSH server.
    • K4P741NxKRUNCH, on 08/28/2008, -0/+2Leave it to the smotpoker to show the article up :P

      • smotpoker, on 08/29/2008, -0/+1That's because smotpoker is the Mack-Daddy ;)
    • simonbp, on 08/28/2008, -0/+1http://www.metasploit.com/users/hdm/tools/debian-o ...

      Here's one way they were obtained. Basically, there was a flaw in Debian's openssl libraries that made it so that only 32,767 different keys were generated for SSH. This made it trivial to brute force the encryption on any SSH session using a key generated by the weak openssl libs.

      It sounds like these attackers are using systems still using predictable keys to gain access to machines that these machines connect to, and are working their way out from there.
    • gemmakicn, on 08/29/2008, -0/+1Maybe its me but every desktop or server i set up either has ssh server running by default or has it running as the first thing on my list once its installed...

      Quite a few automated systems use keys like this, particually with automated deployments for example with version control submission, data syncronisation, and the like. While most users PCs are safe, there are potentially a lot of server configurations made vulnerable by this. While software updates are made frequently keys are less frequently re-generated.

      From my understanding, any key generated by the faulty key generator is open to exploitation, so if someone compromises one system, then all the other systems that it has automatic access to are then vulnerable.

      I hope that any linux admin who is competant already has known about this and fixed it but there are a lot who pretend to be and they are the ones who need to be warned...

  • TruckStuff, on 08/28/2008, -5/+44I know this will come as a shock to most Ubuntu users, but most linux installs are servers that are admin'ed via ssh. Simply turning off sshd isn't an option in many cases.
    • Ryanx0r, on 08/28/2008, -23/+16Man, what?! Only noobs use SSH!
      Real men use Telnet!
      • SteveCUBE, on 08/28/2008, -1/+4I hope you're not serious...
      • DteK, on 08/28/2008, -0/+2this is why pw's and keys get compromised.
      • johndavidjack, on 08/28/2008, -0/+5Man, what? Only noobs use SSH!
        Real men keep a root-bash shell piped over netcat open on their servers!
        ./configure --D-GAPING-SECURITY-HOLE
      • init100, on 08/28/2008, -0/+2@SteveCUBE

        There are telnet implementations that use Kerberos for authentication and encryption, so he might not. But probably, he was joking.

        One such secure telnet is included with the Kerberos V implementation Heimdal:

        http://www.h5l.org/
    • Ryanx0r, on 08/28/2008, -2/+19Of course I'm not serious...

      Wow.. sarcasm doesn't fare too well in Digg land.. lesson learned
      • Culero, on 08/28/2008, -1/+4that was blatantly /s, too.
      • trackerbishop, on 08/28/2008, -3/+6stick to reddit, sarcasm and intellect are allowed there.
    • cawpin, on 08/28/2008, -9/+3TruckStuff - Eat me, I use Ubuntu at home as a server. Your snobbish attitude is the problem with Linux.
      • df12, on 08/28/2008, -1/+9I have a feeling your definition of "Server" isn't what Truckstuff is referring to. But that's besides the point now isn't it......
      • bemenaker, on 08/28/2008, -0/+4How about realizing he was being a little sarcastic. And with Ubuntu being a fav amongst newbies, it is fair to point out that by default, Ubuntu does not install sshd.
    • Culyt, on 08/28/2008, -2/+8You can try SSH over an encrypted VPN if your really tinfoilhat (unrelated point: tinfoilhats actually make you more vulnerable to mind control/reading).

      I would also recommend changing the port number of your SSH server, this is security though obscurity, and despite common misconceptions its actually a *GOOD* thing. Its *not good* to *rely* on security though obscurity but having obscurity *in addition to regular security* improves overall security.

      You can never get every hole, but you can cut down your chances of getting hit my an automated non-specific attack since they will be looking for port 22 as port scanning and service fingerprinting systems is not worth while.

      ☢
    • pak314, on 08/28/2008, -1/+3I'm shocked! Simply SHOCKED!
    • elementop, on 08/28/2008, -1/+1Quote: Simply turning off sshd isn't an option in many cases.

      Sure it is -- increase security by running telnet! (Yes, I am joking)
  • db113456, on 08/28/2008, -2/+16Now it does look like the source of the stolen keys is the debian related ssh key generation entropy reduction affected keys ... if that is the case, the the likelihood of any success are very low, partly due to the high profile of that issue, and the wide spread ripple effect of patching and new key generation that took place. I don't think any of the compromised 64000 or so keys are in use today. If they however stole keys from somewhere else, than that could be a different story. Even then, most admins i know, just generate a key-pair on the spot and use it for authentication and not use their usual e-mail etc.. singing keys
    • S1L3NTC, on 08/28/2008, -2/+3Singing keys? Like A minor?
      • db113456, on 08/28/2008, -0/+5Signing keys , like signature ....
        obviously a typo and the spellchecker did not catch it :-)
  • Huangism, on 08/28/2008, -24/+1muahhaha die!! die!!!!!!!!
  • JKWMedia, on 08/28/2008, -16/+0Linux attacks ... :D
    • wigren, on 08/28/2008, -1/+1"Finally, down her with the rest of us!"
      Difference is: This is not going to be an issue for a majority home users.
  • dondara, on 08/28/2008, -0/+16Eh, threat to mis-configured servers. Really, if this takes your machine down, something else was going to anyway.
  • d3dm, on 08/28/2008, -4/+44My other computer is your Linux box!
  • Viriatus2, on 08/28/2008, -14/+1ah ah! epic fail....
  • IphtashuFitz, on 08/28/2008, -0/+5Even if you use ssh keys you should always use a passphrase with the key, especially root ssh keys. And the passphrase should be as secure as any other password, not just "1 2 3 4 5". If you need to use an ssh key without a passphrase for some automated task then create an unprivileged user account with its own ssh key for the task to run under. That way even if somebody manages to get a copy of the public key they're severely limited in what they can do.
    • init100, on 08/28/2008, -0/+3"Even if you use ssh keys you should always use a passphrase with the key"

      That wouldn't help with the Debian OpenSSL issue, as only 65536 different private keys would be generated, and such a small number of keys can be tried by an attacker in s short while. In other words, the attacker generates a test key, then tries to authenticate against the target server. If he does not succeed, he tries a new key.

      With properly generated keys, the key space is enormous, and the above method would not work in practice (theoretically it would, but it would take an extremely long time, like thousands or millions of years).

      "If you need to use an ssh key without a passphrase for some automated task then create an unprivileged user account with its own ssh key for the task to run under."

      I second that recommendation, but I'd like to add another one. OpenSSH has a notion of "forced commands", i.e. commands that are executed when a user authenticates using a specific key. This prevents intruders using the key from using privilege escalation vulnerabilities to get root access. You can specify the task to run in the authorized_keys file for that user, and only that task can run using that key.
    • tripzero, on 09/04/2008, -0/+1damn, 12345 was my password. Guess it's time to change...

      me@my-cool-server$ su passwd
  • xatx3, on 08/28/2008, -26/+2awesome, ***** linux
    • DteK, on 08/28/2008, -3/+11no my friend, ***** you, ***** you in the ass and mouth.
    • kaelyiesta, on 08/28/2008, -0/+6You do realize that the wheels of the internet often run on linux? Whether or not its your OS of choice for personal computers, linux is often above the rest when it comes to servers.
      • TruckStuff, on 08/28/2008, -0/+3The Internet runs on tubes, not wheels. Duh...
      • init100, on 08/28/2008, -0/+1"You do realize that the wheels of the internet often run on linux?"

        Actually, the infrastructure of the internet, such as routers, switches, etc, are much more likely to run on Cisco IOS, or similar systems. Servers on the other hand, often but far from always run Linux.
    • johndavidjack, on 08/28/2008, -7/+3Linux, the OS for pussies that can't handle viruses and disease.
      • DteK, on 08/28/2008, -1/+6johndavidjack, the idiot who doesnt know the difference between an OS and a kernel
      • johndavidjack, on 08/28/2008, -6/+1Dtek, the serious sam with a badass attitude...

        Besides, it doesn't sound as cool saying "the kernel"...
  • StupotAce, on 08/28/2008, -2/+24An attack against linux? Must be a sign that it's the year of linux.

    ...well, somebody was gonna say it sooner or later.
    • init100, on 08/28/2008, -0/+1Learn the difference between viruses and intrusions. Intrusions on Linux systems are hardly news, but viruses are almost nonexistent.
  • v4vishal, on 08/28/2008, -7/+5What does Linus say about this?
    • dougmc, on 08/28/2008, -1/+8Probably nothing. It really has little to do with the kernel. (I would say it has nothing to do with the kernel, but a rootkit does have something to do with it ...)
  • Ryanx0r, on 08/28/2008, -6/+4I was never fond of the SSH key in the first place. Not that it's not safe, but typing a password in doesn't really bother me. I can understand if say another bash/perl/python script wants to access another SSH server, the easiest way to gain access is through a SSH key.

    Or those admins who need to admin a large handful of systems.. luckilly not many of us have that ask (although it does sound like fun)
    • IphtashuFitz, on 08/28/2008, -0/+13ssh keys aren't merely a method of logging in without a password. Indeed, you can set a passphrase on an ssh key so that it you still need to type in the equivalent of a password. ssh keys give you added security if you desire it (and take advantage of it). One simple case in point: You can tell the ssh daemon to disallow root logins via a password and only via an ssh key. In doing that you effectively improve security of the system so that even brute-force attacks against the root account will fail (root password from the console would still work, so you could always log in if you're physically at the computer). The only way you'd be able to log in remotely as root would be if you had the ssh key, and hopefully that ssh key has a passphrase associated with it.

      You can also associate a specific command with a key, so if you have an automated script that needs to log in and execute a command you can restrict the key so only that command can be executed. ssh keys can be very powerful and provide excellent security if you know the proper way to use them. Unfortunately it seems the many people just use them to avoid having to enter passwords, which is why this attack is proving successful.
    • bigsteve, on 08/28/2008, -0/+8Leave port 22 open on a *nix machine with SSH running (without keys) over a weekend, and look at the logs later to see why this is a good idea :) Lots of ***** poking around out there.

      And keeping root login off is always a good idea, because that's one username every system will have. Let the bastards guess a username and a password.
      • rowjimmy, on 08/28/2008, -0/+3it's kind of funny, really. sometimes i'll have my router forwarding 22 to a certain box, so that i can ssh tunnel from work to access my daap share. then a few days later, i'll look at swatch_rejects and it'll be filled to the brim :)
      • centran, on 08/28/2008, -0/+2It does get crazy. I was looking into intrusion detection but then just said 'F' it and installed denyhosts. 3 strikes and you IP is banned. It has decluttered my everything log since.
      • elementop, on 08/28/2008, -0/+2Not an issue -- that's what iptables is for. Lock down SSH access to hosts and networks that you trust and you will find a lot less attempts to brute-force your SSH server.
      • init100, on 08/28/2008, -1/+1"Leave port 22 open on a *nix machine with SSH running (without keys) over a weekend"

        Without keys? Why? Enable keys, make sure you have good keys (i.e. not generated on a Debian-based system before June this year), and disable passwords. That way, your system won't be compromised by the inevitable dictionary attacks.

        "And keeping root login off is always a good idea"

        You can also set it to without-password, which allows root logins, but only if you use a non-password authentication mechanism, such as a key.
      • bigsteve, on 08/29/2008, -0/+1@init100: I know, that was the point of my post. I was advocating keys, else you'll see tons of attempts. Re-read.
  • neowolfwitch, on 08/28/2008, -1/+10I have to agree with what others have already said. This wouldn't very likely affect ANY desktop user, only those with mis-configured servers. If a sysadmin is living under a rock and didn't update a debian-based server after the very-highly-publicized security warnings, or if they don't secure their keys appropriately- then they probably deserve to be a victim of this attack.

    Generally such keys should only be available to someone with root access, and if someone already has that level of access- you've got a lot more problems than just this exploit.
    • init100, on 08/28/2008, -0/+1"Generally such keys should only be available to someone with root access"

      What? What's wrong with letting ordinary users use key pair authentication?
  • Smogtdi, on 08/28/2008, -10/+10may be I'm just to tired and bored at work but this look like Microsoft is trying to make linux look bad on the server market.
    • microchp, on 08/28/2008, -1/+4It is funny that you are getting buried. I too have noticed a pattern of articles this week attempting to give Linux a bad image. Every article headline was totally unrelated to the actual article, just like this one. Propaganda/PR is a full time job for many so I am actually surprised we don't see more of this type of social engineering.
  • Pandatot, on 08/28/2008, -10/+2I know this! It's linux!!

    nuh uh uh, you didn't say the magic word.
  • toff72, on 08/28/2008, -1/+3i think it would not happen if servers had all updates installed !
    and if they are all updated , it's not linux fault, but SSH server software
    • init100, on 08/28/2008, -1/+1"i think it would not happen if servers had all updates installed !"

      It could happen with an updated server if you would use old keys generated on a system affected by the Debian OpenSSL key generation entropy issue reported a few months ago.
  • jamesmcm, on 08/28/2008, -13/+5People please refer to the operating systems as GNU/Linux since the GNU project produced at least 90% of the software used, and linux refers just to the kernel. To call it Linux deprives the GNU project of the huge credit it is due (it is the GNU project that made a usable OS. Afterall, without GNU, Linux would just be a kernel.)
    • bemenaker, on 08/28/2008, -0/+3Not to split hairs, cuz you are absolutely right, but most of us understand that and know that linux means GNU/linux.
    • rowjimmy, on 08/28/2008, -0/+1i think it'll be easier to get people to call it "*nix" or "unix-like" than gnu/linux.
      your point is well founded, but people tend to be stupid & lazy.
    • DamnLag, on 08/28/2008, -2/+3Put that pole any further up there and you may rupture your colon.
    • neowolfwitch, on 08/28/2008, -0/+1While I do agree with your statement in-general, "Linux" is what it is collectively known as, even though that is only the kernel. Most people on the street these days have at least HEARD of "Linux"- they know it is something like Windows or Mac/OS-X (Apple has an identity problem too, actually.), but they have no idea what "GNU" is. Geeks do, anyone who has actually used Linux for any length of time does, but the reality is- it's just "Linux" to most people. Your average man/woman on the street doesn't know or care what a kernel is...
    • jamesmcm, on 08/28/2008, -0/+1The whole point though is that when new linux users hear of the GNU project, they will listen to the GNU philosophy since they will realise how much they owe to it. It also helps to emphasise the huge amount of effort put in by the GNU project and community.
  • jamesmcm, on 08/28/2008, -13/+1People please refer to the operating systems as GNU/Linux since the GNU project produced at least 90% of the software used, and linux refers just to the kernel. To call it Linux deprives the GNU project of the huge credit it is due (it is the GNU project that made a usable OS. Afterall, without GNU, Linux would just be a kernel.)
    • Knowltey, on 08/28/2008, -1/+1Buried for spamming your comment twice
      • jamesmcm, on 08/28/2008, -0/+1Sorry it was Digg's fault
      • Knowltey, on 08/29/2008, -0/+1There is a way to delete your comment... You could have deleted one of them.
    • Doriath, on 08/28/2008, -1/+3I've noticed in your past comments that you refer to Microsoft Windows as just Windows, depriving Microsoft of the huge credit that it is due. So, STFU.
  • cgibbo, on 08/28/2008, -1/+22Hi! I'm Debian! Here are some random numbers for you:
    1, 4, 12, 7, 1, 4, 12, 7
    • toff72, on 08/28/2008, -1/+18that's problem with randomness, you can never be sure !
  • skyshock1, on 08/28/2008, -14/+1Where is your God now?
  • goldsaturn, on 08/28/2008, -4/+1Wow, deja vu!
  • monty671, on 08/28/2008, -4/+0All Your Data are Belong to Us.

    The writer of the story should have done more research.
  • roebeet, on 08/28/2008, -8/+2Linux is bad for you, eat more Microsoft. (burp)
  • mattgs, on 08/28/2008, -5/+1rlogin for the win
  • tomarocco, on 08/28/2008, -3/+10...as all the MCSE's reading this article think to themselves: "What the hell is SSH?"
    • cgibbo, on 08/28/2008, -0/+2What are the UNIX?
    • cmoz, on 08/30/2008, -0/+0Bashing MCSEs won't change the fact that this is one of the worst security flaws in GNU/Linux systems (Debian based)

      Being a MCSE that actually uses OpenSSH on OpenBSD and GNU/Linux, I can only laugh at such a immature comment.

      MCSEs are as different as Linux users are. Being an Gentoo Linux desktop user, I would hate it if someone compared me to a "regular" Ubuntu user, many of which know nothing about GNU/Linux internals, and use the GUI more that most systems administrators do in Windows.

      An IT professional would look for the merits of any OS, and utilize whatever is best in the situation, and not fall to the level of fanboyism.

      My only regret with ssh is the fact that it isn't included on Windows Server platform natively. It would make a great addition to it.
  • microchp, on 08/28/2008, -0/+8There are no stolen SSH keys. The rootkit is targeting keys and then giving them to the attacker. This is a common practice with rootkits and thus is pointless to mention unless the intent is to scare people. Buried as inaccurate.
  • shakajumbo, on 08/28/2008, -1/+2ok so serious question here (from an admitted Linux beginner)

    So if someone hasn't patched their Linux box, and I have a network share or some other shared file resource on that same box (say my .mp3 collection or whatever) would my Linux box be at risk because theirs is? I thought I read that this thing hits unpatched boxes, then learns the keys to other boxes from that exploited one. (I don't even know if I've given enough info to even answer this question)

    • db113456, on 08/28/2008, -0/+2If you have not set an ssh key authentication for yourself , and likely you have not. Than the attack is essentially meaningless, since without any user using a weak or stolen ssh key on your system it would be pointless trying to authenticate against a key that does not exist on the system.
      On the other hand, if you have created an ssh key pair , uploaded it to a server , or your own box for that matter , and are using it to authenticate than your system would be vulnerable, but only if it is Debian or Debian based , like Ubuntu / Kubuntu. And you should update immediately, re-generate your keys, reinstall them where they belong, and sleep well after that :-)
    • josejimenez, on 08/28/2008, -1/+0Make sure key-based authentication is disabled. Set AllowUsers in sshd_config. Then you are fine, even if your box is unpatched since this is an issue with stolen SSH keys as opposed to the daemon itself.
      • init100, on 08/28/2008, -0/+2"Make sure key-based authentication is disabled."

        That's just wrong. Patch your system, regenerate your SSH keys if your current keys were generated on a Debian-based system before June this year, and enable key authentication.

        Telling people to disable key authentication is a really bad way to solve this problem, as using passwords is a much worse authentication method than using properly generated key pairs.
  • briLo, on 08/28/2008, -6/+1Any chance this is Microsoft in an attempt to cause a little pain in the growing Linux popluation???
  • 3242130193, on 08/28/2008, -1/+2I'm particularly curious as to why something isn't done about the kernel exploit as well.
    • tnoy, on 08/28/2008, -0/+2There is almost always a kernel exploit of some kind. Once it is fixed, anther will be found.
  • Infowarmachine, on 08/28/2008, -1/+4it doesnt matter if you update regularly, if you generate a vulnerable key, it stays generated..
    you have to regenerate all new keys after upgrading

    (it mentions the keys were most likely 'stolen' (faked) thanks to an ssl/ssh random number generation flaw a few months back)

    • microchp, on 08/28/2008, -3/+3There were no stolen keys. The Ubuntu/Debian issue is unrelated to this article. In regards to that issue however, that was solved with an update the same day. Ubuntu updates by default. It is really a non-issue.
      • init100, on 08/28/2008, -1/+2"In regards to that issue however, that was solved with an update the same day."

        The key generation was fixed, but keys generated using the previous flawed version are still vulnerable.
      • microchp, on 08/28/2008, -0/+4The updates included blacklisting the bad keys and regenerating keys so that is not true.
  • xemumanic, on 08/28/2008, -2/+2This is exactly what happened with the Blaster worm on XP a few years back. Some hole was patched a month or more before, but so many went un-patched or whatever and got Blaster. This is similar. The SSH vulnerability was found a month or more ago, but there will still be systems hurt by it.

    I like how the Open Source community tries to downplay this, but as soon as it happens to MS, its a big deal, and they're the first ones up an arms over it, pointing and laughing like monkeys.
    • neko, on 08/29/2008, -1/+1Blaster: Exploited a hole in the RPC service (which is enabled by default), and if vulnerable, spreads and infects more machines.

      This thing: After being released on a multi-user vulnerable machine, looks/lurks for any SSH keys that people might have stored on that machine which allow access to others. It then needs to use those keys to log in to other machines as the key owner, and if that machine is also vulnerable, installs the rootkit and harvests more keys.

      It doesn't really compare to Blaster because it relies on many people leaving copies of their keys on remote servers. It certainly wouldn't spread to the majority of desktop machines. This isn't a SSH vulnerability. This is someone finding your keys in your office, and seeing what other rooms they can get into, and then looking in -those- rooms and seeing if it can find any more keys, and so on.
  • mrno, on 08/29/2008, -0/+3WOW! This is the best they can do? So your kernel has to be unpatched, you need rootkit installed, and you must use a ssh key without "any" passhrase. DAMN. We got owned. Please try again. Script kiddies.
  • StupotAce, on 09/02/2008, -0/+1Oh well, I guess it's a good thing that I didn't say it was a virus now isn't it?
  • SleighBoy, on 09/06/2008, -0/+2Not only is this old news, but to clarify - this is debian-specific because some fools took the advice of security testing tools and ended up killing a large randomizing portion of the OpenSSH code and wondered why the fine people on the OpenSSH/OpenBSD team would not take the "fix" upstream.
  • soso33, on 11/17/2008, -0/+0






    Thank you for the useful information 
    افلام
    , توبيكات
    ,
    منتديات
    ,
    دردشه
    ,
    برامج
    ,
    فساتين
    ,
    اناشيد اطفال
    ,
    دليل مواقع
    ,
    مسلسل الاجنحه المنكسره  ,
    مسجات
  • motivational, on 11/20/2008, -0/+0http://www.goonarak.co.uk/
    http://outdoorgardenlightingreviews.blogspot.com/
    http://hinkleylightingreviews.blogspot.com/
    http://lightfixturesbathroomreviews.blogspot.com/
    http://quoizellightingreviews.blogspot.com/
    http://patiolightingreviews.blogspot.com/
    http://seagulllightingreviews.blogspot.com/
    http://feisslightingreviews.blogspot.com/
    http://kovacslightingreviews.blogspot.com/
    http://feisslampreviews.blogspot.com/
    http://exteriorlightsreviews.blogspot.com/
  •  

    Login or register to add a comment

    Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.


© Digg Inc. 2008 — Content posted by Digg users is dedicated to the public domain.
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.