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

So...

[Anonymous Coward]

If I understand correctly, the author is talking about a complicated man-in-the-middle?

Isn't that why SSH displays that "Private key SO:ME:WE:IR:DL:ET:TE:RS belongs to IP 127.0.0.1" or whatever?

Not a SSH problem?

[andy753421]

Maybe I read the article wrong but it seems to me like a problem with someones design and not with SSH, a little like saying Unix is insecure because a unwitty sysadmin could try to make his life easier by using a blank root password.

Re:dont really understand the problem.

[FuryG3]

I agree completely. Remote root login is disabled by default, and system administrators should *not* enable it unless there is some damned good reason. Too often I have seen sysadmins simply enable root login, and twice now I've seen someone do key exchanges so that they can 'seemlessly' ssh as root between all of their servers.

Duh.

Re:Huh? What?

[limegreen]

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.

Re:Hopefully, a better summary...

[flooey]

Administrators use SSH to run scripts (from server A) to patch other servers (B, etc). These scripts are automated and make use of credentials stored in server A to gain access to the other servers (B, etc.).

If a hacker gains access to server A, he can then use the credentials to access the other servers.

Actually, it was a little more complicated. The scenario is actually that administrators use SSH to run scripts on server A to patch server A using patches from server B. The trick is, without having credentials stored on server A, a hacker who compromised server A could still trick his way into getting server B to allow him to log in if someone was logged into server A and had agent forwarding turned on.

It's not quite as straightforward of a duh moment (after all, server A on its own can't log into server B), it's basically just saying "when you log into a server and have agent forwarding turned on, you allow anyone with root access on that server to log into anywhere your agent can log into".

Re:OpenBSD?

[Anonymous Coward]

That's because openssh is no longer 'on' in the default install, so any holes it might have are no longer exploitable out of the box. How many holes in the last 8 years after you turn on essential services? Heck, NT4 had no remotely exploitable holes when it got its gov certification, since it was for a stand-alone machine with no network connection that was tested.

Re:Huh? What?

[ipso_facto]

If someone gets root on one of your boxes, all bets are off as there's a very good chance that they'll get root on another one of them (by keylogging passwords, brute forcing the password on a sudo enabled account, passwordless ssh keys, hijacking a session etc etc)

Wash, rinse, repeat.

Before you know it your whole DMZ is rooted (in more than one sense).

In short:
- If you find a compromised box on your network, assume there's more than one and order pizza... you're in for a long night.
- Segregate your networks so if someone, say, gets at your DMZ there's no way to get into your internal or other production network i.e. no ssh or accessible services on your firewall machines on the DMZ interfaces.

i.e. It's not just an issue with ssh.

Re:There is a reason....

[Anonymous Coward]

Agree 100%. To anyone who has read the SSH documentation, this is old news. However, judging from the number of posters in this thread who seem confused about the nature of the attack, I guess that most people either (a) don't read manuals, or (b) never considered how 'ssh-agent' performs its magic. Now. at least, they know.

Re:Not a SSH problem?

[Anonymous Coward]

yeah...the article is basically correct, but unintelligible. you can turn off root login easily in the ssh config file (though I leave it on so that i easily kick off a script that runs as root on that host.)

IMHO, the REAL problem that people have with SSH is this:

1) If you turn an IDS on your network and all traffic is going to port 22 and everything is encrypted then you have NO IDEA what really goes on in your network.
2) A compromised home system will be able to masquerade as its owner inside the intranet.

Example of making intranet services available to the whole world:

#make the ssh server on my work desktop available in my home network (on server joeshouse.org):
ssh -L9999:joedesktop.work.com:22 [e-mail]
#make the accounting server available for the whole world at http://joeshouse.org:8000/ [joeshouse.org]
ssh -g -p 9999 -L8000:accounting.work.com:80 joe@localhost
#ditto for the cvs server (probably ssh encrypted access)....
ssh -g -p 9999 -L8878:cvs.work.com:22 joe@localhost

Example of refusing to use the official proxy server while at work, using personal from house instead
ssh -L9999:joeshouse.org:22 [e-mail]
ssh -p 9999 -L3128:localhost:3128 joe@localhost

Example of playing on my favorite gaming server for a 3:00am game before I head home for the night:
ssh -L9999:joeshouse.org:22 [e-mail]
ssh -p 9999 -L2379:goserver.igoweb.org:2379 joe@localhost

In every case, the admin sees nothing but ssh traffic from joedesktop.work.com to joeshouse.org:22. Nothing other than the volume of traffic would trigger suspicion. End users in the network have actual privacy under this scenario, which conflicts with having accountability. You have to actually trust your end users now.

Where I work, the admin basically just shuts down all incoming access to a single ssh gateway, and an http proxy going out. He doesn't take requests to open up ports and such. He will tell you to use ssh and do it yourself. Implicit in this is the idea that this does defend from outside attacks on the network, but it places a level of trust in the employees (to be neither extremely stupid nor malicious)

You can tell yourself that if you get rid of SSH, this problem will go away, but ANY tunnel can be used to do this (https://joeshouse.org for instance). You can set up an SSL service on joeshouse.org:443 and it happens to just be a tunnel to ssh. You could create an SSL tunnel that lets you set up port forwards just like SSH does now, with no way the proxy could tell what happens under that encryption. The fact that the tunnel is encrypted means that you can't spy on users to try to limit what they do. We are the kind of employee population where almost everyone knows all the routes around official policy, so you just have to tell them what activities are prohibited (don't run p2p at work, dont visit pr0n sites, etc) and enforce by non-technical means.

SSH-AGENT doesn't make a root level exploit worse

[argent]

If a bad guy has the ability to bypass local file permissions (whether because he's root or because you screwed up the permissions) then he can steal your credentials by putting a backdoor in the SSH client, the SSH server, the terminal driver, the file system, shared libraries (glibc, for example, is so huge and complex you could hide a trapdoor, magic hat, rabbit, three cages of pigeons, and a performing elephant there and nobody would notice).

I've cleaned up boxes that had been rootkitted, and if you can't identify when it happened so you can restore from a known good backup you're best off reinstalling from scratch.

The same thing is true, to a lesser extent, for local user privileges. Do you check that $PATH doesn't go through ~/bin before /usr/bin before you run ssh?

Once someone can run unsandboxed code on your computer you're compromised, and any tool you use to examine your computer may be compromised, and ssh-agent make so little difference that it's simply not worth worrying about.

Re:Copying from a man-page is not news

[traenky]

This is certainly one part of the ssh puzzle. And I'm glad to meet someone else who reads vendor documentation and follows it. That's not always followed. I see a lot of companies adopting ssh as an ftp/telnet replacement. Maybe a business partner only accepts ssh connections. Maybe there's a 'end plaintext' initiative. As many begin studying ssh, they gloss over port forwarding. They enable agent forwarding, and the users love it! If they see that warning, it's tough to understand; so some skip the warning. And that's the issue: how will your organization implement one of the world's best security AND connectivity tools out there? Write more--I like your reasoning. jt

Re:Huh? What?

[traenky]

Excellent! I'll reconstruct my test environment and make something good happen... jt