Forgot your password?
typodupeerror

Overconfidence in SSH Protection 194

Posted by Zonk
from the don't-be-too-proud-of-this-technological-terror dept.
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?"
This discussion has been archived. No new comments can be posted.

Overconfidence in SSH Protection

Comments Filter:
  • by perlionex (703104) * <josephNO@SPAMganfamily.com> on Saturday May 27, 2006 @03:16AM (#15414853) Homepage

    The submitter didn't summarise anything, he cut out a chunk which didn't make much sense on its own. It didn't help that the article was fairly long-winded. This is what I understand the author is trying to say:

    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.

    As others have commented, this is kind of a "duh" moment. What's the next article?
  • Basic Stuff (Score:5, Informative)

    by sodell (161952) on Saturday May 27, 2006 @03:19AM (#15414860)
    The article illustrated one very convoluted way to break your DMZ security, but failed to make the simple statement: don't trust anyone, not even root, on your DMZ hosts. Allow SSH logins into the DMZ, and allow the DMZ to pull files from private network patching servers, such as apt repositories, but don't allow anyone to SSH from the DMZ to the intranet. Assume the DMZ is cracked wide open and keystroke logging. No one is going to get past the DMZ by watching you type 'apt-get install squid' but they will by watching you type 'ssh root@creditcarddb.int' and then the root password.

    Anyone who tunnels from the DMZ to a trusted host which can execute commands on a sensitive server can't see the forest for the trees. You've learned how to use SSH and tunnel, but you're lacking some basic common sense.

    Also, I don't see what good a socket catching the authentication will do ... you can packet sniff the authentication process all day long and you won't get someone's private key.

    That whole article seemed a bit of voodoo itself. Many incongruous statements, like "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 does that mean, exactly? You direct the authentication process to a socket file and point the process to the admin's credentials? If the socket is on the DMZ host, and the credentials are on the private network host, how can you point the authentication process to those credentials?

    Maybe I'm stupid, but the article didn't seem to make a lot of sense.
  • Re:Huh? What? (Score:5, Informative)

    by Riku (740152) on Saturday May 27, 2006 @03:22AM (#15414864)
    Here's a summary for you:

    User A on box foo:
    foo> ssh-agent xterm
    foo> ssh-add
      * enters their pass key *
    User A can now ssh to any box that has their public key in box:$HOME/.ssh/authorized_keys

    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
    User B now can ssh to any box that User A can, as above.
    (where XXXX, YYYY, and ZZZZ are determined by evul hacker)

  • Re:Huh? What? (Score:2, Informative)

    by ladadadada (454328) on Saturday May 27, 2006 @03:25AM (#15414868) Homepage
    It's not just you. I had to re-read it several times.

    I think the main point (the one the article submitter picked up on) was that if an attacker can compromise your DMZ box (the most vulnerable box your company owns and hence the least trusted box your company owns) that has no private ssh keys stored on it and can't connect to any other trusted box but does have trusted boxes connecting to it, then he can use that to compromise further trusted boxes inside the organisation.

    To put it another way, if you ssh to an attacker's machine using agent forwarding he can probably ssh back to yours.
  • by meridian (16189) on Saturday May 27, 2006 @04:02AM (#15414945) Homepage
    YES Thats correct you can use AgentForwarding.... If you are stupid enough to use agent forwarding to a host you don't trust or you would consider insecure ITS YOUR OWN STUPID FAULT IF YOU GET HACKED. Now for the evil h4x0rz to use agent forwarding on the host you connect to to hack the machine you are coming in from requires quite a number of things to be done on your stupid behalf that sure wouldnt be enabled by default and you would almost need to set them up purposefully. The only real danger with agent forwarding to an insucure host is that evil h4x0rz on that host can use your forwarded authentication agent to connect to boxes that are set up to both allow connections using that ssh-key AND allow tcp connections from any box that the evil h4x0rz have access to. Aside from that it is only as insecure as establishing a telnet session to the box and having some buffer overflow occur back to the client due to poor code on the client side. I am sure not about to stop using ssh for some "simpler" protocol like telnet but I will sure keep disabling AgentForwarding and any kind of portforwarding the hosts I dont trust and I ASSUME EVERYONE ELSE WILL CONTINUE TO DO THAT AS WELL. Otherwise you might as well start posting your root passwords to slashdot which may or may not matter if you have locked your systems down correctly in the first place.
  • by meridian (16189) on Saturday May 27, 2006 @04:11AM (#15414964) Homepage
    Actually...
    Rather than assume anyone^H^H^H^H^H^Heveryone on slashdot has any brains when it comes to Securing SSH let me give you some tips I/Other people have

    Restricted ssh shell for scp/sftp http://sublimation.org/scponly/ [sublimation.org]
    Patch to lock out IPs brute forcing passwords http://ethernet.org/~brian/src/timelox/ [ethernet.org]

    Can add restrictions to authorized_keys file
    from="hostipaddress",command="/usr/local/sbin/ssh_ command_allow_rsync",no-port-forwarding,no-X11-for warding,no-agent-forwarding,no-pty ssh-rsa AA...= backup_key

    Securing sshd in /etc/ssh/sshd_config
            Protocol 2
            PermitRootLogin without-password
            PasswordAuthentication no
            ChallengeResponseAuthentication no
            ClientAliveInterval 60
            ClientAliveCountMax 30

    The first line says to stop using the old, lower security ssh protocol-1.

    The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.

    The third line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)

    The fourth and fifth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. After editing the sshd file, restart sshd or reboot for the changes to take effect.

    31-12-2004: new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.
        pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
                    keep state (max-src-conn-rate 10/60, overload )
        block in on $ext_if proto tcp from to $ext_if port ssh

    Also my previous post to do with limiting user connections to SSH during the scarey SSH port scanning days of not so long ago...
    http://it.slashdot.org/comments.pl?sid=156058&cid= 13084357 [slashdot.org]

    Repeated here for your convenience:
    Ways around SSH Brute forcing (Score:1)
    by meridian (16189) on 11:06 AM July 17th, 2005 (#13084357)
    (http://www.thief.net/)
    There are esentially three ways to fix this problem.
    The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
    http://ethernet.org/~brian/src/timelox/ [ethernet.org] [ethernet.org]

    The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
    Here is a recent example from the iptables mailing list
    iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
    iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
    iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
    iptables -A SSH_BF -p tcp -j DROP

    The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.h [kernel.org] tml [kernel.org] called pam_abl
    This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches.
  • by Anonymous Coward on Saturday May 27, 2006 @04:23AM (#15414982)
    Why the developers of ssh have an option to forbid agent forwarding. Isn't it off by default? I cite from "man ssh":

    >>>
                              Agent forwarding should be enabled with caution. Users with the
                              ability to bypass file permissions on the remote host (for the
                              agent's Unix-domain socket) can access the local agent through
                              the forwarded connection. An attacker cannot obtain key material
                              from the agent, however they can perform operations on the keys
                              that enable them to authenticate using the identities loaded into
                              the agent.

    So wha is slashdot running an article about something where there is an explicit one-paragraph long waring in the man page of program at the option in question.

    Yes, no doutbt there are a lot of idiots around, who without understanding,do things which require semantics which leads to a security leak (there is abolutely no way if you want to initiate authenticatication from processes on a machine to avoid root to do the same - as log as you are not asked on the agent's side each time before authentication;
  • Re:Basic Stuff (Score:4, Informative)

    by flooey (695860) on Saturday May 27, 2006 @04:33AM (#15415008)
    What does that mean, exactly? You direct the authentication process to a socket file and point the process to the admin's credentials? If the socket is on the DMZ host, and the credentials are on the private network host, how can you point the authentication process to those credentials?

    When the admin logs into the DMZ host with agent forwarding turned on, SSH will create a socket to interact with the agent on the admin's machine. Since the wily hacker has root on the DMZ machine, he can write to and read from that socket with no problem, and thus can ask the agent to authenticate to anywhere that the agent is willing to authenticate to (what he actually would do is just set environment variables for SSH that say "I'm using agent forwarding, my agent is located at {admin's agent forwarding socket}").
  • by Athanasius (306480) <slashdot AT miggy DOT org> on Saturday May 27, 2006 @06:21AM (#15415187) Homepage
    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.

    Or better yet, don't allow the DMZ host to initiate *any* connection outbound from itself, if the services present on it don't need to do such, or failing that, disallow it initiating any connection that isn't out the internet-only-facing interface(s).

    However, that's still not what the attack is exploiting, and wouldn't prevent the attack.

    The 'attack' is taking an (I)Internal (S)erver, an (I)nternal (W)orkstation, and a (D)MZ host. Your firewall/ACLs are set such that IS can't receive, or will reject, any connection from D. However IS will accept connections from IW, and furthermore IW can ssh to D. So, the well-meaning admin of D, using IW, ssh's to D, setting up a tunnel to forward traffic on port Dx on D back to IW, port IWx, and also ssh's from IW to IS, forwarding IWx to a service on IS. Thus you can now connection to (D's) localhost:Dx and end up talking to the service on IS.

    At no point is any connection initiated from D outside of itself, as the data is simply passing back through the ssh tunnel from IW to D, and then back further from IW to IS. And, no, you can't firewall D from talking to any but necessary ports on D, as we're assuming root compromise of D and thus all such bets are off.

    Now, if someone has compromised D *and* can hijack this tunnel D IW IS they have access to IS.

    Of course the real solution to the base problem is to have IS set up in some way to push data out to D, such that IW's user/D's admin doesn't have to play such silly and dangerous games in the first place. Any such 'administrator' setting up what has been described is incompetent.

    Now one last thing. The general attack hinges on an attacker's agent Aa being able to make use of the unix domain socket of the administrator's agent, Da. I'm very certain that when I tried this kind of attack on myself way back in 1998 or sooner it plain wasn't possible. If it is now then the (Open, whatever)ssh code has taken a step backwards. Basically some check was done on the origin of the messages on the socket, and if they weren't as expected the request to use the keys in the agent was denied. I think it was along the lines of "is the requesting process a (sub(sub...))child of myself?", presumably by following parent process IDs back up until it finds itself or init. Yes, ok, if the agent spawned any child that spawned a service that was subsequently compromised and not put in a new session group you could probably pull off the attack, but that is unlikely (as any service daemonising itself will end up in a new session group).
  • Because it's useful? (Score:1, Informative)

    by Anonymous Coward on Saturday May 27, 2006 @06:41AM (#15415213)
    ssh-agent is a godsend. My passphrase is > 50 characters in length - yours should be, too - and I don't want to type it more than once per login session. If you often use SSH, and have RTFM, you will be able to use ssh-agent properly, and it will save you a lot of time.

    ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key.

    Any process? Presumably this is only if you have deliberately made the socket files world-readable?

    The alternatives to ssh-agent are password authentication and host-based authentication. I'm sure I don't need to remind you about the security issues with those!

  • Re:Huh? What? (Score:5, Informative)

    by Anonymous Coward on Saturday May 27, 2006 @07:06AM (#15415260)
    The article is about a common misconfiguration with regard to agent forwarding. The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet. The admin must assume that root on these machines is compromised. Consequently he doesn't store his private keys on any of the DMZ machines. But what many overlook, possibly because they don't use the feature, is agent forwarding. Once the admin has logged into a compromised DMZ host, access to his credentials is extended to the DMZ host by that ominous socket. The file itself never leaves the admin's computer, but if agent forwarding is enabled, root on the DMZ host can now point other hosts on the intranet to the authentication facility on the admin's computer. 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).
  • by cortana (588495) <(ku.gro.stobor) (ta) (mas)> on Saturday May 27, 2006 @07:57AM (#15415342) Homepage

    Perhaps the author of the article should have read the source of the text you quoted [openbsd.org]. The preceding paragraph:

    ForwardAgent
    Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. The argument must be "yes" or "no". The default is "no".

    So the only people who will be caught out by this are those who:

    1. Blindly enable ForwardAgent without reading the security considerations mentioned in the manual.
    2. Set up ssh-agent without considering how it will expose their private key.

    Configuring the agent to prompt the user to confirm any signing request can be as complicated as putting the private key on a smart card (which will make the reader prompt for a PIN whenever the card recieves a signing request) or it can be as simple as using the -c option when calling ssh-add; therefore this does not seem like a big deal to me.

  • by biftek (145375) on Saturday May 27, 2006 @08:24AM (#15415399)
    A few versions ago OpenSSH added a -c "Require confirmation to sign using identities" to ssh-add to take care of this. Or using something like SSHKeychain on OS X so it'll ask for confirmation for multi-hop auth, but not for connections direct from your trusted machine.
  • by TomAnthony (927466) <slashdot&tomanthony,co,uk> on Saturday May 27, 2006 @08:33AM (#15415418) Homepage
    I've never needed to use ssh-agent, and during reading this I thought I'd read up on it a bit. So I google it and found an article [securityfocus.com], written in 2004, that had this to say:
    So the bad news is that your agent keys are usable by the root user. The good news, however, is that they are only usable while the agent is running -- root could use your agent to authenticate to your accounts on other systems, but it doesn't provide direct access to the keys themselves. This means that the keys can't be taken off the machine and used from other locations indefinitely.

    Is there any way to keep root from using your agent, even though it can subvert unix file permissions? Yes, you can. If you supply the -c option when you import your keys into the agent, then the agent will not allow them to be used without confirmation. When someone attempts to use your agent to authenticate to a server, the ssh-agent will run the ssh-askpass program. This program will pop up on your X11 desktop and ask for confirmation before proceding to use the key.

    At this point you're probably going to realize that we're still fighting a losing battle. The local root account can access your X11 desktop, all your processes, you name it. If you can't trust the root user, you're in trouble.

    However this will prevent root on machines to which you've forwarded the agent from accessing your agent.
  • Re:So... (Score:5, Informative)

    by Dan Ost (415913) on Saturday May 27, 2006 @08:38AM (#15415427)
    No, it's not really a man in the middle attack.
    It's more of a credential hijacking scenario where
    the attacker waits for you to authenticate with
    the compromised machine, forward your credentials
    to that machine, and then the attacker uses those
    credentials to reach other machines that honor those
    credentials.

    This would be more like you signing in, walking
    away from your computer, and someone else walkup up
    to the computer and doing stuff as you except that
    they get to act as you while you're still acting
    as you.

    Did that help?
  • by Zygamorph (917923) on Saturday May 27, 2006 @09:18AM (#15415556)
    Don't use SSH to poke a hole in the firewall separating your DMZ from the intranet.
  • Re:Huh? What? (Score:2, Informative)

    by Lord Ender (156273) on Saturday May 27, 2006 @01:29PM (#15416424) Homepage
    DMZ hosts are typically configured so that they can NOT connect out to hosts outside the DMZ. This is enforced by firewall restrictions. As long as this is done, there is no problem.
  • by Lord Ender (156273) on Saturday May 27, 2006 @02:01PM (#15416596) Homepage
    Care to explain how a remote root login is any more dangerous than a remote user login when the user can sudo to root?
  • by Goodbyte (539941) on Saturday May 27, 2006 @09:56PM (#15418489) Homepage
    From what I understand of the summary the poster is refearing to the fact that agent forwarding is insecure. Now in the man page for OpenSSH we have:

    -A Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file.

    Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

    So what's the news?

* * * * * THIS TERMINAL IS IN USE * * * * *

Working...