Slashdot Mirror
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?"
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?
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.
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.
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.
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".
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.
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.
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.
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).
/usr/bin before you run ssh?
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
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.
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
Excellent! I'll reconstruct my test environment and make something good happen... jt