Linux Foundation, Linux.com Sites Down To Fix Security Breach 101
An anonymous reader writes "All Linux Foundation sites seem to be down due to a security breach, which occured on 8 sep. (according to a notice displayed on the site)." From the email I received this morning, sent to all Linux.com and LinuxFoundation.org users: "On September 8, 2011, we discovered a security breach that may have compromised your username, password, email address and other information you have given to us. We believe this breach was connected to the intrusion on kernel.org. As with any intrusion and as a matter of caution, you should consider the passwords and SSH keys that you have used on these sites compromised. ... We have taken all Linux Foundation servers offline to do complete re-installs. Linux Foundation services will be put back up as they become available. We are working around the clock to expedite this process and are working with authorities in the United States and in Europe to assist with the investigation."
SSH keys? (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why would you do that?
Maybe in case you'd need to scp large files from linux.org to kernel.org and vice-versa, without having to first download them to your home machine, and then upload them to the target (slow, if you've got asymetric DSL)
Of course, dumb users not aware of security implications is also a possible explanation (less likely though, as dumb users would probably not be aware of ssh authorized_keys in the first place...).
In both cases, it is smart of the Linux Foundation to warn their users of this potential issue
Re: (Score:2)
However, in case of a compromise, you'd still need to remove trust in the private key of the impacted machine (so if kernel.org got hacked, you need to remove your old kernel.org's public key from your ~/.ssh/authorized_keys on linux.org)
Also, if the hacker got kernel.org's /etc/ssh/ssh_host_rsa_key, then he could theoretically later on mount an MITM attack against kernel.org... so the kernel.org admi
Re: (Score:1)
That being said, it's important to use a different private key on each machine where you might ssh from...
Hell yes, and for key management sanity it is good to use a clear comment on keys so you know what they are for.
However, in case of a compromise, you'd still need to remove trust in the private key of the impacted machine (so if kernel.org got hacked, you need to remove your old kernel.org's public key from your ~/.ssh/authorized_keys on linux.org)
You also have to rebuild authorized_keys to check that no new or modified keys have been added. That would allow the hackers right back in at some future time. I keep a copy and cksum of authorized keys for every machine where I use keys, just so I can check. Yes, I'm paranoid.
Also, if the hacker got kernel.org's /etc/ssh/ssh_host_rsa_key, then he could theoretically later on mount an MITM attack against kernel.org... so the kernel.org admins better change that one as well (while publishing the new key's fingerprint on an SSL server).
I don't know if that's the case, but they could certainly set up a fake server if they have your public key and the server
Re: (Score:2)
That's why there is -A option for ssh.
Re: (Score:1)
Dumbass is right. That's why OpenSSH has agents (and the ssh agent does NOT expose your key, it does all crypto and returns just the result). SSH private keys should NEVER leave your own box. You don't reuse openssh keys, either. It is one private key pair per host.
That would not have saved HPA's keys since his laptop was the entrypoint of the kernel.org breach, but if some people were not lazy assholes, there wouldn't be any private keys on kernel.org, except for some automated tasks (which have to be
Re: (Score:2)
Why shouldn't I re-use my ssh keys? I'm pretty clear on all your other points so I assume that you've got a good reason for this. What is it?
I feel that I may have mis-understood the proper use of SSH keys and would really like to know the attack vector here.
Re: (Score:1)
I once had a co-worker who was as stupid to do that, so I immediately blacklisted his key on every machine on the corporate network and told him to generate a new one and keep the private part to himself. I sincerely hope any sane IT dept. will do the same in that event.
It's almost as stupid as emailing the root password in the clear for the new dedicated server you've ordered. Mail me the host key fingerprint, I'll mail you my public key. How hard can it be?
Re: (Score:2)
The statement that I was in disagreement with was "You don't reuse openssh keys, either. It is one private key pair per host."
Bullshit unless there is something that I'm missing. Keep one private key / public key pair and use the public key on all things you want to access. Keep the private key private (read: in a private place, encrypted. As is traditional.)
Is there some problem with re-using your public key on several servers? I think not.
Re: (Score:1)
Yes, you are correct. Nothing wrong with the same public key on 100+ servers.
Though I can also relate to having a separate key pair for internal servers and another for customer servers. That way, when you use an agent and unlock a key you don't unlock every server you ever have to manage anywhere. Especially when you have a multitude (say, 5 at max) of key pairs for that purpose.
Re: (Score:2)
It is an unfortunately common case that people copy/create private ssh keys on servers to login (or scp) from those to another remote host. These keys are of course compromised.
Re: (Score:2)
I don't see why having private keys on a server would be less secure than having these on your laptop/phone, which is much easier to steal or borrow...
My laptop is only vulnerable to theft by people I am in physical contact with and is generally my responsibly to secure while connected to the Internet. Placing SSH keys on a server means I'm giving these keys and any access they grant to the admins of said server and am placing my trust in them to keep them secure. This is fine for automated trust relationships between hosts but not generally a good idea for personal keys.
Re: (Score:2)
Well, you'd still need keys on your laptop to get to the server. So now you have two places where your keys can be stolen and used to login everywhere you trust your keys.
For the case where you actually do need direct communication between two servers you probably want to do agent forwarding instead of having more keys in your authorized_keys. Remember that every single entry there is a point of failure, and any one of them getting compromised means that your account is likely to get owned.
Now there are spe
Re: (Score:2)
It is an unfortunately common case that people copy/create private ssh keys on servers to login (or scp) from those to another remote host. These keys are of course compromised.
There is no requirement to do that. You can just create a tunnel through the first server to the second (ssh -L). Then you connect to the tunnel port on localhost, and you never had to give away your private key. You're even safe if the server in the middle gets compromised.
Re: (Score:2)
Also - don't forget, if someone has your public key (and has compromised the server's key), they can impersonate the remote end and go for a man in the middle attack.
Re: (Score:2)
I don't see any reason to exonerate either of those, but you need to widen your focus. You should include numerous governments (or their agents, perhaps acting without authorization). You should also include groups of criminals, like the Russian Mafia. Then there's folks just out for lulz. etc.
Some of these may be more likely than others, but don't narrow your focus too much. Not without reasonable evidence.
Re: (Score:1)
Re: (Score:2)
I wouldn't go that far. Sounds more like a few attacks on high profile public systems that just happen to host linux projects.
Re: (Score:1)
More Info, and Announcement Content (Score:5, Informative)
A few more details of the breach, including the content of the message from the Linux Foundation, can be found on ITWorld [itworld.com].
LinuxScribe
Re: (Score:1)
The information I really want to see is a statement clarifying this as either technical as in a failure of the security software somewhere, or administrative, as in someone left something open through error or poor security design choices.
It's important to know if this is a bug which is on all Linux systems, or someone made a human error.
Lucky (Score:2, Interesting)
The attack that compromised some high-value servers belonging to kernel.org — but not the Linux kernel source code — may have been the work of hackers who simply got lucky and didn't realize the value of the servers that they had gotten their hands on [slashdot.org].
Sure.
Connection? (Score:2)
Re: (Score:2)
Re: (Score:2)
Those are just pubic facing servers, not the dev team's workflow boxes. However, even if they were their source code management tool, git, exposes every change made by anyone for all time. It is simply that nature of git. Check it out if you want details. Even if they didn't use git the maintainers and anyone with clean copies (per-breach) can simply run a diff on the source code vs any new "untrusted" copy they may see.
Since they've made the breach public and the aforementioned steps to detect any modifica
Re: (Score:2)
Mod -1 Troll
Seriously?
Re: (Score:3)
Do you ever post anything other than instructions on how to mod other posts?
Re: (Score:2, Offtopic)
Re: (Score:1)
Re: (Score:1)
Follow the money. Who stands to gain from creating fear, uncertainty, and doubt surrounding Linux and it's related organizations?
Exactly! The folks at BeOS!!!!
Re: (Score:2)
Follow the money. Who stands to gain from creating fear, uncertainty, and doubt surrounding Linux and it's related organizations?
Exactly! The folks at BeOS!!!!
BeOtcheS. BeOtcheS love FUD.
Re: (Score:2)
Mod -1 Troll
Learn to use the '. Oh no - you're right. You are Ill.
Re: (Score:2)
Still some margin...
Re: (Score:2)
Breaches: Linux 1, Windows 2317
That's the problem. Complacency? Ignorance? Denial? Or just another bash on Windows?
Re: (Score:2)
That's the problem. Complacency? Ignorance? Denial? Or just another bash on Windows?
Bash on Linux, actually.
Re: (Score:2)
This wouldn't have happened with OpenBSD! (Score:1)
This is the right way to do it (Score:3)
Assume everything is compromised unless you can prove otherwise and get the staff in on overtime to reinstall from scratch.
Re: (Score:2)
Re: (Score:1)
Try "rpm -qil "
You don't get it. (Score:1)
You don't get it. The difference is Microsoft is a giant multi-billion dollar corporate machine with an insane marketting and advertising arm that helps them get into places that Linux simply can't because of lack of finances. If a well-funded corporation slips up its schadenfreude because 'even with all that' they still couldn't get it right. While Linux enjoys SOME corporate backing, its still largely a labour of love by independant developers. Most people side with the little guy. ;-)
Re: (Score:2)
Re: (Score:2)
I think you're the one who doesn't get it. Linux is ubiquitous, and has been for several years, in the enterprise server world. Granted, the post you responded to was a bit of a troll, but you've missed an important point.
You can bark all you like about the marketing strength of Microsoft, but the CSO doesn't much care about marketing if the FBI comes visiting because you just self reported a hack and your company is an enormous financial institution, has millions of health records on file, or is part of th
Linux fail security? (Score:1)
SSH Keys Compromised? (Score:2)
How could an attacker getting hold of the public key "compromise" anything? It doesn't contain any personal information, and -- barring an earth-shattering breakthrough in cryptanalysis of RSA (or DSA, if you chose a DSA key pair) -- it can't be used to gain access to anything, not even the system it was stolen from.
That's the whole point of using asymmetric cryptography for authentication!
Re: (Score:2)
Re: (Score:2)
You're assuming only public keys were compromised. If they had private keys enabling login to other hosts stored on said systems (yes, retarded, but...) then those keys are compromised.
A little more than retarded... in order for someone to do that they'd have to have never heard of ssh-agent.
Re: (Score:2)
ssh-agent leaves an active and unlocked ssh-key available on the relevant server. Many of my colleagues refuse to run their ssh-agent as part of their own persoanl host's working environment, and prefer to host them on their most used server, despite my warnings. Others find ssh-agent burdensome and simply use passphrase-free keys, and there is not yet any graceful way to prevent that except to audit for them on the client hosts, which is awkward and intrusive.
Re: (Score:2)
Microsoft doesn't need to resort to this sort of thing to demonstrably kick linux's arse in the market place (i've been waiting for year of the linux / unix desktop since 1995).
More likely, its some random spammer / organised crime group looking for either a well connected site to launch DDOS from, or to insert malware into the linux kernel for spambot purposes.
Or a script kiddie doing it for bragging rights.
The Joker In The Deck (Score:2)
I haven't seen anyone talking about the elephant in the room: Just who would stand to profit from manufacturing FUD surrounding Linux as a result of security breaches?
Alfred Pennyworth: A long time ago, I was in Burma...working for the local government. ... One day I saw a child playing with a ruby the size of a tangerine. The bandit had been throwing them away.
Bruce Wayne: Then why steal them?
Alfred Pennyworth: Because he thought it was good sport. Because some men aren't looking for anything logical, like money. They can't be bought, bullied, reasoned or negotiated with. Some men just want to watch the world burn.
ssh keys compromised? (Score:1)
"you should consider the passwords and SSH keys that you have used on these sites compromised."
How the heck can ssh keys compromised by this breakin? Doesn't the site just have access to the developer's public key? With a sufficiently large ssh key (say 1k or 2k) how is anyone going to derive the ssh private key from the public key? The fact that if is effectively impossible is supposed to be the whole point of public key encryption.
Re: (Score:1)
THEIR host keys and everything that can be decrypted using those keys.