Re: HTTPS proxy tool that resigns SSL certs

[Rogan Dawes <discard () dawes za net>]

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.
------------------------------------------------------------------------------