Dne 6/26/12 5:47 AM, piše J. Hellenthal:
On Tue, Jun 26, 2012 at 03:56:09AM +0100, RW wrote:
On Mon, 25 Jun 2012 18:55:54 -0700
Doug Barton wrote:
My point is that the ssh protocol is designed specifically to
prevent what you're describing.
If you've obtained the server's private key by breaking the public
key you can accept connections from clients just as if you are are
the real server.
Right. That's what Dag-Erling and I have been saying all along. If you
have the private host key you can impersonate the server. That's not a
MITM attack. That's impersonating the server.
If only the server is authenticated, then impersonating the
server is the only impediment to a MITM attack (aside from
intercepting the netwok traffic). If the server has client keys then
obviously it wont work.
If the server doesn't store client keys then there's
nothing to stop you establishing a separate connection with any
client side key and performing a MITM attack.
Last chance ... how, precisely, do you claim to be able to do this?
What's to stop you doing it where there's no authentication of clients?
All the attacker needs to do is establish an ssh connection to the
server and relay what he's getting from the original client. The
situation is analogous to performing a MITM attack against a website
where the ssl keys have been stolen by the attacker.
Client -> FakeSSHD -> RealHOST
If FakeSSHD has RealHOST's ssh_host_*_key's then they are able to
impersonate RealHOST and prompt for a password that no matter wether it
is correct will just silently drop all further traffic and relay to the
RealHOST in which they never realize the difference while the operator
of FakeSSHD now has a password for RealHOST from the user. The user
would not be the wiser to just think there is something wrong in their
environment or the servers environment and will be left clueless.
Still have yet to hear of something like this happening but its real
enough considering some of the exploits out there.
But this is all way to far beyond what this thread is supposed to be
about and beyond the scope of FreeBSD entirely so lets just let it drop
or pick it up on FD.
However, in the above scenario, the RealHOST will answer using Client's
public key which FakeSSHD will not be able to understand without having
Client's private key.
LPA (== {Lep pozdrav! Andrej}_{Slovene} == {Best Regards, Andrej})
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
