Overconfidence in SSH Protection

nitsudima writes to mention a post on the Informit site about the common misunderstandings surrounding SSH, and how well-intentioned admins may be creating holes in their own security by using it. From the article: "In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file. In this case, the connection to Box A (and that private key used for authentication) is a socket file. This file will shuttle the authentication traffic between Box A and Box P. So what's the risk? Maybe the hacker can't get a copy of the private key through the socket file, but something better (from his/her view) can be done. If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the 'safe' intranet. What are the chances that the administrator has configured access to all the DMZ servers he controls?"

Comments

Huh? What?

[XanC]

I consider myself fairly competent as far as this kind of stuff goes, but I just couldn't follow that summary at all. Maybe it's just because it's so late. Can someone post a more sensible summary of an attack?

All I need is root?

[Anonymous Coward]

So all I need to do is to get a root access to a Linux server and I can spy normal users there? Whoah, now this is what I call news.

Root

[L0rdJedi]

Yep, just gotta get root. Of course, at that point, you probably have more to worry about than someone redirecting your ssh session.

dont really understand the problem.

[geoff lane]

If you gain access to a system within the DMZ you've already broken in ... ssh has nothing to do with it.

Any sysadmin who configures sshd to allow direct access to a root account is incompetent and deserves to clean up the resulting mess when they are cracked.

So what should we worry about again?

Re:dont really understand the problem.

[ladadadada]

Not quite. If you have broken into the DMZ, that's all you have. Even mildly competent sysadmins know not to trust the DMZ and therefore you do not automatically have access to the rest of the network, nor do you have access to any confidential documents.

The exploit mentioned in the article doesn't rely on ssh being configured to connect directly to root. It relies on the attacker having gained root access on the box being ssh'd to by the sysadmin. Once the sysadmin has ssh'd to the comnpromised box (as any user) the attacker can then ssh to any other box the sysadmin has configured to use agent forwarding.

Two solutions to prevent this compromise of the rest of the network:
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.

2) Use a different public/private key pair for each box. That way, if you didn't firewall the DMZ off it would still fail on the key authentication. The drawback of this is a) the attacker can still ssh to your admin box which contains all of the private keys and b) you lose most of the advantage of agent forwarding; the ability to ssh through a chain of boxes without any but the first needing to store the private key.

I suppose the underlying message in the article is "You REALLY can't trust anything in a DMZ that may have been compromised. ssh is a tool that can be turned against you if one of your machines is compromised."

Re:dont really understand the problem.

[ladadadada]

After your description of the exploit attempt I had another, very careful read of the author's description and have come to the conclusion that we were both wrong. He is suggesting that other DMZ hosts would be compromised using the authentication credentials that should be safely behind the firewall. No internal boxes would be compromised.

From the article: (emphasis mine)

What are the chances that the administrator has configured access to all the DMZ servers he controls? Altering some environment variables allows the intruder to attempt to access other DMZ hosts with our administrator's private key. This can mean direct access as root or local administrator. And so this socket file becomes a door to many other systems in the DMZ.

The convoluted setup using the workstation and the patching server were irrelevant to the fact that there was an ssh-key connection to a compromised box which then used agent-forwarding to connect to and compromise other boxes in the DMZ.

As long as the DMZ is properly firewalled from the internal boxes it should be impossible to actively compromise them using a forwarded ssh key and hence you were completely correct in stating that your description of the attack was impossible. (I hope. If it were possible that would be... bad.

This would also mean that if the administrator had a different public-key/private-key pair for each box in the DMZ then the attacker could not agent-forward the ssh session to other boxes and would have to compromise each one manually. However, since most boxes in a DMZ are often configured identically with a load balancer in front of them, a flaw on one that allowed the inital compromise would likely be replicated to all the others and allow them to be compromised in the same way.

He also goes on to suggest that there might be a flaw in the administrator's patch loading scripts that allows execution of code on the patch-server but that is an entirely seperate issue and not concerned with ssh at all.

OpenBSD?

[jawtheshark]

Any sysadmin who configures sshd to allow direct access to a root account is incompetent and deserves to clean up the resulting mess when they are cracked.

So you are calling the OpenBSD guys incompetent? After all, if you enable SSH in the default installation, you can SSH into that machine including as root.

The Key is Not Transmitted

[Wovel]

The key is not transmitted or sent to the socket file. This person does not understand anything about private key authentication and should return all of his certifications, and please stop posting stories by them, it is embarassing.

Never understood why they invented the SSH-AGENT

[wtarreau]

Personnaly, I never understood how talented SSH developers came to the conclusion that they needed to invent such a crappy thing : ssh-agent. And I've seen people use it, the same people who put their private keys on USB sticks to ensure that nobody will steal them, but who are not afraid of collegues having root access on their machine ...

ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key. No comment ! There's nothing difficult in typing
a passphrase each time you connect to a remote site !

--
willy
high performance free load balancing solution - http://w.ods.org/haproxy/

Re:Huh? What?

[Onan]

User B (evul hacker with root on box foo):
foo# SSH_AGENT_PID=XXXX; export SSH_AGENT_PID
foo# SSH_AUTH_SOCK=/tmp/ssh-YYYY/ZZZZ; export SSH_AUTH_SOCK

Uh, this is hardly the only way that someone with root on the machine from which you're authenticating can obtain your credentials. Far more effective than this would be for them to simply take your private key file and grab your passphrase as you enter it; that would allow them to use these credentials forever in the future, rather than being limited to when you have an agent running on their machine.

So... how does this even remotely approach being news? Yes, if you type your passwords into a machine on which someone else has root, you have given those passwords to them! The horror! I had no idea!

The best thing I can say about this article summary is that it did not misrepresent the actual piece. The article itself was also muddled tripe, filled with semi-true and completely-irrelevant noise like "in unix, everything is a file..."

It appears that the author is just a firewall admin who's offended that ssh can be used to thwart his precious acls, and invested in giving the tool a bad name.

Bullet proof is hard to come by

[HangingChad]

Short of unplugging the machine and locking it in a vault. SSH may not be perfect but it's pretty darn good. And if getting your credentials depends on someone else have administrator rights on one of your nodes, that's not exactly a fatal flaw unless your security demands are extremely high.

Anyone with the time and resources is going to find a way into your network. Many times security does not have to be bullet proof. Don't have to be faster than the bear, just faster than the large majority of other networks. Unless there's something really compelling on your system, they're likely to pick an easier target.

I use my home network as an example. I have one copy of XP on my system. What I consider the weak link in the security chain. It's on a NAT'd segment, I don't surf the internet with it and anything sensitive is on a TrueCrypt partition that I only mount when needed. Hardly bullet proof but not bad for Windows.

Re:Huh? What?

[Matey-O]

I think part of the article is trying to say that users can enable their own ssh tunnels to home, and thus if their home network is compromised there is an easy route into the office intranet.

But how is this not the case for ANY connection from a home network to the office...VPN opens up the same issues too.

Re:Huh? What?

[ultranova]

This misconfiguration enables the attacker to hop from the DMZ to the intranet. The correct way to avoid this is to disable agent forwarding (on the admin's computer, not just on the DMZ hosts, of course).

Sorry, doesn't work.

I'm an 3v1l h4x0r in complete control of untrusted host X. Some poor fool uses SSH to connect to the trusted, firewalled host Haven. At this point, since I'm in complete control of X, I can simply send commands from X to Haven, doing anything the user could - including launching an SSH or telnet client from Haven's command line. What ? Haven doesn't have them ? Then I simply send one, piping encoded data to uudecode, or perhaps a mail client (to send the file to the users own account - if it's machine-local delivery, it propably won't go through the companys mail server and won't be stripped for binaries), or maybe simply through some insane sed script to turn hexcodes back to binary format - but one way or another, I'll get the telnet client to Haven.

Well, now I have telnet in Haven, and can connect to any service running at Haven, with the connection seemingly originating from Haven itself. And of course I can connect to other intranet machines as well. Or I could use some kind of hex-to-bin proxy telnet-like program, and another one on X, to emulate agent forwarding.

The point is that as long as there is a connectiong between X and Haven, and Haven gives the user a command line interface, it is impossible to prevent the user from forwarding arbitrary connections over it. Or at least simply preventing SSHs native support for that won't stop it from happening.

The lesson: any machine that gives shell access to untrusted machines is untrusted.

Re:Huh? What?

[Kadin2048]

Okay, so let me just get this straight. Executive summary, "moral of the story," whatever, is...

Don't use agent forwarding when connecting to an untrusted box?

Can you just mandate that as a policy or are there times when you absolutely have to use agent forwarding via an untrusted/DMZed machine? I don't think I've ever used a DMZ machine for agent forwarding, but then again it's not really a feature I've used very heavily.

Re:Home/Office network compromisation in 4 steps

[Larthallor]

I think you have it backwards. The author's concern about people tunnelling from home isn't that a compromised work machine will take-over the remote worker's home machine. He's a firewall admin and could care less about your home machine's health, in and of itself. What he is concerned about is the fact that your previously compromised home box can tunnel right through all of that hard work he's done trying to build a secure firewall and have IP access to attack the internal network's soft underbelly. SSH, IPSEC and other tunnelling solutions are putting untrustworthy machines directly inside the firewall.

A more secure way would be to only allow non-port forwarded, remote desktop-style connections to a single cluster of terminal server machines. This would prevent direct remote attacks from the home machine against anything other than the terminal server on the terminal server ports. A compromised home machine could still allow someone to tunnel and login to the terminal server as you via remote control, but at least you have limited the attacker's access to a machine that you control and that isn't compromised. While your credentials would be compromised (via the keylogger/session shadower the attacher installed on your home machine), the attacker would only be able to do what you could do on the terminal server. You would be screwed when they detect "you" attempting to compromise internal security or sneaking out sensitive information, but the network would be much safer.

Alternately, if you don't have a terminal server-style (RDP, Citrix, LTSP, etc.) environment set up, you could have the tunnel gateway only allow RDP/Citrix/X access to the user's work desktop with similar security attributes.

Re:Huh? What?

[davidsyes]

"It appears that the author is just a firewall admin who's offended that ssh can be used to thwart his precious acls, and invested in giving the tool a bad name."

Remember the /. stories that started like, "We're setting up a company and would like to know how you would do xyz with "linux" vs Windows, how long you've been using "linux", how you got approval for it, and how long you have successfully maintained security with the limited headcount you have..." that (if you are cynical) sound like big-company-paid-for pieces meant to flush out Unix/Linux-leaning companies that "ought" to be on ms/windows-related stuff.

Just from the "in unix, everything is a file...." I started seeing big money funding this article. I could be wrong, though...

I wonder if /. would agree to a reader-demanded aversion to corporate-paid slipstream submissions... (opps, a ladder and mop bucket are being hurled my way...(instead of conference room executive chairs)...)

Re:Huh? What?

[traenky]

Being as filled with tripe as you claim, I might have thought I wrote simply enough for you to understand. I guess not? Under agent forwarding, the first hop device doesn't have the private key. You might review the documents on OpenSSH to understand ssh better. In there, you will find big precautions against agent forwarding in an environment that has high potential for compromise. Would you mind posting these enlightening comments of yours on the actual Informit site?

Re:Huh? What?

[traenky]

No, not at all. When you consider the forwarding abilities of both the ssh client and server implementations, it is possible to build what looks to be an insider-initiated tunnel to the outside. Safe, right? Instead, the tunnel is used to force the traffic from the remote server back into the tunnel, and from there, throughout the intranet, including RFC 1918/3330 addresses normally unreachable from the Internet. Let me know if some kind of video file would help explain a very difficult topic in ssh. Many organizations are swapping out telnet/ftp for ssh. That part's great. It's the uncontrollable forwarding abilities that seem the biggest challenge.