What is Digg?Sponsored by Best Buy
The camera starts rolling on Best Buy holiday campaign. view!
www.youtube.com/bestbuy - A behind the scenes look at one employee’s singing debut.
30 Comments
- Heywoodj, on 04/01/2009, -4/+54Problem found ,problem fixed, problem can not happen again, problem honestly reported to the community.
All done in the sunshine.
Well done Fedora. - TomKarpik, on 04/02/2009, -3/+16This only proves to the Linuxfag/Macfag/Winfag crowd that OS security is only PART OF THE PROBLEM, and that no OS can be 100% secure as soon as you let people loose on it.
- trogdoor, on 04/02/2009, -0/+10It's hard to say that the problem can't happen again when they don't even know how the private key was compromised.
- Megatog615, on 04/02/2009, -3/+11How is this ironic?
- magamiako, on 04/02/2009, -1/+9Dude what are you talking about? SSH keys are 1000x as secure as simple password authentication. You'll sooner find a keylogger on someone's system than something that will grab SSH keys.
Plus it allows you to secure accounts on the local machine far more than what you used to be able to do. Even if someone were to compromise your server and for some reason was able to grab your authorized_keys file they can do *NOTHING* with it.
On the contrary, if you use simple password authentication your sole verification resides on your server computer. By some chance someone grabs /etc/shadow in some way, they now have as much free time as they want to break whatever possible weak passwords you set for accounts. They do not get this luxury by grabbing your keys file, well, they do but if you generated using the default 1024 bit key (or if you're paranoid 2048-bit), they aren't going to break that private key in any reasonable amount of time.
While I agree with having password authentication, it is a tough case to make if you follow normally alternative proper security procedures. This guy did not. - shinkou, on 04/02/2009, -1/+9Another piece of evidence which proves that human error can never be eliminated.
- HonoredMule, on 04/02/2009, -1/+9The private key was not "left out in the open," it was on a private machine that no one but the owner should have been able to access. The machine owner's ssh key was cracked/leaked by unknown means.
All things told, the break-in was a pretty exceptional scenario.
"I haven't read the actual mailing list exchanges, so perhaps these concerns have already been addressed. "
As for that, revoking the one compromised key was sufficient to seal the breach. The whole point of rebuilding the entire certificate authority was to start fresh with new security policy, removing any possibility of even a recurrence using other pre-existing unsecured keys. - Heywoodj, on 04/02/2009, -0/+8I knew I'd be called out on that point and rightly so.
Still kudos to the Fedora team for keeping everything above board. - miztaken, on 04/02/2009, -1/+7Hi, I'm a spamming douche monkey? I think so.
- johnwoo32, on 04/02/2009, -1/+6Imagine being the guy whose SSH private key AND password were stolen. I'd feel pretty lame. They probably will never find out how even his password was stolen.
- magamiako, on 04/02/2009, -0/+5HonoredMule:
He could have accidentally uploaded it, he could have accidentally left a share open, or he could have let someone use his computer. There are any number of means that someone could have obtained that private key file.
His machine could have been compromised by a trojan and when someone realized that this person might be important they scanned the machine for private key files.
It is an exceptional scenario, but one that can happen to *anyone*.
Nobody cares about security until you have an infiltration. - planetbeing, on 04/02/2009, -6/+11Hold on a second. You're telling me that someone left a copy of an unpassword protected SSH private key that had access to a copy of the package signing key for a distribution thousands of computers rely on!? And the only reason they were found out was because they were sloppy and broke a cron job?! First of all, why would you leave the package signing key on a computer enough people have access to that someone leaked an SSH key from. Why wouldn't you put the key on a special signing machine that no one touches unless for very special circumstances (and then just remotely request that it sign stuff)? This way the key could be kept safe. I thought this would be standard practice in large organizations.
Reissuing keys is something you do as a matter of course when something like this happens, but what are the other infrastructure changes that occurred? The only thing that's cited in the article was that SSH keys now have to be password protected. Whoopdedoo. Any admin lazy enough to leave their SSH key out in the open will be lazy enough to use a relatively easily brute-forceable password. What's the point of having 2048-bit RSA as package signatures when someone can get at it by cracking like an eight character password or something.
I haven't read the actual mailing list exchanges, so perhaps these concerns have already been addressed. But honestly, no one should be interpreting this story as a OPEN SOURCE COMES TO THE RESCUE piece (as much as I love open source) but as only a mildly mitigated horror story. - magamiako, on 04/02/2009, -1/+6planetbeing:
How else are they going to sign packages for distribution easily? What? Load everything up on a portable hard drive and sneaker net it to the machine with the private key? And do this on a set schedule monthly? That's a bit ridiculous.
Password-protected SSH keys will work as long as you follow these guidelines:
-Figure out approximately how long it will take someone to X or Y password. (Usually at least 10 characters is pretty strong).
-Rotate both passwords and SSH keys within the time frame it would take someone to break the password on the private key.
Alternatively they could move to smart card based authentication or hell even biometric authentication as well, though the key/password rotation policy should work pretty well on the cheap. But really, as long as someone has remote access to that machine you have to assume a hole in the network. But that's just a risk you take. - bennyboyo, on 04/02/2009, -3/+6And you believed it?
- magamiako, on 04/03/2009, -0/+3Scotty:
Okay, so I guess I should re-word what I implied with this paragraph. Using SSH keys is *SAFER* than relying on simple password authentication.
However, using both SSH Keys *AND* a strong password is the safest bet.
But really to be honest, this guy seriously ***** up somehow when it came to his system. I don't think it was any simple compromise that resulted in that key getting stolen. Either that or it was a targeted attack. I don't think I've seen nor really heard of any trojans out there that search your hard drive automatically for any SSH key files. You're sooner going to get a key logger on your client system than you will find software that does this. So while it's not necessarily more secure, it's safer to say the least.
And it's not necessarily a "false sense of security", because he assumed that his usage of wherever he put this key was safer to begin with.
And when I meant that an SSH key is more secure in itself, it certainly is when it comes to SSH'ing into the machine. The simple fact is that password security gets infinitely limited by the amount of ***** you want to remember. To have adequate password security you should use a different password for each site or system you use. You should use a different password for each location/system, and each one should be at least 10 characters long with at least a special character, a number, and a capital letter. As computing power increases dramatically, you then have to increase that password by a few characters to increase the time to brute forcing it.
Of course, we know people generally don't use random characters such as #a18$^#@j, no, they will use dictionary words that they remember easily. They might use their name, high school name, pet's name, address, whatever have you.
When it comes to raw brute force prevention, an SSH key significantly lowers the attack vector. And while there are many solutions to securing SSH (limiting the # of retry attempts, fail2ban, limiting logins to certain IP addresses). None of these are as flexible AND secure as using an SSH key.
Limiting the # of retry attempts, say you happen to be on a different keyboard than normal and you still don't hit the caps key properly or whatever have you. Bam, locked out for X amount of time. Limit logins to certain IP addresses? What if you find yourself at a random coffee shop somewhere when a server goes down that you have to be able to remotely connect to? Uh oh, can't fix it from there.
But at the end of the day, yes, he should have had a password (a rather complex one) on the SSH key. Now they know.
However, it is still VERY strange that this would have gotten out anyway. - koick, on 04/02/2009, -1/+3Good job guys, but this in no way "reads like a detective novel". This is closer to that:
http://en.wikipedia.org/wiki/The_Cuckoo%27s_Egg_%2 ... - init100, on 04/02/2009, -0/+2"This key existed on the other hand for pure laziness it looks like."
Using SSH keys is much more secure than using passwords, provided you keep your keys secure. There is really no excuse for keeping an unsecured key, unless it is used for a "forced command", i.e. it can only be used to execute a predefined command on the server. The proper way to be lazy with SSH without compromising your key is to use the SSH agent, which unlocks your key once per session and stores it in memory, so that it can be fed to multiple SSH instances without requiring the passphrase each time. - padraic2112, on 04/02/2009, -0/+2> Using SSH keys is much more secure than using passwords, provided you
> keep your keys secure.
No, it's not. In the first place, that "provided" is a plenty big huge gotcha, there, pally.
In the second place, any blanket statement about one thing being more secure than any other one thing is completely off-base.
Things are more or less secure in the context of a security system and vulnerability space, the are not more or less secure in and of themselves. - mdman, on 04/02/2009, -0/+2duh...
- ScottyMcBaggs, on 04/02/2009, -0/+2WTF @ this paragraph:
"Plus it allows you to secure accounts on the local machine far more than what you used to be able to do. Even if someone were to compromise your server and for some reason was able to grab your authorized_keys file they can do *NOTHING* with it."
PKI has been around for a long time in SSH first of all, so "than what you used to be able to do" means nothing unless you've been using unix since like ***** return of the jedi. Doubtful however... given the demographic of digg, chances are you a teenage 'buntard. Second of all, what the ***** does authorized_keys have to do with it? The server is the ***** attack vector, client access points are the easiest. We're talking about a key that you can just ssh-add with no pass. Local access to a system, you grab an unpassworded SSH key and put it on a usb stick. I can almost guarantee the partition it resides on is not encrypted and grub has no password, so that part's not too hard. O look grep ssh ~douchebag/.bash_history >> /media/yourusbstick/stuff.txt. Now you've got an unpassworded SSH key and a list of servers to try it against. Doesn't exactly require a lot of compute power. In the case you're talking, someone has to either crack your passwords of sniff them. You don't even have to INSTALL a keylogger once you have the SSH key cause it has no password. So maybe I'm still not getting it, how in the ***** is an un-passworded SSH key more secure than a password? An SSH key with no password is ***** like not even one-factor authentication, it's like .3-factor authentication. - Gman1223, on 04/02/2009, -0/+1Wow! What a find!
- init100, on 04/04/2009, -0/+1@padraic2112
"No, it's not."
No? Allowing password authentication allows crackers to run dictionary attacks against your SSH server, while using SSH keys requires the user to possess a private key corresponding to a public key listed in the authorized_keys file for the account in question. How is this not more secure? How is guessing a 1024-bit or 2048 bit private key as easy as running a dictionary attack? - padraic2112, on 04/02/2009, -1/+2> He could have accidentally uploaded it, he could have accidentally left a share
> open, or he could have let someone use his computer. There are any number
> of means that someone could have obtained that private key file.
> His machine could have been compromised by a trojan and when someone
> realized that this person might be important they scanned the machine for
> private key files.
> It is an exceptional scenario, but one that can happen to *anyone*.
It is not an exceptional scenario; or rather, any security intrusion *is* an exceptional scenario because it's not the norm. Not norm = exception.
That said, this even demonstrated that Fedora had some egregiously horrible security procedures in place. "We've fixed it" is not a terribly encouraging response.
> Nobody cares about security until you have an infiltration.
You do not have this luxury if you are in a position of transitive trust. You can stop caring about security when nobody depends upon your systems. For something like this to happen in an organization that provides packages to other people is inexcusable, period. - ArrangedEntropy, on 04/02/2009, -1/+1dugged for a FredLUG'er.
- Azathothh, on 04/03/2009, -3/+2ahah Linux as pwned!
- Eurynom0s, on 04/02/2009, -11/+10Ironic that a Linux group had their security compromised.
- ScottyMcBaggs, on 04/02/2009, -4/+2HAHAHA no passwords on SSH keys. SSH keys are either for secure automation of processes (and by secure I mean /bin/bash is not the shell) or two factor authentication to your boxes. This key existed on the other hand for pure laziness it looks like.
- qwertydvorak, on 04/02/2009, -9/+5i thought linux was perfect. at least that was the hype...
- amoore2600, on 04/02/2009, -7/+2why is this news, it happed in 2008...
- spiki, on 04/01/2009, -35/+1First post.
Well, yes. Lame. Dugg me down.
Browsing Digg on your phone just got easier with our enhancements to the 
© Digg Inc. 2009
— Content created and posted by Digg users is