Date: Tue, 26 Jun 2012 09:14:58 +0200 From: "Andrej (Andy) Brodnik" <andy@brodnik.org> To: freebsd-security@freebsd.org Subject: Re: Hardware potential to duplicate existing host keys... RSA DSA ECDSA was Add rc.conf variables... Message-ID: <4FE96172.6090109@brodnik.org> In-Reply-To: <20120626034727.GA56503@DataIX.net> References: <86pq8nxtjp.fsf@ds4.des.no> <20120625223807.4dbeb91d@gumby.homeunix.com> <4FE8DF29.50406@FreeBSD.org> <20120625235310.3eed966e@gumby.homeunix.com> <4FE8F814.5020906@FreeBSD.org> <20120626015323.02b7f348@gumby.homeunix.com> <4FE9094A.4080605@FreeBSD.org> <20120626024624.4c333bd2@gumby.homeunix.com> <4FE916AA.6050503@FreeBSD.org> <20120626035609.0d0f061b@gumby.homeunix.com> <20120626034727.GA56503@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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})
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FE96172.6090109>