Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FreeBSD Project Discloses Security Breach Via Stolen SSH Key

timothy posted about 2 years ago | from the happy-transparency dept.

Security 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?"

cancel ×

86 comments

Sorry! There are no comments related to the filter you selected.

CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (-1)

Anonymous Coward | about 2 years ago | (#42011763)

i read it in a slashdot comment so u kno its tru!!!11

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (-1)

Anonymous Coward | about 2 years ago | (#42011773)

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.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (-1, Flamebait)

overmoderated (2703703) | about 2 years ago | (#42011793)

Microsoft users get raped everyday. It's called a botnet.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (-1, Flamebait)

Jeremiah Cornelius (137) | about 2 years ago | (#42012505)

The last 5 users of FreeBSD have agreed to purge the key from their key-rings, and new fingerprints will be exchanged by express delivery of a single USB key among the participants.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (1)

RockDoctor (15477) | about 2 years ago | (#42021285)

The last 5 users of FreeBSD

and you makes 6.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (5, Informative)

benjymouse (756774) | about 2 years ago | (#42012773)

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.

You found a law which MS would never violate? (0)

Anonymous Coward | about 2 years ago | (#42014751)

O RLY?

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (1)

Anonymous Coward | about 2 years ago | (#42014767)

You probably should have read this...

"requiring notice to individuals when the security of their personal information has been compromised"

Those laws have nothing to do with a security breach of this sort if their own personal information isn't stored on the machine as well and in this context, the only people who would be notified **might** be the people writing the code. .

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (0)

innerweb (721995) | about 2 years ago | (#42016151)

LMAO!!! Microsoft following the law because here are potentially serious fines. Where have you been for the past 30 years?

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (0)

overmoderated (2703703) | about 2 years ago | (#42011783)

I think you are on the wrong site. You probably need slashtroll.org.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (2)

Bill, Shooter of Bul (629286) | about 2 years ago | (#42012693)

Although this is a troll, there still is an unanswered question: how did the ssh key get stolen? While its nice to see that FreeBSD wasn't breached due to a vulnerability in *its* systems, someone obviously had a vulnerability in their system. To all the sysadmins out there, I think that's what keeps you up at night: How do you ensure that your users safeguard their secrets? Other than a "corporate policy" document imploring them to use "good judgement"?

Especially with BYOD coming into vogue, I think the security community needs to come up with a solution that is cross platform and easy to implement, verify and enforce.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (3, Insightful)

icebike (68054) | about 2 years ago | (#42014671)

[t]here still is an unanswered question: how did the ssh key get stolen? While its nice to see that FreeBSD wasn't breached due to a vulnerability in *its* systems, someone obviously had a vulnerability in their system.

The explanation is simple enough, and provided on the compromise notice:

The compromise is believed to have occurred due to the leak of an SSH key from a developer who legitimately had access to the machines in question, and was not due to any vulnerability or code exploit within FreeBSD.

It only takes one instance of walking away from your workstation leaving it running to have a co-worker slip into your chair and email your .ssh directory to some obscure off shore email address, then remove the outgoing email from the "sent" list. A stolen phone, a purloined laptop, the possibilities are endless, although in the latter two instances you would expect revocations to be issued (assuming you had a backup copy somewhere)..

Once someone has your private key they ARE you, and it it was done without being immediately discovered, the key could linger in the wild for months or years.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (0)

jep305 (1288822) | about 2 years ago | (#42021669)

"Once someone has your private key they ARE you"

Only if you're such an idiot that you don't passphrase protect your private key.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (1)

jep305 (1288822) | about 2 years ago | (#42021651)

This is a very good point. One dumbass user who doesn't keep a passphrase on his private key, doesn't encrypt his hard drive, etc. and bam, you get hosed.

If you're on a current OpenSSH (as available in Red Hat 6.3 at least, or its rebuilds like Scientific Linux or CentOS), you can require both key and password auth. From the release notes at https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.3_Release_Notes/index.html#id3199604 [redhat.com] :
"SSH can now be set up to require multiple ways of authentication (whereas previously SSH allowed multiple ways of authentication of which only one was required for a successful login); for example, logging in to an SSH-enabled machine requires both a passphrase and a public key to be entered. The RequiredAuthentications1 and RequiredAuthentications2 options can be configured in the /etc/ssh/sshd_config file to specify authentications that are required for a successful log in."

To implement on an SSH server where only SSH protocol 2 is allowed, drop this in your /etc/ssh/sshd_config:

        RequiredAuthentications2 publickey,password

You need to specify PasswordAuthentication yes as well, or you'll be told: "Invalid required authentication list"

Once you set it up, restart your sshd daemon, and you will be good to go.

Nothing's foolproof however, and I mean that in the literal sense of the word "foolproof". Some fool can store his password in plain text on the same system as his key, write his password on his computer in Magic Marker or whatever, and you're screwed again. Allowing SSH access to morons is a major security hole.

Re:CAN'T BE TRU! OPEN SORCE IS MOAR SEKURE!!!11 (0)

Anonymous Coward | about 2 years ago | (#42015873)

Ad hominem attacks are in bad form but you, truly, are an idiot. Fairly young too, I'd bet.

bsd updates for the linux challenged (4, Informative)

alphatel (1450715) | about 2 years ago | (#42011771)

If you run on freebsd, examine your tar and tar.gz
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

Re:bsd updates for the linux challenged (1, Funny)

TheGratefulNet (143330) | about 2 years ago | (#42012131)

uhm, burma shave??

(good effort)

Re:bsd updates for the linux challenged (0)

Anonymous Coward | about 2 years ago | (#42015269)

Is it common for BSD users to be unable to express thoughts properly?

Forthcoming... (4, Insightful)

QuietLagoon (813062) | about 2 years ago | (#42011789)

and we are left wondering, would proprietary companies that get broken into so forthcoming?

I suspect most would not be so forthcoming.

Should they be?"

Yes.

Re:Forthcoming... (2, Interesting)

Anonymous Coward | about 2 years ago | (#42011865)

They wouldn't be until they were forced to due to possible leaking of customer data. I don't blame them, I've worked at a company whose ad servers got hacked and used to spread malware causing customers of ours to be blocked by google. After fixing the compromised servers we got contacted by some of our customers and had to lie (blame 3rd party) not to lose them.
Another thing, companies rarely go after the hackers, even if they're dealing with total scriptkiddies (which is usually the case). While patching our servers we left certain parts of the hackers webshell active but rewrote it so he had no actual access to the system and we would get notified instead. We already had his IP from the server logs and it was consistantly the same IP originating from a customer dsl line in Russia. After patching this same IP tried connecting several times.
So what do you do next? Nothing.

Re:Forthcoming... (0)

Anonymous Coward | about 2 years ago | (#42012171)

Had to lie not to lose them? The popel at that company fucked up and should lose them.

Re:Forthcoming... (1)

UltraZelda64 (2309504) | about 2 years ago | (#42015709)

If you had to lie about a security issue, you should immediately lose all trust and your company should immediately go out of business. Simple as that. Especially sleazy fucking advertising companies, which already tend to be some of the worst culprits.

Worthless, lying, malware-serving companies such as your own are exactly the type I make every attempt to block in every major way possible (cookies, scripting, advertisement images, etc.). Of course, I don't discriminate--I block them all; none of their business is wanted, nor are any of them trustworthy--but its companies like your own that are potentially the most, *ahem*, malicious.

for the butterfingers of SSH, silence is golden (2)

epine (68316) | about 2 years ago | (#42012955)

and we are left wondering, would proprietary companies that get broken into so forthcoming?

No, we are not left wondering (unless one thinks that FreeBSD has a patent on especially leaky SSH developer keys) so instead we pretend that we are left wondering to justify hanging around and scribbling on the bathroom wall.

If Apple can't keep their mitts on an iPhone prototype and Google can't keep their mitts on a Nexus prototype, do you really think these butter-finger organizations have any better control over their developer's SSH keys?

FreeBSD Security team (3, Informative)

Anonymous Coward | about 2 years ago | (#42011795)

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.)

Re:FreeBSD Security team (1)

Tastecicles (1153671) | about 2 years ago | (#42011903)

Completely OT; I agree with your usage of the Oxford here, however I tend not to use it unless omission would cause obvious confusion.

Re:FreeBSD Security team (1)

TheRaven64 (641858) | about 2 years ago | (#42017989)

Really do seem to know what they're doing, and are very proactive with their security.

The security team and cluster admin has also been working very hard over the past few months to partition the FreeBSD cluster a lot better. If this attack had happened in a month or two, you wouldn't be hearing about it because nothing of value would have been compromised. The attack was against the legacy package building infrastructure, which is due to be retired soon. It was able to get access to more systems because it had the developers' home directories mounted (this isn't be the case with the new system, which is completely isolated). They're also rolling out the new audit logging daemon, which should mean that this sort of thing would be detected much sooner in the future.

We were lucky. The attackers seemed not to know what they'd found. There was an (apparently) automated scan for ssh keys (which have now all been revoked) and that's about it. They seemed to be trying to add the machine to a botnet, rather than to attack it directly. We believe that they got access via a compromised developer VM which had an ssh key that connected to the cluster (for doing svn+ssh commits), so it's possible that it was an entirely automated attack. They attempted to run a load of Linux admin commands and apparently gave up when they didn't work. As far as we can tell, they didn't actually modify anything (although, of course, the compromised machines are offline pending imaging for forensic analysis and clean reinstalls or replacement, just in case). The announcement tells you not to trust any of the things that we know that they could have touched, but it currently looks like there's a very low probability that they did touch anything. For example, they might have modified ports / base cvs, but the top of the tree is identical to the svn tree (which had off-site backups, and has had every recent commit manually audited) and so they'd have had to insert something bad and then remove it in a subsequent CVS version, and that seems unlikely. Verifying cvs is pretty hard, which is part of the reason why we're encouraging everyone to move to svn now.

Short answer (5, Insightful)

wbr1 (2538558) | about 2 years ago | (#42011797)

"...and we are left wondering, would proprietary companies that get broken into so forthcoming? Should they be?"
Short answer:
No, they do not want to scare the stockholders.
and... Yes, they should be because openness allows people to recover or protect themselves faster.

Re:Short answer (1)

Anonymous Coward | about 2 years ago | (#42011925)

I wonder, is it insider trading if you openly and publicly give ALL the information you have on a break-in that you (the company) detected, see that the immediate reaction of the market is far out of proportion to the actual harm, and then buy stock like crazy in the company you work at, only to sell it at a large profit a few weeks later? Are there laws against that? Considering that you have not hidden any information, you simply believe that you have a better appreciation of that information as part of working at the company. In a sense it is a tax on easily spooked investors.

Re:Short answer (1)

Anonymous Coward | about 2 years ago | (#42012183)

That's precisely why there are requirements in some cases for executives of companies to file notices when they buy and sell certain stocks in advance. As long as those are followed then it is usually fine.

Re:Short answer (2)

celle (906675) | about 2 years ago | (#42012433)

"Are there laws against that?"

    There should be as it's a major conflict of interest that opens a lot of bad doors to stock manipulation. You shouldn't be allowed to use(play with) the stock of the company you are employed by unless you own the company lock, stock, and barrel thereby only shooting your own foot. Your described situation is technically insider trading.
      Are there laws, probably not. Legal responses, depends on who you piss off.

Re:Short answer (1)

shentino (1139071) | about 2 years ago | (#42012203)

Unless the shareholders decide to throw a short sighted tantrum and force a company's hand. a company should be aware of the very bad PR possible from being caught withholding this sort of information.

Tattling on yourself is good karma and protects you from being embarrassed later.

In the UK it is a requirement (4, Informative)

Tastecicles (1153671) | about 2 years ago | (#42011811)

...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:In the UK it is a requirement (1)

buchner.johannes (1139593) | about 2 years ago | (#42012651)

I believe this has already become a EU directive. If you lose person-related data, you have to make it known within 24 hours after becoming aware of it, otherwise your company faces fines. And the fines have been increased to make companies feel it.

Let this be a lesson to the SSH key advocates! (0, Troll)

Anonymous Coward | about 2 years ago | (#42011813)

Whenever the topic of password security comes up, there's always a few people who will go on and on about how SSH keys are so much more secure than passwords.

Yet these people rarely acknowledge that SSH keys are basically no different than the old password-on-a-sticky-note-behind-the-monitor technique. In fact, SSH keys may even be worse, as they are already in a digital form ripe for stealing. Some of them even portray SSH keys as the solution to almost every authentication and security woe that exists.

I sincerely hope that these SSH key advocates take this incident as a humbling experience. I hope they realize that the claims they're making just aren't valid. Perhaps the smart ones will apologize for their past transgressions, and will vow not to spread their nonsense in the future.

The FreeBSD developers are among the best there have ever been. They know software and computer security inside and out. But if something like this can happen to one of them, it can happen far more easily to any lesser computer user.

So, please, SSH key advocates, take this as a lesson. Let some good come out of it, and mend your ways. Please.

Re:Let this be a lesson to the SSH key advocates! (4, Insightful)

CRCulver (715279) | about 2 years ago | (#42011853)

You don't seem to be aware that SSH keys are typically encrypted, and still require a password to unlock. Yes, some people foolishly enable passwordless use of SSH keys, but that does not reflect on the principle of SSH key login in general.

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42011901)

Christopher Culver, you may be surprised at how many SSH keys in the real world do not have a password.

The "principle of SSH key login" is irrelevant in the real world. Maybe that crap flies nicely in academia, but not in reality. What matters is how they are actually used. That determines how well they perform in actuality.

As is clearly shown by this incident, they are far easier to compromise than you and the other SSH key advocates claim. You can go on and on all you want about how they're secure "in principle", but the reality is obviously so much different!

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42012333)

This idiocy deserves to be highlighted. You, dear AC, are a first class dumbass.

Re:Let this be a lesson to the SSH key advocates! (-1)

Anonymous Coward | about 2 years ago | (#42012477)

SSH is ass, kiss dicks, fag.

Re:Let this be a lesson to the SSH key advocates! (-1)

Anonymous Coward | about 2 years ago | (#42012533)

I tried doing that but when I got to your mother here's was to big discouraging me. I think your mom is a dude, dude. Explains a lot.

Re:Let this be a lesson to the SSH key advocates! (5, Informative)

Antique Geekmeister (740220) | about 2 years ago | (#42012165)

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:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42012263)

How would you then automate remote login?
In a way that is not even worse.

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42013771)

I don't have a complete, general solution to all remote access issues. It depends on what is desired. Kerberos can provide a robust, even distributed authentication technology, with good password management and key revocation, but does not work well for entirely detached and local authentication, and it's already built into recent versions of SSH. SSH key management would also benefit profoundly from very minor changes, such as disabling the generation of passphrase keys without an _affirmative_ selection to generate one, instead of merely accepting the default blank passwphrase with a warning that is so often ignored.

With the growing use of local passphrase keychaiins integrated to web browsers and X sessions, such as the "Kwallet" toolkit, it's become easier to use password based access and store them locally for specific target sites. This is much like the passphrases on SSH keys, but usually much better managed.

Re:Let this be a lesson to the SSH key advocates! (1)

jgrahn (181062) | about 2 years ago | (#42013499)

This is compounded by the lack of effective centralized management tools for SSH key access ...

It works both ways. Precisely because there *is no* centralized control of SSH keys, my workplace cannot implement crazy password aging schemes, or demand at least one digit in each passphrase. End result: I take much better care of my ssh keys than of my plain login passwords.

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42013943)

I... haven't actually attempted this... but it should be possible with a bit of work...

you can enforce all types of complex policies in PAM, and among them... is password and key length policies. SSH keys *DO* (or should anyway) have an expiration date, that you can extract, and this can be checked against, and you could write a plugin that would check it that would be fairly trivial to parse and reject login on.

For that matter, you should be able to enforce centralized IT signing of a personal ssh key -- but again, most IT departments are ran by people that aren't actually ...competent enough to understand that. Maybe that is a "real world failure".

Fort what it's worth, my SSH keys are of the password caching variety. This would be fairly dangerous on a multi-user machine (or any machine where I can't trust the admnistrator, but that's the same problem as anything else), but on a desktop that's actually *mine* it's better.

I log in, my bashrc launches keychain. keychain exports SSH_AGENT_PID into a user owned and readable folder in home. My shell-rc files later refernece these files to import the agent pid and socket. My SSH config will automatically forward my agent to any 'trusted' hosts I log into, similarly preventing me from having to do passwords or launch agents on them. It all comes back to my desktop.

Any machine that has my one of my public keys (I have at least a dozen depending on classification, which may have different passwords) can then be authenticated to. If the computer reboots, or I idle too long, a job purges the cache.

I realize in real life, ssh has many passwordless keys as GP says, but there really isn't a good /excuse/ for a passwordless key save primal ignorance. It takes all of a minute to setup. Seriously -- anyone that doesn't do it now just google "ssh how to use keychain" or similar.

If you're actually /good/, you can do a lot more than that. I have complex SSH loops with multdirectional port forwarding over different user accounts -- many of which are wholly shelless and cna do nothing other than establish sockets. There are socks proxies (with HTTP content filtering and inspection, including OTF antivirus), and a program called autossh (using a passwordless key even) that exists entirely to bring my home desktop into a host-only LAN (vmware) on the office desktop's revert-on-poweroff lightweight vmware instance.

The program is capable of doing *nothing* but establishing a connection on a single port that tunnels over SSH back to itself.

Now, at a big megacorp -- this probably wouldn't fly because the IT guys wouldn't have the control they want over it. Funny thing is -- it's actually more secure than most people think if they'd just understand it. My work desktop has a passwordless authentication to my system, binding a tunnel that only another local user used for just that purpose can take.

Someone would have to compromise the external host, connect to the local socket, and login to it using my office username and key which is controlled by the machine authenticating me to their LDAP service. Then they'd have to run a local compromise to break out of the VM and into the desktop host. Which admittedly then could pose an incredibly serious problem with its ssh agent caching all of my keys... and the ssh config having a beautiful listing of all my hosts and which keys work on them. The agent might or might not have been flushed recently....

It's still a much harder target than any sort of public facing VPN anybody could run because there's only a single functioning username on that host, and the only service publicly exposed is *my* ssh.

But yeah...take good care of your ssh keys.

And to mega IT guys -- one, I couldn't even do this unless you gave me vmware or cygwin. Two, you probably actually wouldn't catch it -- my SSH traffic looks a lot like HTTPS. Three, this happened with permission of my immediate sysadmin. Four -- I wouldn't do it without permission. Five -- if you don't grant permission, you better have a VPN that works not just on linux or mac, but on BSD--and if you use the words PPTP or CHAP, I will forward it with relevant vulnerabilities to your supervisor requesting your resignation.

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42017221)

You quoted:

> Someone would have to compromise the external host, connect to the local socket, and login to it using my office username and key which is controlled by the machine authenticating me to their LDAP service.

That applies to LDAP password based authentication. This is exactly what shared source repositories, like FreeBSD and gitbhub, and Sourceforge, do _not_ want to do. They find it far more effective to use SSH keys, and leave the client side key management in the hands of the clients, It's the poor handling of the client side SSH keys I've found, and confirmed in a recent professional security survey, as being profoundly vulnerable because of the commonplace practices.

Your sophisticated approaches do not scale well, I'm afraid, and are not inherent to SSH itself. They're complexities you've personally introduced that, frankly, I've not heard of anyone else bothering with.

Re:Let this be a lesson to the SSH key advocates! (1)

Yomers (863527) | about 2 years ago | (#42020489)

Whats the point encrypting private key, it would add hassle of typing password every time without real security benefit - if attacker got access to your account installing keylogger is not a problem, right? Just use common sense - do not store unencrypted backups of your keys.

Re:Let this be a lesson to the SSH key advocates! (1)

Antique Geekmeister (740220) | about 2 years ago | (#42021331)

I'm afraid that you are mistaken: your ignorance of the technology is widespread, and leads to precisely the behavior I described of leaving the SSH keys unencrypted and widely available.

Look into the "ssh-agent" tool, the wrappers for it, and the various system keychaiins on different operating systems. It may take thought to handle it for your particular environment, but the simplest approach from a common shell environment is below:

          eval `ssh-agent1
          echo $SSH_AUTH_SOCK
          ssh-add -l
          ssh-add $HOME/.ssh/id_dsa
          ssh-add -l

You'll see that the key has been unlocked for any shells or system commands on that host that have the "SSH_AUTH_SOCK" set to access the running ssh-agent.

Passwords are bad. Don't use them. Use passwords! (0)

Anonymous Coward | about 2 years ago | (#42015351)

You're exactly the kind of person that the GP is talking about. People like you say that passwords are a horrible thing, should never be used, and that the only solution is ssh keys. Then when the security issues surrounding ssh keys are pointed out, you tote passwords as the answer! Lordy, lordy, lordy! Make up your mind!

Re:Let this be a lesson to the SSH key advocates! (1)

Anonymous Coward | about 2 years ago | (#42011855)

I think you mean unencrypted SSH keys...

Re:Let this be a lesson to the SSH key advocates! (2)

overmoderated (2703703) | about 2 years ago | (#42011881)

You can password protect SSH keys. Furthermore, you can store them on an encrypted volume. Passwords can be bruteforced rather easily, because most people tend to use weak passwords. Bruteforcing an SSH server server that enforces PKI however... I guess the only way to get in is... to steal a user's key, which means you need physical access to it or the user has been really careless.

Re:Let this be a lesson to the SSH key advocates! (2)

nurb432 (527695) | about 2 years ago | (#42012249)

or the user has been really careless.

Which is always the weakest link in any security system.

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42011891)

I take it as you were bullied by a bunch of ssh keys as a kid. Quite understandable, you seem a bit dimwitted and full of yourself. Go ssh keys!

Re:Let this be a lesson to the SSH key advocates! (2)

dissy (172727) | about 2 years ago | (#42012873)

Seriously? You are suggesting we leave passwords laying around in plain text in batch files, and go back to telnet???

Your method is only better in one single way. There is no worrying that you are the 0.0001% that did it wrong and are vulnerable. With your way, you KNOW you are already exploited!

Re:Let this be a lesson to the SSH key advocates! (1)

UltraZelda64 (2309504) | about 2 years ago | (#42015615)

Shit happens. One intrusion through OpenSSH into two out of an entire cluster FreeBSD servers doesn't mean jack shit as to the overall security of using SSH as your authentication method. I'll continue to use SSH, and I'm sure pretty much anyone else who uses it now will see no reason to stop just because an encryption key was used as an entry point to a high-profile server. According to TFA, steps are being taken to prevent this from happening again by deprecating legacy services... and SSH doesn't look to be one of them. Besides... it appears that the SSH key wasn't "cracked" anyway, it just somehow made its way to someone it wasn't supposed to.

The compromise is believed to have occurred due to the leak of an SSH key from a developer who legitimately had access to the machines in question, and was not due to any vulnerability or code exploit within FreeBSD.

Good job FreeBSD, for not only disclosing this but also taking steps to prevent similar security breaches in the future.

Re:Let this be a lesson to the SSH key advocates! (0)

Anonymous Coward | about 2 years ago | (#42016141)

The FreeBSD developers are among the best there have ever been.

There are glaring exceptions to this statement.

On this topic, a certain Frenchman is foremost in my mind. He's arrogant and reckless childlike asshole who isn't nearly as smart as he likes to think he is. His half assed "innovations" are leading the project down a bad path, and I get the sense they won't realize what happened for quite some time and when they do, they'll have to redo things that have just been redone, at great cost in manpower and project confidence.

Re:Let this be a lesson to the SSH key advocates! (1)

fnj (64210) | about 2 years ago | (#42016589)

On this topic, a certain Frenchman is foremost in my mind. He's arrogant and reckless childlike asshole who isn't nearly as smart as he likes to think he is. His half assed "innovations" are leading the project down a bad path, and I get the sense they won't realize what happened for quite some time and when they do, they'll have to redo things that have just been redone, at great cost in manpower and project confidence.

Could you possibly state plainly and precisely what you mean. For Christ's sake, man, you are posting anonymously. Why be coy? Give us an allegation we can check.

Hardwre Tokens (0)

Anonymous Coward | about 2 years ago | (#42011817)

Time to go to hardware keys such as eToken for SSH authentication.

Re:Hardwre Tokens (1)

Anonymous Coward | about 2 years ago | (#42011857)

Uhh, people use OpenSSH because it's free, it's everywhere, and they don't need any goddamn hardware token generators and other nonsense like that.

You security hardware guys have been pushing this crap since at least the 1980s. Seriously, it hasn't taken off in 25+ years because it's not practical and it's not what the public in general wants to deal with.

So give it a rest already! Aside from a few niche users, the public at large is not going to pay good money for a hardware token generator, and they sure as hell aren't going to waste their time using it!

Re:Hardwre Tokens (1)

overmoderated (2703703) | about 2 years ago | (#42011919)

Amen. Not to mention, if you lose your token, your screwed. To create a strong password that is easy for you to remember, follow these simple steps: Do not use personal information. You should never use personal information as a part of your password. It is very easy for someone to guess things like your last name, pet's name, child's birth date and other similar details. Do not use real words. There are tools available to help attackers guess your password. With today's computing power, it doesn't take long to try every word in the dictionary and find your password. Mix different character types. You can make a password much more secure by mixing different types of characters. Use some uppercase letters along with lowercase letters, numbers and even special characters such as '&' or '%'. Use a passphrase. Rather than trying to remember a password created using various character types which is also not a word from the dictionary, you can use a passphrase. Think up a sentence or a line from a song or poem that you like and create a password using the first letter from each word.

Re:Hardwre Tokens (1)

Antique Geekmeister (740220) | about 2 years ago | (#42012229)

Also, do _not_ rely on the commonly enforced use of excessively "Mix3d!Cas3". The reasons not to use this take some thought, but are actually well described in XKCD:

              http://xkcd.com/936/ [xkcd.com]

But the real reason is not there: it's that people frequently store such passwords in unencrypted, easily accessible locations such as a file called "passwords.doc" on their desktop, or send them via unencrypted email because they're too hard to remember or explain on a voice transmission.

Re:Hardwre Tokens (1)

overmoderated (2703703) | about 2 years ago | (#42012301)

pwgen -sy 256

Re:Hardwre Tokens (0)

Anonymous Coward | about 2 years ago | (#42015737)

The XKCD only shows that some users are more likely to choose easy guessable passwords if you forced them to use mixed case alphanumeric. In reality, these passwords are still stronger than non-mixed non-alphanumeric and there's no reason not to use them if you have the brain power to do so.

Re:Hardwre Tokens (-1)

Anonymous Coward | about 2 years ago | (#42012071)

Good money? They are like 5-10 bucks. Maybe you need to ask mommy and daddy to raise your allowance?

The Damage Will Be (0)

Anonymous Coward | about 2 years ago | (#42014659)

5 million bucks if you use that Crapware. 50 bucks if you take the effort to use a proper pw and write it on a piece of paper you store in your purse. And all the variants of that down to one-time-password lists.

Why the fuck should anyone trust in an opaque piece of crapware made by a greedy slimbag corporation ??

5 million (0)

Anonymous Coward | about 2 years ago | (#42014679)

..because the crap-generator will be broken and Chicom will pilfer your intranet for 5 million worth of R&D data.

Re:Hardwre Tokens (0)

Anonymous Coward | about 2 years ago | (#42014097)

Hardware token generators are in fact quite widespread for bank use in Europe and Asia. The public can, and does, escept them for important applications. It's the US laws on the export of encryption technologies as a military material, and the insistence that the US governments retain control of the central key authorities, that has created many of the absurdities such as the old 80-bit SSL keylength restrictions and the new so-called "Trusted Computing" technology. Do look into that technology. If you've bought a motherboard in the last few years, you've probably _already paid_ for a hardware crypto token.

It certainly has flaws, but you've probably already paid for it on new netbooks or desktop machines.

Oh Yeah !!!!! (0)

Anonymous Coward | about 2 years ago | (#42014629)

Fighting Common Cold with Malaria or what ??

A shitcorp named "RSA Security" demonstrated why hardware PW generators should be avoided like the plague. Unsound concept, unsound practices, security by obscurity. Chicom stole their balls and then pissed into Lockmart's face. Yeah, Lockmart of F35 infamousness.

Re:Hardwre Tokens (1)

Admiral Burrito (11807) | about 2 years ago | (#42014727)

Yes! These things have finally gotten cheap enough (around $20) that those of us with access to a lot of servers ought to have one.

For those not in the know, these things look like a USB flash drive, but have more number-crunching power than storage. You load your SSH private key onto the USB fob and the key never leaves the device. Plug the fob into a USB port and ssh offloads the private-key RSA operations to the fob, which won't do anything unless you enter a PIN. As the private key never leaves the device, it can't be stolen without physically stealing the device or somehow hacking into the firmware. Using the fob requires software (opensc) on the computer you plug the fob in to, but to the server it's just a plain old SSH connection.

Obviously if you lose the fob you're screwed unless you have a backup copy of the key somewhere. The best option seems to be to generate the key on a PC with no network connectivity, save the key to the fob, and also save to removable media as an offline backup.

You cannot secure carelessness (5, Insightful)

overmoderated (2703703) | about 2 years ago | (#42011939)

No matter how secure your system is (and SSH is very secure), if the individual using it is careless, the system will end up getting compromized.

Re:You cannot secure carelessness (-1)

Anonymous Coward | about 2 years ago | (#42011991)

Ah ha ha ha!

Where is your God now, F/OSS people!

Re:You cannot secure carelessness (1)

Anonymous Coward | about 2 years ago | (#42012217)

your comment is non-sequitur. being carless is not
related to your software license.

Re:You cannot secure carelessness (1)

evilviper (135110) | about 2 years ago | (#42017417)

OpenSSH will refuse to use any key where the permissions are set too permissively, so others may be able to read it...

Technology can't solve stupid user mistakes, but it can keep getting better at preventing common mistakes.

Odd way to announce it (1)

nielsm (1616577) | about 2 years ago | (#42012117)

Why would you use a stolen SSH key to announce a security breach?

Short Answer (3, Interesting)

benjymouse (756774) | about 2 years ago | (#42012877)

would proprietary companies that get broken into so forthcoming? Should they be?

Yes, they are already required to [proskauer.com]

BTW, have we ever seen a satisfying explanation for what happened at kernel.org and linuxfoundation.org? We were initially told that it was something similar (stolen password/compromised user system), but AFAICT they have never explained how that could lead to the servers being root'ed. A rootkit *was* installed. That requires careless use of root privileges or an exploit of a privilege escalation vulnerability. Which was it?

Re:Short Answer (0)

Anonymous Coward | about 2 years ago | (#42016803)

I think we were all reminded recently by Apple that were "required" to apologise to Samsung that "required" is a weak word.

Re:Short Answer (0)

Anonymous Coward | about 2 years ago | (#42018557)

BTW, have we ever seen a satisfying explanation for what happened at kernel.org and linuxfoundation.org? We were initially told that it was something similar (stolen password/compromised user system), but AFAICT they have never explained how that could lead to the servers being root'ed. A rootkit *was* installed. That requires careless use of root privileges or an exploit of a privilege escalation vulnerability. Which was it?

As far as I know, no explanation has ever been provided. I spent some time looking a few weeks ago and came up blank, if anybody does find oen I'd love to see it.

Re:Short Answer (0)

Anonymous Coward | about 2 years ago | (#42020589)

let's give this some more spotlight:

BTW, have we ever seen a satisfying explanation for what happened at kernel.org and linuxfoundation.org? We were initially told that it was something similar (stolen password/compromised user system), but AFAICT they have never explained how that could lead to the servers being root'ed. A rootkit *was* installed. That requires careless use of root privileges or an exploit of a privilege escalation vulnerability. Which was it?

Re: (0)

Anonymous Coward | about 2 years ago | (#42152485)

It's all security theater anyway :-P

-Linus

I thought linux was supposed to be more secure tha (-1)

Anonymous Coward | about 2 years ago | (#42013301)

I thought linux was supposed to be more secure than Windows. Even my Windows Server isn't hacked so easily. Just goes to show what happens when people aren't paid for their IP.

Re:I thought linux was supposed to be more secure (1)

overmoderated (2703703) | about 2 years ago | (#42014197)

I agree, everybody should get paid for their IPs. It's only fair damnit.

Re:I thought linux was supposed to be more secure (0)

Anonymous Coward | about 2 years ago | (#42019263)

This is BSD, not Linux, tard.

What happened at kernel.org anyway? (0)

Anonymous Coward | about 2 years ago | (#42013545)

I haven't seen any official response, only some unofficial assertions that about compromised user credentials.

Re:What happened at kernel.org anyway? (1)

TheRaven64 (641858) | about 2 years ago | (#42017961)

I had an account on a machine in the same rack as kernel.org, and that machine was taken away for forensic analysis and still isn't back. Apparently (I don't do security research, but I work on a team that does) kernel.org contained the world's best collection of rootkits found to date, which was incredibly useful to people doing work in this area.

Re:What happened at kernel.org anyway? (0)

Anonymous Coward | about 2 years ago | (#42020629)

I had an account on a machine in the same rack as kernel.org, and that machine was taken away for forensic analysis and still isn't back. Apparently (I don't do security research, but I work on a team that does) kernel.org contained the world's best collection of rootkits found to date, which was incredibly useful to people doing work in this area.

i would love to have a source for this statement.

It's the Perversion! (1)

synthespian (563437) | about 2 years ago | (#42021301)

Crypto: 0
                    As received by: Transceiver Relay03 at Relay
                    Language path: Cloudmark->Triskweline, SjK units
                    [Cloudmark is a High Beyond trade language. Despite
                    colloquial rendering, only core meaning is guaranteed.]
                    From: Transcendent Bafflements Trading Union at Cloud Center
                    Subject: Matter of life and death
                    Summary: Arbitration Arts has fallen to Straumli Perversion
                    via a Net attack. Use Middle Beyond relays till emergency
                    passes!
            Key phrases: Net attack, scale interstellar warfare, Straumli
                    Perversion
  Distribution:
                    War Trackers Interest Group, Threats Interest Group, Homo
                    Sapiens Interest Group
Date: 61.12 days since the fall of Straumli Realm
Text of message:
WARNING! The site identifying itself as Arbitration Arts is now
controlled by the Straumli Perversion. The Arts' recent advertisement
of communications services is a deadly trick. In fact we have good
evidence that the Perversion used sapient Net packets to invade and
disable the Arts' defenses. Large portions of the Arts now appear to be
under direct control of the Straumli Power. Parts of the Arts that were
not infected in the initial invasion have been destroyed by the
converted portions: Fly-throughs show several stellifications.
What can be done: If during the last thousand seconds, you have
received any High Beyond protocol packets from "Arbitration Arts",
discard them at once. If they have been processed (then chances are
it is the Perversion who is reading this message and with a [broad smile]),
  then the processing site and all locally netted sites must be
physically destroyed at once. We realize that this means the
destruction of solar systems, but consider the alternative. You are
under Transcendent attack.
If you survive the initial peril (the next thirty hours or so), then
there are obvious procedures that can give relative safety: Do not
accept High Beyond protocol packets. At the very least, route all
communications through Middle Beyond sites, with translation down to,
and then up from, local trade languages.
For the longer term: It's obvious that an extraordinarily powerful
Class Two Perversion has bloomed in our region of the galaxy. For the
next thirteen years or so, all advanced civilizations near us will be
in great danger.
If we can identify the background of the current perversion, we may
discover its weaknesses and a feasible defense. Class Two Perversions
all involve a deformed Power that creates symbiotic structures in the
High Beyond -- but there is enormous variety of origins. Some are
poorly-formed jokes told by Powers no longer on the scene. Others are
weapons built by the newly transcendent and never properly disarmed.
The immediate source of this danger is well-documented: a species
recently up from the Middle Beyond, Homo sapiens, founded Straumli
Realm. We are inclined to believe the theory proposed in messages
[...], namely that Straumli researchers experimented with something in
Shortcuts, and that the recipe was a self-booting evil from an earlier
time. One possibility: Some loser from long ago planted how-to's on the
Net (or in some lost archive) for the use of its own descendants. Thus,
we are interested in any information related to Homo sapiens.

-- Vernor Vinge, A Fire Upon the Deep

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>