Penetration Testing mailing list archives
Re: HTTPS proxy tool that resigns SSL certs
From: Rogan Dawes <discard () dawes za net>
Date: Wed, 07 Jun 2006 11:05:25 +0200
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: CenzicConcerned 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.
------------------------------------------------------------------------------
Current thread:
- Re: HTTPS proxy tool that resigns SSL certs Rogan Dawes (Jun 01)
- <Possible follow-ups>
- Re: HTTPS proxy tool that resigns SSL certs Robert BARABAS (Jun 01)
- Re: HTTPS proxy tool that resigns SSL certs Tobias Glemser (Jun 01)
- Re: HTTPS proxy tool that resigns SSL certs Huzeyfe Onal (Jun 02)
- Re: HTTPS proxy tool that resigns SSL certs Phil Frederick (Jun 05)
- Re: HTTPS proxy tool that resigns SSL certs Rogan Dawes (Jun 06)
- Re: HTTPS proxy tool that resigns SSL certs Phil Frederick (Jun 05)
- RE: HTTPS proxy tool that resigns SSL certs Steve Abatangle (Jun 06)
- Re: HTTPS proxy tool that resigns SSL certs Nathan Keltner (Jun 06)
- Re: Re: HTTPS proxy tool that resigns SSL certs one2 (Jun 06)
- Re: HTTPS proxy tool that resigns SSL certs Rogan Dawes (Jun 07)
- RE: HTTPS proxy tool that resigns SSL certs Ritesh Rekhi (Jun 08)
- Re: HTTPS proxy tool that resigns SSL certs silentw (Jun 08)
- Re: HTTPS proxy tool that resigns SSL certs Rogan Dawes (Jun 09)
- Re: HTTPS proxy tool that resigns SSL certs Rogan Dawes (Jun 07)