From: Rogan Dawes (discard@dawes.za.net)
Date: Wed Jun 07 2006 - 05:05:25 EDT
one2@onetwo.com wrote:
> Thanks to everyone who responded. Appologies for the question being a
> little vague - I was a little eager to gain an answer before knowing
> my final question.
>
> My ultimate goal is to perform a MITM attack on an SSL connection,
> and be undetected by the user - ie. no security prompt by the browser
> - and without the victim system being previously compromised, or
> having access to import a certificate into the browser.
If this was actually possible in any form, there would be a significant
problem with the entire SSL protocol, or else with the CA process.
Your approach won't work, since your cert for attacker.com will most
likely never match the URL that the victim's browser is expecting, and
they will get a warning. Modern browsers trigger warnings if:
a) the CN in the cert does not match the host portion of the URL that
the browser is requesting.
b) The cert is either not yet valid, or is expired (current date is not
within the "valid from" and "valid until" range)
c) the cert presented was not signed by a CA that is recognised by the
browser
Everything hinges on your being able to get a cert THAT MATCHES THE SITE
THAT THE VICTIM IS GOING TO signed with a key that the browser will
accept (i.e. with a key that matches a CA key ALREADY loaded into the
browser) and valid for the current date.
There are a couple of approaches to this:
1. Compromise a recognised CA's verification checks to convince them to
issue you a certificate for the target site. This is unlikely. However,
VeriSign has issued certs in Microsoft's name in the past, so not
completely impossible. This also limits you to the particular sites that
you manage to get certs for.
2. Create your own CA cert, and get it signed by one of the recognised
CA's. Then you can use it to sign additional certificates that
correspond to the sites that you wish to intercept. AFAIK, you can't
simply use an email certificate for this, as the cert itself has a
"purpose" for which it is valid (encryption/signing/CA/etc), and email
certs do not have the necessary attributes. However, if you were able to
do this, you'd be able to create certs for ANY site you wish to
intercept. Needless to say, this is also VERY unlikely.
3. Create your own CA cert, and get the cert loaded into the browser of
your victim. Similarly to item 2, you'd be able to create certs for any
site you wish to intercept. To do this, you'd need control over the
victim computer.
4. This is closest to what you suggest below. Intercept HTTP (not HTTPS)
requests for your target site, and redirect them to your own SSL Server
at www.attacker.com, possibly in a frame, so that the URL does not
appear to be invalid. However, this means that the URL will not be
HTTPS, and that the browser will likely warn you about mixed secure and
insecure content. If you don't use the frame, then the user will be able
to see the URL of your attacker.com site. You MAY be able to combine
this with browser vulnerabilities that allow you to obscure the title
bar and other browser components.
>
> The response that came closest to what I was after was from Phil
> Fredrick. With a little modification to his solution, and assuming we
> are on the same lan as the victim, we have the following;
>
> - Attacker purchases a valid SSL certificate for www.attacker.com -
> Attacker sets up website https://www.attacker.com on the attacking
> machine - Attacker performs DNS Spoofing to redirect victim https
> requests to www.attacker.com - This provides a valid SSL certificate
> to the victim - ie. no security prompt
This is where your scenario falls down. The cert will not have the
correct Canonical Name to match the URL that the victim typed in. So you
WILL get a warning.
> - Attacking machine gets and
> passes on (proxies) the original page requested by victim (also
> allowing modification to the page as necessary)
>
> Basically you are still acting as a proxy, but using DNS spoofing and
> a valid SSL cert, the victim is not prompted by the browser.
>
> The only flaw with this process is that the victim will now have
> https://www.attacker.com in the address bar of their browser. One
> solution is to try to make the SSL certificate's URL as close as
> possible to the site you wish to spoof (www.h0tmail.com), so that it
> isn't easily noticeable to the end-user. This would, however, limit
> the attacker to intercepting hotmail requests ... My preferable
> solution, would be to either to use an IE exploit that allows
> spoofing in the address bar (assuming IE), or simply buffering the
> URL so that the end user can't see www.attacker.com
>
>
>
> Other concepts that I was looking at, and would like to hear
> responses on, are;
>
> 1. Using a null-cipher, allowing an attacker to present the 'SSL'
> pages to the user over HTTP - and therefore not causing the browser
> to produce a security warning. I understand that some companies do
> this to perform content filtering on SSL connections. Would be
> interested to hear if any tools implement this functionality for MITM
> attacks.
Most browsers will not negotiate a NULL cipher. Even if you do, the
server still has to identify itself.
>
> 2. Using "certificate chaining", which may allow an attacker to sign
> whatever certificates they like, and will be trusted. RSA (aka
> "verisign") sells a certificate service seemingly specifically for
> this purpose - RSA Root Signing Service. More info on this below;
>
> RSA Security - RSA Root Signing Service
> http://www.rsasecurity.com/node.asp?id=1267
>
Yes, this is my item 2 above. Good luck convincing VeriSign that you're
legit, and signing your CA cert.
> So this means that using the RSA Root Signing Service I would be able
> to sign a certificate for www.hotmail.com and have it chained back to
> RSA Security's trusted root, meaning that browsers would accept the
> certificate as valid - and no security prompt.
>
> Looking forward to your responses.
>
> One2
>
regards,
Rogan
------------------------------------------------------------------------------
This List Sponsored by: Cenzic
Concerned about Web Application Security?
Why not go with the #1 solution - Cenzic, the only one to win the Analyst's
Choice Award from eWeek. As attacks through web applications continue to rise,
you need to proactively protect your applications from hackers. Cenzic has the
most comprehensive solutions to meet your application security penetration
testing and vulnerability management needs. You have an option to go with a
managed service (Cenzic ClickToSecure) or an enterprise software
(Cenzic Hailstorm). Download FREE whitepaper on how a managed service can
help you: http://www.cenzic.com/news_events/wpappsec.php
And, now for a limited time we can do a FREE audit for you to confirm your
results from other product. Contact us at request@cenzic.com for details.
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:03 EDT