FreeBSD Project Discloses Security Breach Via Stolen SSH Key 86
An anonymous reader writes "Following recent compromises of the Linux kernel.org and Sourceforge, the FreeBSD Project is now reporting that several machines have been broken into. After a brief outage, ftp.FreeBSD.org and other services appear to be back. The project announcement states that some deprecated services (e.g., cvsup) may be removed rather than restored. Users are advised to check for packages downloaded between certain dates and replace them, although not because known trojans have been found, but rather because the project has not yet been able to confirm that they could not exist. Apparently initial access was via a stolen SSH key, but fortunately the project's clusters were partitioned so that the effects were limited. The announcement contains more detailed information — and we are left wondering, would proprietary companies that get broken into so forthcoming? Should they be?"
bsd updates for the linux challenged (Score:5, Informative)
Access via ssh key, someone may have changed the tree
If you only use base release, power down and anti-freeze
For package add post 9/16, SVN and confirm you're clean
FreeBSD Security team (Score:3, Informative)
Really do seem to know what they're doing, and are very proactive with their security.
I'm glad they openly announced this, how to deal with the breach for end-users, and also how they're dealing with it. (This coming from a proud FreeBSD server and desktop user)
(yes I use the Oxford comma.)
In the UK it is a requirement (Score:5, Informative)
...that any company which holds personally identifiable information (so that's all of them - it goes from CRM databases to employee records and payroll) has a Statutory obligation to register Company details with the Information Commissioner's Office and to report any breaches to the Information Commissioner [ico.gov.uk].
For the definition of "breach", read: lost or stolen mobile phone, laptop, notepad, application or registration document, tablet, audio recording, video capture, or any other method, known or unknown, of recording personally identifiable information.
Re:Let this be a lesson to the SSH key advocates! (Score:5, Informative)
From a recent security audit I participated in, you are mistaken. The number of SSH keys that were _not_ passphrase encrypted, in a typical multi-user environment, vastly exceeded the number that were encrypted. These keys were stored on an unsecured NFSv3 environment, and on poorly secured backup tapes. This configuration is common, and we even found several github and Sourceforge SSH keys for known participants in open source projects there.
While the number of security errors in those environments were quite large, they're quite commonplace. They are partly the result of the fact that SSH servers have no way of restricting users to the use of passphrase protected keys, and SSH key generators, especially those in the OpenSSH codebase, do not enforce the use of passphrase protected keys. (They issue a warning, but do not enforce the use of passphrase.) There are certainly tools available to help manage passphrase protected SSH keys. but even where available, they remain rarely used.
This is compounded by the lack of effective centralized management tools for SSH key access, and the nonexisting or recently implemented and rarely used expiration or revocation technologies for SSH. SSH should only be considered robust for protecting individual sessions from decryption. Its "key" technology should not be considered a robust authentication technology due to these commonplace flaws.
There are better general authentication approaches: SSH, both OpenSSH and SecureCRT's tool suites, now offer Kerberos authentication. This is a much safer technology, not vulnerable to the various "stolen passphrase free key" issues of normal SSH. Unfortunately, I've not seen any way for it to mesh well with SSH configurations that rely on the "ForceCommand" option being tuned for individual users and their SSH keys, especially source control technologies such as the "git" and "Subversion" and "CVS" access at Sourceforge.
Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (Score:5, Informative)
And so, when Microsoft gets raped by a bunch of hackers you think they are going to let the public know?
No, they are going to keep it under wraps.
No, they are *not* going to keep it under wraps, at least not if the break-in puts its users or customers at risk.
The reason is simple: Microsoft is required by law to disclose [proskauer.com] any such breach. The penalties for "keeping it under wraps" are severe and could include paying restitution/punitive damages to each individual customers/user.
But don't let such minor detail stand in the way of spewing your MHD [slashdot.org] all over slashdot.