Sourceforge Attack: Full Report | Hacker News Reader

Sourceforge Attack: Full Report

sourceforge.net

38 pointsbilliob12 comments

I don't see how this is a 'full report'. For example:

> There was a root privilege escalation on one of our platforms which permitted exposure of credentials that were then used to access machines with externally-facing SSH.

How are the credentials exposed after escalation? What accounts on the externally-facing SSH machines were used? Why was it a problem that the externally-facing SSH machines could be accessed? Was the access through root accounts? Why do externally-facing SSH machines allow remote root-login?

Besides, why can I still download projects when the data validation is still ongoing?

Furthermore, the 'full report' does not say anything what SF.net plans about their ssh servers.

I understand the SF.net team does its best, but I am not so happy with that report.

What I really want is a list of compromised projects. They say it takes time to verify that, but I really hope they keep us posted.

Well, there's enough for an educated guess. My own reading was "someone used a root privilege escalation to ferret out ssh private keys, and then used them to log into our cloud as the admin with the compromised key." (I don't see an implication that ssh itself was configured to allow root access.)

But there are other open questions --- the two of most interest to me are:

What was the root privilege escalation that coughed up the credentials in the first place, and could the attacker have used it to do something else?

Also, what was the extent of the compromised "zone", and how sure are they that the network partitioning held?

Sorry, but this is ridiculous:

"Our analysis uncovered (among other things) a hacked SSH daemon, which was modified to do password capture. We don’t have reason to [believe] the attacker was successful in collecting passwords."

You don't have reason to believe they weren't either. Why write this?

Perhaps one would have expected log entries or an updated atime?

Someone has root. Everything on the system can't be trusted.

The assumption should be the opposite, by default.

There's a difference between digital forensics and "the virus scanner says it's clean, let's start loading the credit card data". As a forensics statement, this makes perfect sense - and note that they (say they) have reset all passwords, so it's not like they rely on this.

i can verify that i received a password reset email from sourceforge on saturday, that explained there had been an attempt made to get at the passwords, and that rather than wasting time speculating on if they had been compromised, they were just doing a system wide password reset.

The logs may (should) be on a separate loghost, which is otherwise isolated from the machines it's servicing. Assuming this is the case, and those logs show no evidence of further penetration, that's evidence in favor of the conclusion that the damage was contained. However you're right, once an attacker has root it's very hard to take anything at face value after the fact.

Interesting read, both regarding the attack vector, actual damage and their current plans to get everything back up and running.

The number of people whining about CVS support possibly being deprecated is amazing, get with the 21st century people.

What's especially depressing is how many people let Eclipse support determine their source control strategy. IDE FTL.

Reply on news.ycombinator.com