SSH Tunneling part 3 - Where does the crypto end?

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  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
brian () hackinglinuxexposed com.

--------------------------------------------------------------------
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-request () lists onsight com.

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 majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.