RE: ssh holes? Trojans? [long]

[Ben Nagy <bnagy () sa volante com au>]

> -----Original Message-----
> From: Gregory Hicks [mailto:ghicks () cadence com]
> Sent: Tuesday, 19 September 2000 7:58 AM
> To: firewall-wizards () nfr net
> Subject: [fw-wiz] ssh holes? Trojans?
>
>
>
> We have a requirement to monitor, for legal reasons, everything that
> goes off the company network.

IANAL, but is this requirement best-effort, or absolute? If you have an
absolute requirement that no unmonitored traffic leaves your network then
you WILL NOT be able to comply without disconnecting it from the rest of the
world.

There is too much good steganography and crypto stuff available - it's not
possible to stop a determined user from leaking information out of the
network.

> Recently, we closed access to port 22 (ssh).  The reasoning 
> was that we
> could monitor things like ftp, telnet, mail, et al because when these
> data streams crossed the firewall, they were '...in the clear
> (unencrypted).'  And yes, I know that ssh can be tunneled on any other
> port...
[snip]
> Now then, what we would like to do is to set up an ssh 'proxy' inside
> the DMZ so that whatever is passed to the sshd on the proxy host
> crosses our monitoring hosts 'in the clear'.
>
> Does anyone know of such a beast?  Has anyone used it?  I 
> only found an
> unfinished section of C code...

Nice problem. If you haven't already, you should look at the IETF secsh
working group pages - they have a reasonable description of the SSH
protocol, and mention some security issues.[1]

In summary, though, it's quite hard to do what you want. What you're
effectively trying to do is mount an active man-in-the-middle (MitM) attack
against the protocol. Sadly, the ephemeral keying in the SSH transport layer
is signed Diffie-Hellman, which is resistant to MitM.

Even requiring all clients to lodge their private keys with your proxy
(which makes me shudder) won't help you compromise the keying - that's the
way DH works. It will only let you impersonate them, not eavesdrop on them. 

Luckily (depending on your point of view) there is one flaw - DH in its
purest form offers no authentication - it's just a method for secure key
exchange. SSH adds some signing to the basic DH (of course) to stop the
trivial active MitM vulnerability.

Therefore, your best bet is to mount an active MitM attack when the client
first connects to a host. At this stage, there is an (insecure) option to
accept the host's key on faith. Your proxy can then subvert the protocol by
pretending to be the remote host, passing its own public key, and doing DH
with the client and then DH with the remote. This will ONLY work as long as
the clients don't already have the remote host's key and they don't acquire
it by some out-of-band method.

All in all, though, it's sucky. You can't make it work if the clients don't
want to let you make it work. This is probably why there is nothing around
that does what you want.

If you were to provide a non-transparent SSH gateway, that might work.
Clients can telnet (or SSH) to your gateway, and from there start a new SSH
connection to the outside world. You could then snoop the traffic before it
entered the second tunnel. They still get the protection of SSH over the
Internet and you still get to snoop the traffic. This requires user
co-operation, though. You can't do it in secret. I'll leave the fine details
as an exercise ;)

[snip]
> Assist appreciated in advance.
>
> Regards,
> Gregory Hicks

Cheers,
 
[1] http://www.ietf.org/html.charters/secsh-charter.html
--
Ben Nagy
Amateur Crypto Pontificator, Volante Solutions
PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520 

_______________________________________________
Firewall-wizards mailing list
Firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards