Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Community > MacNN Lounge > SSL MITM Exploits

SSL MITM Exploits
Thread Tools
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Oct 21, 2009, 02:16 PM
 
I know I'm late to find this news, but I just started reading about SSL Man in the Middle attacks. I find these revelations quite disturbing. For those who don't know about the issue and the activities of Moxie Marlinspike, you can read up on the exploits here, and more recently here.

If you want my executive summary, an attacker can (in one of the attack types) register and obtain a certificate for an exploitative subdomain the attacker created (i.e. paypal.evilsite928dag.com/) and then sniff around the local network until someone goes to PayPal. The attacker can then somehow covertly substitute the bogus certificate for PayPal's, and due to a flaw in the way browsers validate the certificates the bogus cert will not only appear to be valid but will also continue to display the site as https://www.paypal.com/ instead of https://www.paypal.evilsite928dag.com/. Crazy.

Until now I thought that if the URL looked correct and the padlock was shown, the encryption could generally be trusted. I consider myself an advanced web user, but I've only really stopped to examine a cert perhaps 0.1% of the time. Now I have to be much more deliberative in how I use encrypted sites. I can't find any information about whether or not the browser vendors have done anything about these attack vectors since they first started appearing.

One thing that I don't really understand is why browsers don't automatically recognize that the certificate is for a subdomain of a different domain name than the one that the user is currently at. Shouldn't a "certificate address does not match URL" error come up?
( Last edited by Big Mac; Oct 23, 2009 at 03:02 AM. )

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Big Mac  (op)
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Oct 21, 2009, 11:10 PM
 
No one cares?

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Laminar
Posting Junkie
Join Date: Apr 2007
Location: Iowa, how long can this be? Does it really ruin the left column spacing?
Status: Offline
Reply With Quote
Oct 21, 2009, 11:33 PM
 
Nope.
     
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Oct 21, 2009, 11:42 PM
 
Originally Posted by Big Mac View Post
I know I'm late to find this news, but I just started reading about SSL Man in the Middle attacks. I find these revelations quite disturbing. For those who don't know about the issue and the activities of Moxie Marlinspike, you can read up on the exploits here, and more recently here.

If you want my executive summary, an attacker can (in one of the attack types) register and obtain a certificate for an exploitative subdomain the attacker created (i.e. paypal.evilsite928dag.com/) and then sniff around the local network until someone goes to PayPal. The attacker can then somehow covertly substitute the bogus certificate for PayPal's, and due to a flaw in the way browsers validate the certificates the bogus cert will not only appear to be valid but will also continue to display the site as https://www.paypal.com/ instead of https://www.paypal.evilsite928dag.com/. Crazy.

Until now I thought that if the URL looked correct and the padlock was shown, the encryption could generally be trusted. I consider myself an advanced web user, but I've only really stopped to examine a cert perhaps 0.1% of the time. Now I have to be much more deliberative in how I use encrypted sites. I can't find any information about whether or not the browser vendors have done anything about these attack vectors since they first started appearing.

One thing that I don't really understand is why browsers don't automatically recognize that the certificate is for a subdomain of a different domain name than the one that the user is currently at. Shouldn't a "certificate address does not match URL" error come up?

An SSL cert has no way of actually verifying the machine's hostname, it can only verify that the URL in the address bar serves a cert offered by a trusted authority. You could add an entry to your /etc/hosts file that maps paypal.com to whatever IP you want, and if you can serve an SSL cert from a trusted authority that your browser won't complain about with the common name that matches the domain you are accessing, all is good.

The key here is in the issuing of the SSL cert. Any trusted authority should verify your ID matches your certificate information. If they don't do this, they are negligent.
     
Big Mac  (op)
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Oct 22, 2009, 05:15 AM
 
I'm confused. I don't care about the machine's hostname. What I don't understand is why the browser can't look at the URL and match it to the full certificate URL and put up an error if they don't match. paypal.com is different from paypal.foositebar123.com, but apparently browsers don't realize that. If the browser can't compare the URL of the current page to the URL listed on the cert and throw up a non-matching address alert if they don't match, then that's a giant, inexcusable security hole. If it's really that easy to bypass SSL, I'm astonished it took so many years for hackers to catch on.

Placing all the responsibility on CAs isn't going to help. They'll pump out a cert for anyone with the cash. This appears to be a fundamental problem with SSL and how browsers handle it.
( Last edited by Big Mac; Oct 22, 2009 at 05:22 AM. )

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
Oct 22, 2009, 07:22 AM
 
The trick in all man-in-the-middle attacks on any type of connection is to "insert" the fraudulent identity/certificate/key in the establishing/established conversation. Both ends should be verifying that what they're getting is indeed from the correct distant end, which is part of the SSL authentication (requester's ID and server's ID are part of the initial negotiation). I don't know the details of the protocols with SSL, but it's pretty solidly built and would be rather hard to intrude into without at least tripping some safeguards.

Glenn -----OTR/L, MOT, Tx
     
Big Mac  (op)
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Oct 22, 2009, 09:38 AM
 
That's what I would have thought, Glenn, but that's not at all the case if I'm understanding how these exploits are being used. I know it's not trivial to do and takes knowledge to sniff encrypted communications, but they make it sound pretty easy relatively speaking.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
Oct 22, 2009, 11:44 AM
 
My browsers all check certificates, and if there's any issue, INCLUDING the cert not matching the intended server, I get an error message. The real issue seems to be dumb surfing; you have to know know to avoid using links and instead ONLY type in URLs for sites that could be fraud targets, then it's really hard to let that man get into the middle.

Glenn -----OTR/L, MOT, Tx
     
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Oct 22, 2009, 02:21 PM
 
Originally Posted by Big Mac View Post
I'm confused. I don't care about the machine's hostname. What I don't understand is why the browser can't look at the URL and match it to the full certificate URL and put up an error if they don't match.
It will. Like I said, it matches the cert's CN to what is being requested in the browser.

paypal.com is different from paypal.foositebar123.com, but apparently browsers don't realize that.
They don't if you have an entry in /etc/hosts or your DNS server has been hijacked, your browser will trust the domain -> IP mapping your OS comes up with. There is no way for it to verify that the IP address for the site you are accessing is the correct one, it can only verify that the domain requested matches the cert's CN. There are a number of ways to route domain requests to different IPs. The only way to determine the rightful owner of the domain is via a trusted source/CA.

The exception is the anti-phishing database that the browser vendors are maintaining and supporting now, but this is just a listing of common domains and IPs. I have no idea how long it would take for this listing to be updated, but I suspect that this will only address the more common reported phishing attempts.

Placing all the responsibility on CAs isn't going to help. They'll pump out a cert for anyone with the cash. This appears to be a fundamental problem with SSL and how browsers handle it.
I've never requested a cert from any company that didn't do pretty rigorous identity checks. Some companies are granted TrustAuthority status (or whatever this is called), so maybe they neglect the identity checks to some extent, but I've yet to come across a private CA that doesn't make you send in copies of your ID.
     
Big Mac  (op)
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Oct 23, 2009, 03:04 AM
 
That sounds right, but this is an excerpt from a Slashdot summary on the topic:

But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com\0.badguy.com, using the null character \0 in the URL. The CA will issue the certificate for a domain like PayPal.com\0.badguy.com because the hacker legitimately owns the root domain badguy.com. Then, due to a flaw found in the way SSL is implemented in many browsers, Firefox and others theoretically can be fooled into reading his certificate as if it were one that came from the authentic PayPal site. Basically when these vulnerable browsers check the domain name contained in the attacker's certificate, they stop reading any characters that follow the "\0 in the name.
That sounds like a browser and/or SSL flaw to me.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Oct 23, 2009, 03:25 AM
 
Finally got around to reading the reports. It does indeed look like an SSL implementation bug to me, a bug that can be leveraged for malicious intent. I would imagine that the OpenSSL library itself just verifies whatever domain and cert is handed to it, it's up to the software using it to parse the domain correctly.
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
Oct 23, 2009, 08:28 PM
 
That null character parse stop thing is just dumb. Of course most strings are terminated by a null character, and that's the typical way a function/process determines the end of the string. With this particular application though, I would think that extra checking for something beyond that character would be called for. I just don't have a clue how you'd determine the REAL end of the domain name string if you couldn't trust a null character to be the string delimiter.

Glenn -----OTR/L, MOT, Tx
     
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Oct 24, 2009, 03:00 AM
 
Originally Posted by ghporter View Post
That null character parse stop thing is just dumb. Of course most strings are terminated by a null character, and that's the typical way a function/process determines the end of the string. With this particular application though, I would think that extra checking for something beyond that character would be called for. I just don't have a clue how you'd determine the REAL end of the domain name string if you couldn't trust a null character to be the string delimiter.
Why would most strings be terminated by a null character? I'm not following you....
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
Oct 24, 2009, 10:43 AM
 
Originally Posted by besson3c View Post
Why would most strings be terminated by a null character? I'm not following you....
That's how most compilers code the termination of a string. You have to mark it somehow, or parsing code is either a bear to manage or just plain won't work. You'd either have to know in advance how many characters to parse (impossible in most situations) or have some other way to indicate "the string stops here."

Parsing most arguments (i.e. command line) on the other hand, is relatively simple because you usually look for white space (specific characters including TAB and SPACE) or some number of arguments separated by white space and nothing else. This "nothing else past the white space" is indicated by an empty argument buffer and/or using up the number of arguments indicated by the function call (this is going way back to basic C). But when you're reading text from an external source, you have to have some sort of convention to say "this ends the string" or it's chaos.

I suppose the fix for FF and other browsers would be to investigate what comes after that null to see if it's actually a termination character or not, but that's still a very large can of worms.

Glenn -----OTR/L, MOT, Tx
     
besson3c
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Oct 24, 2009, 11:09 AM
 
I see what you mean by strings being terminated with a null character after doing a little more reading (String Handling: <string.h>). However, you need to compile your apps in C. Passing a string to a C application as an argument doesn't require a null character, does it?

I don't mean this in the form of a leading question, I'm not a C programmer.
     
Cold Warrior
Moderator
Join Date: Jan 2001
Location: Polwaristan
Status: Offline
Reply With Quote
Oct 24, 2009, 11:27 AM
 
Hasn't this been fixed for Firefox and OS X Safari? Windows Safari and IE remain vulnerable I think.

IE, Chrome, Safari duped by bogus PayPal SSL cert • The Register
     
Big Mac  (op)
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Oct 25, 2009, 12:36 AM
 
Thank you for posting that article, Warrior. I was looking for that class of information but couldn't find it.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
Oct 25, 2009, 10:43 AM
 
Originally Posted by besson3c View Post
I see what you mean by strings being terminated with a null character after doing a little more reading (String Handling: <string.h>). However, you need to compile your apps in C. Passing a string to a C application as an argument doesn't require a null character, does it?

I don't mean this in the form of a leading question, I'm not a C programmer.
By convention, C compilers produce machine code that USES the null character to identify ends of strings. It's not in the source code, it's the machine code that the compiler produces. Sorry I wasn't clearer about this. For what it's worth, MOST languages use this convention of terminating strings with a null character.

Glenn -----OTR/L, MOT, Tx
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Nov 10, 2009, 08:15 AM
 
For the record, this appears to be fixed in 10.6.2.

About Security Update 2009-006 / Mac OS X v10.6.2

Certificate Assistant

CVE-ID: CVE-2009-2825

Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8, Mac OS X v10.6 and v10.6.1, Mac OS X Server v10.6 and v10.6.1

Impact: A user may be misled into accepting a certificate for a different domain

Description: An implementation issue exists in the handling of SSL certificates which have NUL characters in the Common Name field. A user could be misled into accepting an attacker-crafted certificate that visually appears to match the domain visited by the user. This issue is mitigated as Mac OS X does not consider such a certificate to be valid for any domain. This update addresses the issue through improved handling of SSL certificates.
     
ghporter
Administrator
Join Date: Apr 2001
Location: San Antonio TX USA
Status: Offline
Reply With Quote
Nov 10, 2009, 10:14 AM
 
Originally Posted by TETENAL View Post
This issue is mitigated as Mac OS X does not consider such a certificate to be valid for any domain. This update addresses the issue through improved handling of SSL certificates.
That's an approach that hadn't occurred to me-just automatically distrust any certificate so constructed. Elegant, simple, robust. This is why I'm not a programmer...

Glenn -----OTR/L, MOT, Tx
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 03:24 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,