SourceForge.net : Hacker's Target

[Bonie81]

SourceForge.net : Hacker's Target

Excerpts from SourceForge blog:
Link to Full report : http://sourceforge.net/blog/sourceforge-attack-full-report/


Attack Description

The general course of the attack was pretty standard. 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. Our network partitioning prevented escalation to other zones of our network.

This is the point where we found the attack, locked down servers, and began work on analysis and response.
Immediate Response

Our first action response included many of the standard steps:

* analysis of the attack and log files on the compromised servers
* methodically checking all other services and servers for exploits
* further network lockdown and updating of server credentials
Service shutdown

Once we knew the attack was present, we locked down the impacted hosts, so that we could reduce the risk of escalation, from those servers to other hosts, and prevent possible data gathering activities.

This strategy resulted in service downtime for:

* CVS Hosting
* ViewVC
* New Release upload capability
* ProjectWeb/shell
Password invalidation

Our analysis uncovered (among other things) a hacked SSH daemon, which was modified to do password capture. We don’t have reason to the attacker was successful in collecting passwords. But, the presence of this daemon and server level access to one-way hashed, and encrypted, password data led us to take the precautionary measure of invalidating all SourceForge user account passwords. Users have been asked to recover account access by email.
Data Validation

It’s better to be safe than sorry, so we’ve decided to perform a comprehensive validation of project data from file releases, to SCM commits. We will compare data agains pre-attack backups, and will identify changed and added. We will review that data, and will will also refer anything suspicious to individual project teams for further assessment as needed.

The validation work is a precaution, because while we don’t have evidence of any data tampering, we’d much prefer to burn a bunch of CPU cycles verifying everything than to discover later that some extra special trickery lead to some undetected badness.

* - * - *

Further more, I have noticed that most of the open source software revisions @ Sourceforge have being published without any MD5, SHA-1 or SHA-256 checksum. If any of MD5, SHA-1 or SHA-256 checksum is published along with software revision, it would be easy to figure out alterations. Small checksums.txt should be included in ZiP or 7z archives and should also be published on web-sites. Same applies to beloved VideoHelp too!