[ISN] SSH Tunneling part 3 - Where does the crypto end?

From: InfoSec News (isnat_private)
Date: Mon Mar 17 2003 - 03:13:29 PST

  • Next message: InfoSec News: "[ISN] Security firm finds a hole in Sun One"

    +------------------------------------------------------------------+
    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  16-March-2003                                                   |
    |  http://www.hackinglinuxexposed.com/articles/20030316.html       |
    +------------------------------------------------------------------+
    
    This issue sponsored by Hacking Linux Exposed, Second Edition.
    
    Hacking Linux Exposed, Second Edition is out in stores and online.
    This new version of the best-selling first edition includes almost
    200 new pages of hacking and cracking materials for Linux and
    Unix-like systems. HLEv2 shows you, step-by-step, how to defend
    against the latest Linux attacks by understanding the hacker's
    methods and sinister thought processes.
    
    For reviews, sample chapters, or to order, go to http://
    www.hackinglinuxexposed.com/books/  
    
    --------------------------------------------------------------------
    
    SSH Tunneling part 3 - Where does the crypto end?
    By Brian Hatch
    
    Summary: Want to encrypt an otherwise cleartext transmission? SSH
    Tunneling may be the tool for you.
    
    Over the last two weeks I've shown the syntax of SSH tunnels. Either
    can be created using command line arguments or via entries in ~/.ssh/
    config, as follows:
    
    Local Forward specified on the command line
        -L port_on_client:destination_host:destination_port
       
    Local Forward defined in ~/.ssh/config
        LocalForward port_on_client:destination_host:destination_port
       
    Remote Forward specified on the command line
        -R port_on_server:destination_host:destination_port
       
    Remote Forward defined in ~/.ssh/config
        RemoteForward port_on_server:destination_host:destination_port
    
    Most frequently, people use SSH tunnels when the tunnel's endpoint is
    either the SSH client or server. For example they may have an account
    on the IMAP mail machine at their ISP so they would SSH to it and
    point the forward at localhost (the IMAP server):
    
      # set up forward
      home_desktop$ ssh mail.my_isp.net -L 1143:localhost:imap
     
      # read email via the encrypted tunnel
      home_desktop$ mutt -f imap://user@localhost:1143/
    
    Or they're doing a remote forward in a similar way, for example this
    firewall-traversing, security policy-violating version:
    
      # connect out to our home machine before going home for
      # the evening
      work_mailserver$ ssh home_machine -R 1143:localhost:imap
     
      # read our work from home through the tunnel
      # without using the corporate-mandated PPTP VPN.
      home_machine$ mutt -f imap://user@localhost:1143/
    
    However, there is no reason the endpoint of the tunnel need to be the
    SSH client or server machine. For example if you did not have shell
    access to the work_mailserver machine in the second case above[1]
    then you could still create a functional SSH tunnel as follows:
    
      # From your Linux desktop at work, you SSH to your machine
      # at home.  Connections through the tunnel from home will
      # get forwarded to work_mailserver, which is a different
      # machine at your office.
      work_desktop$ ssh homemachine -R 1143:work_mailserver:imap
    
    In this case the IMAP connection is *not* encrypted end-to-end. It is
    encrypted inside the SSH tunnel from home_machine to work_desktop,
    but is cleartext from work_desktop to work_mailserver. This means
    that your email content and your mail password is being sent over the
    work network in the clear.
    
    Is this a problem? It depends on how much security you need. If you
    normally read your email from work_desktop using plain unencrypted
    IMAP, then your password is already going across the work network in
    the clear. The only parts of this connection that are unencrypted are
    the same parts that were already unencrypted when you checked your
    email at the office. So, you have successfully enabled yourself to
    check email from home in a no-less-secure way than you do being in
    the office itself. Excellent.
    
    So let's revisit the first example above. Say we have don't have SSH
    access to mail.my_isp.net. This means you can't directly log into
    mail.my_isp.net with a LocalForward and have your IMAP connection
    encrypted end-to-end. However if you have a shell account on
    shell.my_isp.net that is available via SSH, you can do the following
    instead:
    
      home_desktop$ ssh shell.my_isp.net -L 1143:mail.my_isp.net:imap
    
    Your IMAP connection will only be unencrypted between the ISP's shell
    server and mail server - the rest of it will be completely encrypted.
    You could do this from anywhere, from work, a friend's house, or an
    Internet cafe.
    
    Again, is this safe? Well, the only people who can read the cleartext
    traffic between the shell machine and the mail machine are those
    folks who have root access on one of the two machine, or a machine
    that can sniff the network traffic between those two machines.
    Hopefully, that would only include the legitimate administrators of
    the ISP, who would have several other ways of reading your email or
    resetting your password anyway. If an attacker has this level of
    access on the ISP's machines, your data was already in trouble. So
    again, setting up an SSH LocalForward allows you to check email from
    anywhere with encrypted connections except for that last leg which
    was never crypto-enabled anyway.
    
    This was, in fact, the very setup that Alice was using to check her
    email.[2] Alice didn't have shell access on her ISP's mail server,
    but was using a LocalForward from home and/or work to access the mail
    server (via POP in her case) with an encrypted connection for all but
    that last leg.
    
    Bob said it wasn't secure. Alice said it was. Both Alice and Bob
    understood that the last bit of her connection was not encapsulated
    in any encryption, so I did not need to clear that up for them, which
    was the point of contention I imagined they had. So, to their
    original question "is Alice's email access secure" I had to reply "As
    secure as the link between the shell server and the mail server." I
    don't think they were happy with my response. After much debate, we
    decided that they both knew the facts, and that her threat model
    considered the short unencrypted connection to be secure enough, and
    his did not. They agreed to disagree, and I decried that they both
    needed to buy each other dinner.
    
    Tunnel Forwarding Examples
    
    Some time next month[3] I'll dedicate an issue of the newsletter to
    many sample SSH tunnels. Most uses of tunnels are variants of the
    examples I've already given - tunneling POP, IMAP, or SMTP, getting
    into your office from home by using a RemoteForward back through your
    firewall for SSH or a web proxy, etc. If you have any weird useful
    tunnels you like to use, drop me a line and I'll include them.
    
    Happy Birthday Results
    
    Thanks to all 50ish people who wished my sister a Happy Birthday. You
    guys confused and amused her more than I would have imagined. What an
    excellent turnout.[4]
    
    And congratulations to Jennifer Welch, who was person #20 and gets a
    free signed copy of "Building Linux VPNs."
    
    NOTES:
    
    [1] Say they're running Exchange, god forbid.
    
    [2] Yes, believe it or not, I'm finally getting back to the question
    that started this whole topic. Luckily I contacted Alice and Bob
    before I started writing it.
    
    [3] I think I need to give everyone a break from crypto-related
    issues before they kill me.
    
    [4] I suspect that the possibility of free stuff might have helped,
    but I'm always willing to bribe.
    
                                -------------                            
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He's really going to try to
    stop talking about crypto for a while. Promise. Well, with the
    exception of the upcoming Easter Egg Hunt. Brian can be reached at
    brianat_private
    
    --------------------------------------------------------------------
    This newsletter is distributed by Onsight, Inc.
    
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    linux_security-requestat_private
    
    Archives of this and previous newsletters are available at
    http://www.hackinglinuxexposed.com/articles/
    
    --------------------------------------------------------------------
    
    Copyright 2003, Brian Hatch.
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Mon Mar 17 2003 - 05:51:31 PST