Venerable BSD-based operating system FreeBSD has announced a smallish system compromise.
The FreeBSD administrators took a bunch of servers offline to investigate, and published a blow-by-blow account of what they know about the breach so far.
FreeBSD isn’t the first open source operating system to suffer an intrusion on its core servers.
In this case, however, the FreeBSD crew and their users don’t seem to have suffered too badly.
None of the so-called base repositories were touched – that’s where core components such as the kernel, system libraries, compiler, core command-line tools and daemons (server software) reside. Only servers hosting source code for third-party packages were affected.
Fortunately, the investigation so far hasn’t turned up any software packages that were Trojanised by the intruders. So the knock-on effect of the break-in will probably turn out to be minimal.
The official reason is given as a likely compromise of a developer’s SSH key.
SSH, or secure shell, is the predominant remote-access protocol for non-Windows systems.
It supports a range of authentication schemes; on many systems, administrators do away with across-the-wire usernames and passwords, and opt instead for authentication based on public/private key pairs.
The idea is that I generate a key pair and send you my public key.
After verifying carefully that it really is my key, e.g. with a phone call, you upload my public key to your server. My SSH client can then use my private key to log me in; your server uses the corresponding public key to verify my identity.
Since my private key is itself protected by a password (or ought to be), we continue to enjoy the benefits of password-based security – plus the advantage that knowing my password alone is not enough for an attacker. He needs a physical copy of my private key file, too.
In this case, it sounds as though the attacker did manage to steal both authentication factors – key file and password – from the developer.
This is a hearty reminder that a chain is only as strong as its weakest link.
In particular, never forget that the security of your internal systems may very well be no better than the security of any and all external systems from which you accept remote access – whether those are servers, laptops or even mobile devices.