Re: SSL MITM fun.

[Dan Moniz <dnm () pobox com>]

On Thu, Feb 19, 2009 at 3:07 PM, Alexander Sotirov <alex () sotirov net> wrote:

> On Thu, Feb 19, 2009 at 01:04:33PM -0500, Dan Moniz wrote:
> > On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel <dave () immunityinc com> wrote:
> > > 1. Register a .cn address and use unicode character for / and ? to
> > > have HTTPS://www.paypal.com/?domain.cn?<some args> validate
> >
> > Unless I'm missing something, this is essentially what Eric Johanson
> > said in 2005 about IDN:
> > http://www.shmoo.com/idn/homograph.txt
>
> Eric used the IDN to register p&#1072;ypal.com, which was displayed as
> paypal.com. According to Moxie's presentation, this doesn't work any more
> because Firefox always shows the non-IDN version of the domain name for
> the .com TLD. Firefox will show the above domain as xn--pypal-4ve.com.
>
> The new idea in this presentation is to use a .cn domain, but use UNICODE
> characters that look like '/'. The attacker registers a domain like
> www.google.com/blahblahblah.cn, and since this is a .cn domain, the
> browser decodes the IDN name and displays the '/' character. Very cool.
>
> This means that as long as there is one TLD which allows IDN, attackers
> can spoof any address in any other TLD. IDN is dead.

I guess what I was getting at is that this still relies on a lack of
canonicalization of Unicode characters to codepoints, and takes
advantage of a character appearing to be something it actually isn't,
in this case, one including something that looks like a slash (or
virgule) but isn't. Am I still missing something?

Interestingly, the slash we're all familiar with on "standard'
keyboards is U+002F, named SOLIDUS in Unicode, despite the fact U+2044
is typographically a solidus, yet *it* is named FRACTION SLASH in
Unicode, in flagrant violation of hundreds of years of typesetting
convention; Somewhere, Bringhurst is rightfully incensed.

> > > 3. Sign the leaf cert with your leaf cert. This abuses an
> > > implementation flaw in OpenSSL, etc.
> >
> > If you can sit between endpoints, modify traffic, and you control one
> > of the eventual endpoints anyway, and only you're jumping through all
> > these hoops to maintain the illusion for the unsuspecting user, why
> > not just take control of DNS and *actually* MITM SSL?
>
> No, ever if you sit between endpoints you are not necessarily in control
> of the endpoints. For example, sitting in a Starbucks will let you modify
> the traffic for other WiFi clients, but you don't have access to the
> clients themselves.

My understanding of the attack presented was that the attacker was
able to at least sit between endpoints and modify HTTP responses (e.g.
302 redirect) from the legitimate destination host en route back to
the requesting host towards the end of rewriting them to point to the
new .cn domain name. In addition, the host on the other end of that
.cn domain name was attacker-controlled.

Given this, why not just try to gain control of DNS and actively MITM
SSL instead of rewriting HTTP responses? The request to go to
http://www.secure.example.com/ goes to the attacker's bump on the
wire, the attacker can independently fetch content from the real
http://www.secure.example.com/ and follow whatever legitimate 302
redirect it returns to point to https://www.secure.example.com/,
initiate and handle the SSL/TLS setup, and either establish real SSL
with the requester as well (with a generated cert signed by a cert
trusted by the browser), or do the same thing (for whatever reason)
and just feed back pages that look right but aren't.

As far as I can tell, the trade-offs are:

1. One way you aren't really supporting the requester using SSL, but
they likely won't notice or care. You need to register an appropriate
IDN domain name with a TLD that supports IDN, like .cn. You need to
sit on the network to rewrite 302 redirect responses from the
destination host back to the requester to point to your domain name.
You need to run your malicious attacker-controlled endpoint referenced
by your domain name.

2. The other way you can force HTTP if you want to, or you can support
SSL to the requester with a cert signed by a trusted cert which would
result in no cert warnings. You can observe and modify all the traffic
you want, including pointing to other sites if you so choose, but you
don't need to. You have to take over DNS as far as the requester is
concerned, at least. The requester never need see anything other than
what the legitimate destination's URLs should and do look like under
normal circumstances.

Did I miss something?

On Thu, Feb 19, 2009 at 3:27 PM, George Ou <george_ou () lanarchitect net> wrote:
> You don't need to MITM SSL, nor is it easy to do.
>
> When you fake an SSL cert, the user gets a certificate warning which 9 out
> of 10 people ignore anyways.  Taking control of DNS does nothing to change
> this.

Eddy Nigg documented an example with cert resellers doing zero
verification before issuing a cert for mozilla.com, which was trusted
by Firefox out of the box, as late as December 23, 2008 (cert issued
for one year, starting on December 22, 2008). This would raise no
warnings. I find it hard to believe there are provably no resellers
today, nor will there be any in the future, that wouldn't necessarily
do the same thing. This plus the ability to control domain names
resolution and it seems easy (subject to the trade-offs mentioned
above).
https://blog.startcom.org/?p=145


-- 
Dan Moniz <dnm () pobox com> [http://pobox.com/~dnm/]
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave