Re: SSL MITM fun.

["Chris Weber " <chris () casabasecurity com>]

You wouldn't actually need a .CN domain to do this, a .ORG would do the
trick.  But I'm skeptical of the slides.  From the screenshots in the
presentation it looks like U+FF0F FULLWIDTH SOLIDUS is being used as the
U+002F homograph. If that's the case, it would have to be an older Firefox
browser because current major browsers seem to (mostly) normalize with form
KC as defined by the Nameprep RFC.  This normalization reduces U+FF0F to
U+002F.  If it's one of the other homographs that are visually similar to
the example screenshot, then current browsers seem to handle those cases
well too.  Opera spits out illegal-url messages, and the most others just
convert to Punycode in the status bar and URL. Chrome seems to have an issue
with normalizing U+FF0F in particular which is probably a bug but not a
vulnerability.

I wouldn't say IDN is dead but it may be mutilated - there are significant
differences between the way browsers handle it.  Opera, Firefox, and Safari
have whitelisted domains which are allowed to display IDN characters in the
URL and status bar.   These includes .ORG which is why you don't need a .CN
registrar, just a good subdomain spoof.  

But these three take extra steps to prohibit certain characters like /
lookalikes.  There's one lookalike in particular that's overlooked in their
filters but it's obviously not the one in the Moxie's screenshot. Firefox
has a configurable list of prohibited characters. IE allows limited
mixed-script in certain situations.  I don't know what Chrome intends to do.

-Chris

-----Original Message-----
From: dailydave-bounces () lists immunitysec com
[mailto:dailydave-bounces () lists immunitysec com] On Behalf Of Dan Moniz
Sent: Thursday, February 19, 2009 1:47 PM
To: Alexander Sotirov; George Ou
Cc: dailydave () lists immunityinc com
Subject: Re: [Dailydave] SSL MITM fun.

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

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave