[18286] in bugtraq
Re: sshmitm, webmitm
daemon@ATHENA.MIT.EDU (Boris Lorenz)
Thu Dec 21 15:30:57 2000
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
Message-Id: <XFMail.001221172731.bolo@lupa.de>
Date: Thu, 21 Dec 2000 17:27:31 +0100
Reply-To: Boris Lorenz <bolo@LUPA.DE>
From: Boris Lorenz <bolo@LUPA.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20001220175502.B1545@students.cs.unibo.it>
Hi,
On 20-Dec-00 Samuele Giovanni Tonon wrote:
> On Mon, Dec 18, 2000 at 10:18:02AM -0500, Dug Song wrote:
>> sshmitm and webmitm have been released as part of the new dsniff-2.3
>> package, available at:
>>
>> http://www.monkey.org/~dugsong/dsniff/
>>
>> these tools perform simple active monkey-in-the-middle attacks against
>> SSH and HTTPS, exploiting weak bindings in ad-hoc PKI.
>
>
> i've used it (sshmitm) last night and it seems it works only under certain
> condition:
> - you connect to a machine querying a DNS instead of putting the ip in
> /etc/hosts
IMO that's no real condition. There are lots of networks with both internal and
external nameservers resolving names instead of putting some (more or less)
dynamic host addresses in a hosts file.
> - you have no ~/.ssh/known_host or you haven't the public key of the host you
> want to connect and you have StrictHostKeyChecking set to no (default) .
You name the problem - default settings. They reflect a typical setup for ssh
and do not dig deeper into certain security issues. Basically it's a RTFM
problem but there are enough admins and users out there refering to ssh as some
kind of ultima ratio in encrypted data transfer. Some think that it is enough to
download, make and use ssh to be on the safe side. However, tools like dsniff
proof them to be wrong.
> - the forger must know you'll connect to it and must be on the path between
> you
> and the machine .
Well... If the attacker is really willing and able he or she will probably find
some weakly secured host on the packets' way to the victim system. Afterwards,
a little traffic analysis will do the trick to know when it's best to fire up
sshmitm.
And: The enemy lies within - an evil employee might know that the
organisation's admin starts to work at 9 o'clock in the morning and logs into
some host via ssh...
[...]
> Samuele
[...]
---
Boris Lorenz <bolo@lupa.de>
System Security Admin *nix - *nux
---
