Public storage for public keys

[Gary E. Miller]

Yo Ed!

No need to intercept DNS traffic.  All you have to do is get the
victim DNS server to visit the hijackers DNS server.

The hijacker puts a bogus glue record on his DNS server.  Then gets the
victim's DNS to do a legit DNS query to his DNS server.  Maybe he does
a telnet or ftp to the victim host and when the victim host does the
reverse DNS check it goes to the hijackers DNS server.  The hijackers
DNS server then returns legit answer to the legit request and also
returns the bogus glue record.

A while back a guy did this and was sending out new NS records for ICANN.
He was able to hijack the entire ICANN domain on all his victims this
way.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Mon, 14 Jan 2002, Ed Phillips wrote:

> Just for giggles, let's say we're distributing public host keys via DNS,
> and JH (Joe Hacker) is trying to use this as an advantage to break into a
> system that is trusting the DNS-supplied public keys.  In order to cause a
> compromise, JH would need to somehow convince a system running the ssh
> client (system A) that the sshd server it THOUGHT it was connecting to
> (system B) is the real thing when really it is not.  In order to do this,
> JH would have to first, intercept DNS traffic from A DNS and return a
> spoofed public host key for system B (okay - that should be easy enough
> for JH).  Then the hard part - JH would have to play man-in-the-middle
> between A and B enough to convince A that the spoofed host key for B is
> okay... but how can JH do this without knowing the REAL private host key
> for system B?  What am I missing?