Linuxfoundation.org also hacked | Hacker News Reader

Linuxfoundation.org also hacked

linuxfoundation.org

50 pointsKonradKlause21 comments

My bet is we are going to see more and more of this, as fallout from the kernel.org crack.

Kernel.org said "Don't worry about linux, the source tree is in git and tamper-proof. All they messed with was SSH. It was amateur, really." (Some paraphrasing.)

Well, a modified SSH could easily log interesting details that pass through it. So if you used [ed: gpg] private key forwarding, the crackers have your private key. [ed: See http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#se... for the SSH vulnerabilities.]

The only question is how fast the attackers have moved. Blitz all the servers at once, or try to carefully lay something individually tailored and undetectable. It's been long enough for either.

edit: Erroneous simplification, sorry. The attacker could imitate you on the remote system. This is not the same as having your ssh private key (my bad) but the result is the same. The third party server you connected to through kernel.org is compromised.

edit edit: But check your gpg keys! Gpg signing does require the full private key on the remote system. If you signed any files on kernel.org with forwarding, they could have your gpg private key. (Though this might need modification to gpg, which was not mentioned by kernel.org.)

Is that true? I didn't think private key forwarding was vulnerable to a MITM like that.

I don't have the details, but a modified SSH client could be modified to leak the private key. A modified ssh server can't, since the server never gets the key.

Additionally, from this article: http://www.linuxfordevices.com/c/a/News/Kernelorg-hacked/

"Phalanx variants have attacked sensitive Linux systems before by stealing SSH keys to access servers and exploiting kernel vulnerabilities."

Sort of. See http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#se... for more details.

I left out a few steps, but at the very least the system you connected to through kernel.org could be compromised.

When using SSH agent forwarding, your private key is absolutely not compromised if the host you connect to is compromised. All that happens when forwarding is that a socket is set up so that the forwarding host can proxy any authentication actions back to your home host (the one with the private key).

The root user on the forwarding machine should be trusted because they can monitor the contents of the agent socket while your connection is active, being able to eavesdrop on communications, but since your private key never leaves your own host, there's no way it could be leaked.

The fact that your private key is never transmitted is one of the core strengths of asymmetric keys. Did you think you were leaking your private key to any server you SSH'd to?

Hum, I think you're missing some detail too. When agent forwarding is active, root can use that listening socket to authenticate evil connections while you're logged into that machine. I'm actually surprised OpenSSH doesn't yet print a large warning when you go to connect and forwarding is enabled.

All Mallory must do is rifle through your known_hosts (or bash_history if hashing is enabled), wait for you to connect, then su to your account, fix up the environment, and SSH to some boxes of yours, and update your authorized_keys there to let him connect while you're offline, or starting up a quick background netcat and disconnecting.

This requires no magic tools, and syslog/lastlog on the remote machine won't show much of interest, especially if you're like me and rely on logging in multiple times "quickshot" to remote hosts, except for remote host names the lastlog is basically unreadable already.

I'm actually surprised OpenSSH doesn't yet print a large warning when you go to connect and forwarding is enabled.

agent forwarding is not enabled by default, so if you've turned it on, you should know what you're doing. it should only be enabled in ~/.ssh/config per-host, for hosts that you trust.

you should also enable confirmation in ssh-agent so that whenever a key is used, you must manually confirm it. it will prevent attacks like this where another user on a compromised machine will use your agent to login to another machine.

i wrote about doing this on osx, but it works similarly on any other platform - http://jcs.org/macssh

Nice approach, modulo the usual problems with dialogs popping up while you're typing (it seems spacebar would confirm that dialog in your post).

I no longer use agent forwarding. For config changes I prefer keeping "smarts" close to home and away from production, and in most cases do dumb pushes via rsync/SSH, rather than those machines ever having direct access to revision control, etc.

That assumes, say, users not inheriting ~/.ssh/config files, or having one configured for them by a site administrator.

Just because a configuration needs to be added to a file doesn't mean that everyone using that config has added it themselves, or understands the implications.

Seems that an agent notification of auth requests would help mitigate some of the risks here.

You don't actually send your private key to the server during authentication, the server asks you to sign a random value with your private key, which never leaves the safety of your computer. If this value can be restored using the public key, then you are authenticated.

Since the private key never left your computer, it is impossible to compromise the private key on the server side.

Who stands to gain from an attack on linuxfoundation.org and kernel.org?

My guess is the same people who stand to gain from knocking over mailboxes.

Driver's ed students?

He's probably referring to people who purposely whack mail boxes with baseball bats out car windows.

So presumably drunk highschool football players.

Thats a question i asked myself why go after the opensource world.

But its probably only for the "fame"

---

"Normally if you were to target a high-value target you would potentially use something that's more more tailored to your specific target, something that's not going to be flagged or potentially detected," said Oberheide. It was not likely the attackers were after the source code, or they would have performed the attack differently, he added.

http://www.linuxfordevices.com/c/a/News/Kernelorg-hacked/

Et tu, BSD?

The hackers didn't realize that they had compromised such important boxes; the attack just kept trying to spread itself. There are nearly 500 users on k.org, and not all of them are security-minded.

kernel.org has been down now for three or four days now. Seems there is more to this hack than we've been told. For awhile kernel.org just didn't respond to requests, then they put up this maintenance page:

http://kernel.org/

Quote: "...you should consider the passwords and SSH keys that you have used on these sites compromised. If you have reused these passwords on other sites, please change them immediately"

Did they really store clear text passwords? Or perhaps I'm misinterpreting the announcement?

It's unlikely they stored plaintext passwords. That doesn't mean that the attacker couldn't crack the hash.

More importantly, if the hacker modified the ssh binary then they could make it retransmit passwords before hashing them. Once the attacker has such a high level of access to the system it doesn't matter if the system has otherwise sound security; that security can simply be removed or altered.

I think the announcement is made as it is because it's far safer to assume the worst than the most likely or best. Even if your keys and passwords aren't compromised it doesn't hurt to change them.

Linux.com is also down with the same message.

Reply on news.ycombinator.com