Case Study: GE Money's Invalid Certificate, False Positive?

[GµårÐïåñ]

I wanted to share a personal test case with you and hopefully get some meaningful and constructive discussion going on the topic because I believe that it could present a case for people to consider as to the level of their actual security, even with SSL certificates and all the checks and balances, can we still get bitten?

I have a credit provider whose backed by GE Money and they use the following website: Account Management

I went there today and I got a notice from both Perspective that the certificate is invalid showing signs of being attacked and SSL Blacklist also said it was invalid and additionally Trusteer's Rapport also gave a warning that the certificate is invalid and should be avoided.

Normally I would take that as valid and avoid it until that was fixed, even if a false positive. However, I decided that I want to see what Safari, Opera and Chrome have to say about it. So I check and NONE of them gave any alert to the validity or doubts of validity of the certificate.

So question: Why not? Supposedly they all have a certificate validation routine that accesses the issuing authority to check its validity, so how is that Fx tools are giving this message, almost unanimously but not others? Who do we trust? Above all, how do we know or can verify which is right?

I would appreciate Giorgio's or anyone who has either user experience or even security experience about this to please provide the perspective of their experience and knowledge so that we can all benefit from an actual hands on case study. TIA.

[GµårÐïåñ]

[Tom T.]

Steve Gibson's weekly podcast, Episode 217, 08 Oct 2009, discussed a vuln in the MS CryptoAPI that could be exploited to create false SSL certificates. MS had known about it for more than two months, but did nothing, nor did Apple, Opera, etc.

Firefox took it upon themselves to create a fix for their own browser within a couple of days of the disclosure of the vuln, not waiting for MS or relying on MS. In Gibson's words, at that time, Fx was "the only Windows browser that you could trust for SSL" -- or words to that effect.

A couple of weeks ago, an actual, successfully-forged PayPal SSL cert was posted on the Net. No one knows how many other people created how many other fake SSL certs for sensitive sites. After this pressure and negative publicity, MS issued the patch in October Patch Tuesday's update, IIRC.

The podcast is interesting.
Text transcript
Hi-fidelity mp3
Lower-bandwidth mp3
Pdf

[GµårÐïåñ]

Thank you for summarizing that for me, unfortunately as much as I love my old friend (lost touch with him on personal disagreements arising over nano-probe technology) and want to listen to his stuff, I just don't have the time. Thank you for that.

So if I gather correctly from what you are saying, based on Steve's assertions, this should be taken as a correct alarm? So this is truly a site that is under attack and hijacked? I wanted to discuss it and be sure before I offend their IT with a report that they will laugh at.

[Tom T.]

STEVE: The bad news is that just three days ago,[[5 Oct -- TT.]] this last Monday, a fake PayPal certificate was posted on the Internet which allows SSL connections, Secure Socket Layer connections, to be spoofed, that is, like with various sorts of phishing attacks, using this fraudulent certificate.

ALEX: So you can think you're paying through PayPal, and you're really paying - you're really connecting to somebody else.

STEVE: Well, exactly. And in fact this is - what's disturbing about this is that this is more than two months old. This is a defect that originally affected all Windows browsers. Microsoft still to this day, more than nine weeks after this went public, has not fixed this. The problem still exists in their own CryptoAPI library, which is a shared component of Windows that IE, Apple Safari running on Windows, and Chrome all use. So today IE, Safari on Windows, and Chrome are all vulnerable to this.

What's interesting is that Firefox, both version chains of Firefox, the 3.0 and the 3.5, fixed it within a couple days. And there was also the problem, even in the Mac OS X originally, but Apple fixed it a couple weeks later. So this has long been fixed for Firefox under Windows and Safari under OS X. But even now, more than two months later, has not been fixed for IE, Apple Safari under Windows, and Chrome. And now we have this fake PayPal certificate that is being circulated on the Internet that essentially, if it's used, you can actually establish an SSL connection to what looks like PayPal. We talked about this a couple months ago, to remind our listeners.

The idea is that the way strings are stored in pretty much all modern operating systems is it's just a sequence of bytes that ends with a null byte, that is, a zero byte. They're so-called null terminated strings. Strings historically have been stored in various different formats. Pascal was famous for storing the length of the string as the first byte, which was convenient for all kinds of reasons. The problem was that a byte can only be 0 to 255. So Pascal strings could never be longer than 255 characters. So that was sort of fixed by saying, wait a minute, we'll just allow a string to be any length, but terminate it with a null. Well, of course that has had disastrous security consequences. That whole null terminated string issue, while it's very convenient for programmers to sort of scan until you hit a null, that's largely responsible for all the buffer overrun problems we have today.

ALEX: Now, is part of that giving a hacker an idea of what to look for?

STEVE: Well, it's more that the operating system will just read bytes until it hits zero. And it'll do that blindly. So if you tell it to, like, copy one string to somewhere else, it will copy as much as you give it until it hits a null character. So it creates this, like, all kinds of opportunities for exploitation. What's interesting about this particular null - it's call the "null prefix vulnerability" in certificates - is that you can create a certificate, http://www.paypal.com null, that is, a zero, and then anything else you want, like mymachine.secure.net. And so the certificate is actually for the secure.net domain. And certificate issuers will issue certificates to the secure.net domain. And then if you embed a null between sort of your own machine name, http://www.paypal.com, the browsers, while they're parsing the name on the certificate, they stop at the first null. Which is the way strings are processed in our modern operating systems. So it's not a surprise that they do this. But you absolutely don't want that behavior in this particular instance.

ALEX: Right.

STEVE: So anyway, so essentially this is a bad problem. Microsoft has not responded. And as of three days ago there is this known fraudulent PayPal very spoofable certificate floating around the 'Net. And of course the big question is, okay, we know about the PayPal cert. What other ones have been issued that we don't know about?

ALEX: Right.

STEVE: So essentially the takeaway from this is, at the moment you cannot trust, that is, a Windows user cannot trust any Windows browser other than Firefox. The Firefox guys fixed this. They took responsibility away from the underlying Windows platform and fixed it themselves within days.

ALEX: So, now, so Apple could fix it, for instance, on Safari. They just - they would need to - but right now they're relying too much on the Windows framework?

STEVE: Exactly. They're using - there's a shared library called the CryptoAPI that IE, Safari on Windows, and Chrome all just assume the underlying framework is reliable. They're all using it. And as a consequence, today they're all vulnerable. And so Apple did fix it in OS X immediately, but haven't done so on Safari under Windows, probably presuming that this is, you know, hey, this is not our fault. This is a Windows problem. The problem is that it makes all browsers except Firefox untrustworthy, I mean, completely untrustworthy, for making secure connections until Microsoft finally fixes it. Which maybe they'll do so soon. I hope so.

So Steve is saying that this was patched on F3+ long ago.

I can't tell whether it's a false alarm, but it certainly merits the attention of the site. People post XSS and ClearClick false pos here all the time. We don't laugh at them, we appreciate them letting us know so that we can investigate, reassure them if it's false, and perhaps give some information that the site could use to rectify their poor coding. I don't see why they would laugh or be offended -- they shouldn't be.

FWIW, back in the old days when I used to get my MS Updates from MS Update's secure site, https://update.microsoft.com, using IE, I would always get a browser warning of a site mismatch on the SSL cert. It was just that the cert was issued to microsoft.com and the site was update.microsoft.com, or something trivial like that. But SSL warnings are always disconcerting. I wrote to them about it. The first person said, "Not my job", but he'd hand it off to someone else. Never heard from them again, but a few months later, it was fixed. Not even a thank-you.

It seems that that problem is happening again. Probably when the old cert expired and they renewed it, they made the same mistake. But since I no longer get my updates from MS Update or on IE, but rather manually with FX, it's not my problem any more. (I might start a thread in Security or Web Tech on how and why I use Fx for MS updates, and not from MS Update web site, if I find the time, energy, and motivation, or any indication of interest.)

[Alan Baxter]

I have a credit provider whose backed by GE Money and they use the following website: Account Management

I went there today and I got a notice from both Perspective that the certificate is invalid showing signs of being attacked and SSL Blacklist also said it was invalid and additionally Trusteer's Rapport also gave a warning that the certificate is invalid and should be avoided.

I loaded the url and Firefox is not giving me a warning. Apparently Firefox thinks the cert is good.

[GµårÐïåñ]

@Alan, thank you for checking that. That is very interesting to me because as you can see the second screenshot is of Firefox telling me its untrusted. I wonder why mine is saying its bad while yours says not. What is the difference in our setup do you figure? What should I check? Since we are running the same version, it should not be so different in analysis, right?

[GµårÐïåñ]

Everyone, just wanted to report something that I tried in lieu of Alan's good cert verification. Since the first prompt or alert comes from Rapport, instead of block this time, I said allow and it loaded fine with SSL Blacklist reporting the cert is OK and Firefox not alerting that its invalid and Perspective comes back as valid. However, if I say block when Rapport intercepts then everyone, such as Rapport, Perspective, SSL Blacklist, and Firefox, claim the cert is invalid and under attack. So I wonder why it is that Rapport's decision is affecting all the others. Is there an intermediary authority that is being set to false which affects how others see it too or is it just coincidental? Giorgio?

Information & Results
Perspectives Notary Results:

Code: Select all

Notary Lookup for: www.statementlook.com:443,2
Browser's Key = '1f:9b:75:0e:cc:33:6c:54:04:db:3a:5c:28:9b:63:09'
Results:
Quorum duration: 158.993 days
Notary Observations: 

Notary: convoke.ron.lcs.mit.edu:8080
ssl key: '1f:9b:75:0e:cc:33:6c:54:04:db:3a:5c:28:9b:63:09'
start:	1247155980 - Thu Jul 09 2009
end:  	1255768559 - Sat Oct 17 2009

Notary: cmu.ron.lcs.mit.edu:8080
ssl key: '8b:e9:48:72:32:b8:d3:43:e7:0f:2f:df:16:58:74:c4'
start:	1219883918 - Wed Aug 27 2008
end:  	1236430777 - Sat Mar 07 2009
ssl key: '1f:9b:75:0e:cc:33:6c:54:04:db:3a:5c:28:9b:63:09'
start:	1236430778 - Sat Mar 07 2009
end:  	1255783506 - Sat Oct 17 2009

Notary: mvn.ron.lcs.mit.edu:8080
ssl key: '1f:9b:75:0e:cc:33:6c:54:04:db:3a:5c:28:9b:63:09'
start:	1242071157 - Mon May 11 2009
end:  	1255765668 - Sat Oct 17 2009

Notary: hostway.ron.lcs.mit.edu:8080
ssl key: '1f:9b:75:0e:cc:33:6c:54:04:db:3a:5c:28:9b:63:09'
start:	1241678248 - Wed May 06 2009
end:  	1255765937 - Sat Oct 17 2009

Firefox's Certificate Information:

[Giorgio Maone]

This is apparently a Rapport false positive.
I don't specifically know this product, but the stuff I've just read online on it lead me to believe it acts like a proxy between your browser and the internet.
Therefore, depending on how the "block access" feature is implemented, it may lead to confusion on the requester side, e.g. by serving a local "dummy" resource with the certificate of the blocked response.

[GµårÐïåñ]

I believe you are correct on that. Although it sits and behaves like an extension inside Fx, there is corresponding Extension or Plugin reference for it in the Fx lists, so it must somehow be outside Fx but with a hook inside it. The proxy model makes sense and it would explain why the others believe as it does because its affecting the local cache copy of the certificate with a dummy to "protect" from access I guess.

Now a question of logical decision making and choice. Having dealt with all perspectives on this, would you assume Rapport is wrong and go with the rest or possibly give the benefit of doubt and assumption that maybe they caught something first and the rest haven't caught up? As you can from a user perspective that's a tough choice because you have no idea who to hold to a higher regard? so how would you recommend someone weighing the advice and making a choice? Especially that in my case, up until I posted this thread, Rapport never gave a warning on this site and I go there fairly regularly. I will submit a ticket to their technical team and reference this thread in the hopes they will check it and make the appropriate corrections. Since there is no need to register for posting, maybe they will also post a comment on all this here for future reference.