IE, Chrome, Safari duped by bogus PayPal SSL cert If you use the Internet Explorer, Google Chrome or Apple Safari browsers to conduct PayPal transactions, now would be a good time to switch over to the decidedly more secure Firefox alternative. That's because a hacker on Monday published a counterfeit secure sockets layer certificate that exploits a gaping hole in a Microsoft …
Are Microsoft really bothered? Well it's not like they have a reputation for providing secure software to defend, and their, and I paraphrase... this software is not guaranteed fit for purpose disclaimer in the EULA mitigates any legal action one may wish to take against them.
They have been aware of this for over two months, there is no fix, there have been no warnings issued by Microsoft that I am aware of. You decide if they care.
More info:
http://www.linuxtoday.com/security/2009100102035NWNT
http://www.thoughtcrime.org/software/sslsniff/
Unfortunately I have to share this with you, why is it Microsofts fault?
Did they script the fraudulent certificate?
Perhaps you, and anyone who thinks like you, might actually like to focus on the real cause of the problem, which to your utter dismay is not Microsoft. Why don't you spend some of your vitriolic hatred of Microsoft on the real perpetrators of the problem.
Focusing the attention elsewhere is poor journalism, and also shows to some extent poor moral standards. Spend some effort removing the real problem, perhaps an attempt at getting the fraudulent site down might have been a better use of your time.
OK, I remember the story about some ssl providers failing to parse the input string in cert requests, and issuing null-prefix certs.
1. I thought that the "trusted root" provideres would fix this within 24 hours. 2.Then they would search for null-prefix certs that had already been issued, and revoke them all. 3.Then MS and other OSes would publish some kind of blacklist patch.
But it's been a while, and it sounds like none of the three have happened (or at least 1+2+MS).
Question for anyone with the proper knowledge:
Does this hack only apply to certs that have been issued by "trusted root" authorities, or can anyone with openssl create a null-prefix cert that would fool these browsers on windows?
Sir, you are clearly not a software engineer, but possibly a troll.
Software must be able to cater for garbage input and reject it. This is a basic tenet of software engineering best practice.
The fault here is two-fold. First, the granter of the certificate hasn't tested their software properly, and are issuing faulty certificates based on invalid data. Second, Microsoft's Crypto API suffers from exactly the same problem, not sanitising its input. So it's a big FAIL on your part to try and point the blame somewhere else, although where exactly is not clear.
<smug mode>Not a problem on my Mac or Linux boxes</smug mode>
The article mentioned a demonstration of the vulnerability in CryptoAPI which does not currently check for null-prefixed strings. There was an example given of how to create a certificate, but no actual site which is exploiting this - there was no site for the author to take down.
The real problem is the perpetuators (not perpetrators). This would appear to be any certificate issuing authorities who do not handle these strings correctly, and companies providing cryptographic APIs which also do not handle these strings correctly. The latter group includes Microsoft, who appear to have perpetuated the vulnerability for two months compared to, for example, the Firefox developers fixing it in several days. In this respect, they are fair game.
Why don't you spend some of your vitriolic hatred of anyone speaking against Microsoft on actually reading - and perhaps understanding - the article?
Obviously not. I you had you wouldn't post such garbage.
For your information: An operating system provides a large set of libraries that perform common functions and are accessed trhough Application Program Interfaces, or API for short. If a bug or malfunction exists in such a library, it is the responsibility of the provider to fix it.
I this case, it is the CryptoAPI, rsp the underlying code that has a flaw. This library is provided by Microsoft, that's why it is their task to fix it. Simple as that.
So the only one who is vitriolic is you.
The certificate must be signed by a "trusted" CA to pass validation, so no you can't just make your own.
I put 'trusted' in quotes because I've looked the the default list of trusted providers and I don't trust 99.9% of them, and I'm not sure about the other 0.1%
But yes, this sounds like just the thing that CRL was built for, and they're not using it... shows that the CAs are not interested in security, just profits. It should be trivial for them to fix, even retrospectively.
But then the other point is that you have to be heading to the fake server to be fooled, which means your DNS is already compromised so you could argue that you're screwed anyway.
For people that don't follow that, this isn't your typical phishing technique - you can't just get someone to follow a malicious link; the browser has to _think_ it's going to paypal, but the traffic must be intercepted/diverted somewhere.
"following the \ and 0 characters"...
No. Those are not two characters '\' and '0', that is the single character NUL which has the byte value of zero. This denotes the end of a textual string in many programming languages including C and C++. Since this can't be easily displayed and often confuses software, it has to be escaped so that programmers can type it, thus the '\0' notation. Also used, and identical, is \x00, for example.
"We're working to see if there are any technical workarounds on the PayPal side which can be put into place,"
Oh yeah, how? The whole point of the fraudulent page is that it is not anything to do with PayPal.
We'll find a technical workaround for a transaction that never actually hits our site???
It is Microsoft's fault for twiddling their thumbs for nine weeks while a critical security vulnerability exists in their library. Other vendors supplied a patch to a critical security issue in a timely fashion so why haven't Microsoft? Haven't MS been crowing about how much more security focused they are these days?
This isn't some minor typographic error, it is an extremely serious issue that seriously undermines the trust model that every secure website depends on. In other companies this would spark a firedrill and command their maximum attention until it was fixed.
To answer your questions you should re-read the article and understand before posting.
Microsoft wrote the CryptoAPI which processes the certificate. It erroneously ignores any characters after a /0 character in a certificate. It should not do this.
This allows people to create a certificate which can be exploited in the way described, and windows users running the noted browsers will not be alerted that the certificate was not actually issued for the wesbite they have in the address bar.
This is microsoft's fault. They should fix it.
"this software is not guaranteed fit for purpose disclaimer in the EULA mitigates any legal action one may wish to take against them."
has that ever actually been tested in a court where a precedent may be set? After all, folks are still arguing whether shrinkwrap software is licenced or sold, and if the lawyers can't even agree on that, what chance is there in terms of consumer rights, unfair contracts legislation, etc?
Well I guess it's business as usual at Vulture Central, with Dan Goodin once again writing (like he did 4 days ago on this same issue) as if Firefox is the saviour of the world, and mention of the only other major browser that is NOT vulnerable to this flaw (Opera) is nowhere to be found.
But we see plenty of negative trash on The Reg about Opera's campaign to highlight Microsoft's questionably-maintained browser marketshare. (With little explanation of the little detail that Opera is the ONLY major independent browser maker that A) has a direct financial interest in Microsoft's antitrust activities since it relies on browser revenues to survive, and B) doesn't itself own an OS and PC/phone business to bundle its product with.)
I don't think anyone whose primary job is to shift virtual column-inches is prone to 'vitriolic hatred'. (Although, saying that, I suspect Goodin has been branded guilty of vitriolic hatred by just about anyone who doesn't like stories about Windows vulnerabilities, Linux botnets, or Mac users getting infected by viruses. In fact, I know he has, because you can Google about it. The blogosphere positively seethes with 'Online journalist called my computer a poof!' style commentary in response to such articles. You could almost say it amounted to 'vitriolic hatred', at times!)
Meanwhile, businessweek, cnet, zdnet, and probably even Fox news will love it - because they'll quote this entire article, almost verbatim (and let's face it, that was the original aim). So, what's the author been smoking? Dollar bills, perhaps. The only poor journalism, is the kind of journalism no one reads.
Truth is, however, three different browsers are susceptible to a vulnerability in a shared Windows library - for which the fix appears to amount to little more than a call to Regex.Replace, in the correct location.
Opera and Firefox certainly seem to think so, since they have both demonstrated that it is possible.
So, is it Microsoft's fault ("did they script the fraudulent certificate")? Clearly no.
But is the world full of people scripting fraudulent certificates, however? Clearly yes.
Are millions of out of date or invalid certificates being used - even by legitimate websites? Clearly yes.
Is this One Hell of a Mess? Clearly yes.
Would you like your browser vendor to actually do something about it, or just sit on their hands and say 'Not me gov: the Internets is broken'?
I'll leave you to answer that last one.
"If you use the Internet Explorer, Google Chrome or Apple Safari browsers [on Windows]..."
The vast majority of Safari users are on OS X, and so apparently unaffected by this exploit - but of course you should never let the truth get in the way of a good headline.
"Unfortunately I have to share this with you, why is it Microsofts fault?"
Because the CryptoAPI appears to have a security hole.
<quote>
The certificate exploits a security hole in a Microsoft application programming interface known as the CryptoAPI, which is used by the IE, Google Chrome and Apple Safari for Windows browsers to parse a website's SSL certificates....
</quote>
Can we PLEASE have a RTFA icon ?
...some developer decided to use a C string operation (which is terminated by the appearance of the first 0x00 in the string) on an ASN.1 string data type. ASN.1 data structures are TLV (type, length, value). SInce the length of the string is specified in the encoding, the appearance of a null within the string shouldn't stop the processing of that string before its end is reached.
If this was someone hacking into bank systems, or NASA or the US Military then, then various agencies would be doing summersaults to find them and prosecute them. I can understand it if someone finds a security breach, they should tell the relevant people, but to publish online to all and sundry is just criminal. They should be found, locked up for a long time. At the same time, MS, Apple and all should be under obligation to warn users that there is a problem.
surely this exploit goes over to the Comodo-bashers and, in addition, will never affect me as I don't click on links and don't have any bookmarks.
If I go to PayPal or any other SSL site, it's because I typed the URL into my browser.
But this goes towards a different question - is an SSL certificate proof of anything but a certificate existing?
I can't think of a decent icon for this one so I'll use the beer icon :-)
"Unfortunately I have to share this with you, why is it Microsofts fault?
Did they script the fraudulent certificate?
Perhaps you, and anyone who thinks like you, might actually like to focus on the real cause of the problem, which to your utter dismay is not Microsoft. Why don't you spend some of your vitriolic hatred of Microsoft on the real perpetrators of the problem."
So not checking for the null prefix in the crypto API that they wrote isn't Microsoft's fault?
What fucking planet are you living on sir?
That's like saying MS aren't responsible for the numerous buffer overflow attacks their OS's have been susceptible to throughout history purely because they didn't launch the attack.
Get a grip man it's the coder's responsibility to check the input for garbage/malicious info. They wrote the shit.
How can I put it any easier for you to grasp that if the purpose of the code is to check the validity of a certificate then any certificate it says is valid should be so. Get it?
Of course the hundreds of patches to internal SSL libraries and the like on linux (and likely OS X), which fix very similar "holes", seem to go by with little fanfare and vitriol.
They all make the same mistakes. Judging by the regularity of security patches I've seen on my linux server, I'd say some make more mistakes than Microsoft ;)
Firefox has fixed the problem, without MS doing anything, ergo this isn't an OS problem, or a cryptoAPI problem, it's a browser problem.
So no, I'm not a software expert, and to be blunt I don't need to be, however I can read, and I can think.
Perhaps you guys could remove your heads from your asses, and actually construct a criticism that is actually relevant to the issue, which is BROWSER related, quite obviously, or if it isn't, perhaps it is the OS, so why don't you all just f+++ off to a Mac, or a Linux system, and actually have to employ your brains for once, if they aren't yet frazzled by the commute to the front door.
Quite frankly, the article is nothing more than a sales pitch for Firefox. I get enough spam in my inbox already, thank you very much.
"That's because a hacker on Monday published a counterfeit secure sockets layer certificate that exploits a gaping hole in a Microsoft library used by all three of those browsers"
Gaping hole in a MS library.... Mozilla have patched their browser, which presumably means it intercepts the call to the library and rejects it if necessary. Therefore I would suggest that it is a Microsoft issue after all. The other vendors could do the same, but it still won't resolve the underlying issue in the MS code.
"Firefox has fixed the problem, without MS doing anything, ergo this isn't an OS problem, or a cryptoAPI problem, it's a browser problem."
No, it's an OS problem with the CryptoAPI. As far as I know, Firefox still uses its own cryptographic libraries rather than the OS-provided ones, so they can fix the bug themselves. (Remember that Firefox is (a) based on Netscape, which predates widespread OS support for crypto, and (b) designed to be portable across different operating systems.) The other browsers, however, do use Microsoft's CryptoAPI and that's where the vulnerability has to be fixed.
@neil 5: "the Internet Explorer, Google Chrome or Apple Safari browsers"
MS wouldn't have written any of those, would they ?
Either way, MS have a problem.
ps Yes, the author of the article is a one-eyed Firefox zealot, but he'll get over it one day.
<Smug> Written by a long-time Opera user. </Smug>
Now let's all have a nice cup of tea.
Yes it is an OS problem. Many software applications rely on CryptoAPI. These applications HAVE NO WAY WHATSOEVER OF FIXING THIS ISSUE. They rely on Microsoft to fix their subsystem and it is Microsoft's responsibility to do so in a timely and measured fashion. If they sit on their backsides (as they have) while other vendors who use alternate APIs manage to fix the issue, then Microsoft is the one being tardy.
And if this article is a sales pitch for Firefox, it is only insofar as it highlights the difference in attitude between Mozilla (and Apple) vs Microsoft when faced with a web-breaking critical vulnerability.
Yep, widen the argument out if you must, however cryptoAPI isn't the interface with the web, IE is.
At others who still persist, to be fair, if the author had written the article to say for eg, only safari was affected, would you all be jumping on Apple's or MS's back.
I'm sorry, in my opinion, and as written by the author, this IS a BROWSER issue, not an OS issue.
CrptoAPI isn't broken. the browsers are broken, and all those who harpen on about the OS being broken are wrong.
Now I agree that IE is crap, but to be fair so are all the other options available. perhaps hardening up the interfaces with the web is the route to be looking at. If you still don't follow that, if I run my computer without connecting to the web, am I at risk from fraudulent sites, NO.
The real truth you can't all face, lazy/malicious web site coders, fraudulent in part populace, and unknowleadgable users.
The OS is fine, the web, it's users, and abusers aren't. Mozilla, whatever system it runs on, has to make calls to the OS. Fix the browsers once and for all, including Apple, Opera and Mozilla.Don't just blame MS for the criminal activities and intents of others.
Look in your own hearts first, or not, just blame MS because society is f'ed up. No, the responsibility lies equally with the web's users. Perhaps adjustments to your attitudes are needed too.
"Yes it is an OS problem. Many software applications rely on CryptoAPI. These applications HAVE NO WAY WHATSOEVER OF FIXING THIS ISSUE."
Sort of. They rely on Microsofts Crypto API, but they don't HAVE to. They could write their own code. You'll notice that Mozilla and Opera don't have this problem because they aren't lazy and don't rely on buggy MS code.
Yup it is the fault of every coder that uses MS API's, MS are blameless. All developers should write their own DLL's, crypto routines, disk handling code, TCP/IP stacks, GUI's, kernel etc, etc. In fact, developers should completely bypass ALL MS code altogether just to be on the safe side. Which raises questions such as... What's the point of an MS OS in the first place? And if there is a point, why does MS allow third party developers to use their DLL's anyway? Ah, so it is Microsoft's fault for allowing developers to use MS code in their applications, but wait a minute isn't it the fault of developers for using MS API's in the first place.
Perhaps developers need a trusted base for which to write applications, or should every application come with it's own OS? Like you allude to, it is the developers fault for trusting such shoddily written, bug ridden and insecure code such as that provided by MS and not writing their own underlying OS to protect their applications from exploitation.
***"So no, I'm not a software expert, and to be blunt I don't need to be, however I can read, and I can think."***
***"CrptoAPI isn't broken. the browsers are broken, and all those who harpen on about the OS being broken are wrong."***
And how does someone who is "not a software expert" decide that "CryptoAPI isn't broken"?
Did you gut a chicken and fondle its entrails, or something? Divine inspiration? Astrology? Or just a lucky guess?
I like this.
Being a smug linux and firefox user and of course never using Paypal as it is just a rip off, this means nowt to me. However reading the logic arguments for what is simply another MS not caring for it's customers once the customer has paid up for it, Like Vista, Home server and half a dozen other pieces of software they have made over the years. I find myself spitting tea over my keyboard and laughing out loud to the point my boss is looking.
Can we have a popcorn please icon for those readers of comments that just enjoy the tirade of trolls and the like who want to try and make this anything other than MS being slack.
First of all this clearly is an MS problem with the CryptoAPI and affects many applications that use it, BUT I think Apple and Google must take the blame as well.
They take every opportunity to knock Microsoft over security issues and boast about how their browsers are better written and more secure, then they end up relying on a buggy API for one of the most critical security functions in a browser! Why did they not test this and identify the problem themselves before it was revealed in a Black Hat conference? Perhaps THEIR testing procedures are not up to scratch.
On the other hand why didn't they just avoid using untrusted MS APIs for such a critical function? Lazy programming perhaps? I think they should also take responsibility for putting their users at risk by using APIs from a company renowned insecure products (as Google and Apple like to remind us ad nauseum).
I also wonder if there are any other critical security features in their browsers that they have delegated responsibility to Microsoft's APIs? We should be told (actually, being a smug Linux/Firefox user I couldn't give a sh%t).
The point is should they be relying on MS APIs for anything beyond the user interface? And if they do then do they have the right be so smug about security problems in MS products?
exactly the very thing I'm talking about, jumped ignorant pricks, perhaps if YOU read the article instead of getting yourselves all wound up, crptoApi isn't broken, it has performed exactly as it should have, what is broken is the morality of the coder of the malicious website. And the browsers ability to detect fraudulent certificates, and no, not just an MS issue, but if you read carefully, and I know that the headline is in larger letters, so that SHOULD make it easier for you to read, although obviously nothing can be done about your comprehension.
As an aside, anonymouse coward 15.34. Perhaps you could enlighten me, MS code for Apple and for Google, please don't choke on your cup of tea, whilst you single handedly keep the economy running, your wages will have to fund our benefits.
Again, for all of you complaining about MS coding, why don't you all use an OS which is so obviously superior,and free, or would that involve you actually having to think. Of course, the plus side of that being, the instant removal of all crime on the internet, wouldn't it.
Neal 5 says: ". . . crptoApi isn't broken, it has performed exactly as it should have,"
People who complain about coding are making this much too complicated. I agree with Neal that code is not the real culprit here and we should simply get rid of all crime on the internet so we won't have to worry about vulnerabilities.
You are either a troll or thick as a plank when you write
"CrptoAPI isn't broken. the browsers are broken, and all those who harpen on about the OS being broken are wrong."
It processes characters in a string after the null character which it should not do so it is very broken. You said yourself that you weren't a programmer so when it has been pointed out that you don't know what you are talking about it would be wise to shut up.
As it is you that has reverted to the childish name calling in support of your misguided view on this issue I suggest it is you that are getting "wound up".
Those browsers that rely on the Microsoft crypto API are vulnerable to this attack.
Those browser that do not rely on the Microsoft crypto API are not vulnerable to this attack.
Logic dictates that Microsoft's crypto API is at fault. Perhaps when MS get around to fixing this and releasing a patch it will sink in.... Microsoft's crypto API is bugged, flawed, broken.
"'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!
'Is metabolic processes are now 'istory! 'E's off the twig!
'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!!"
Some people just can't see a dead parrot when presented with one.
btw, I use Linux (OpenBSD and Ubuntu) for the serious stuff. XP is my toy operating system, my gaming OS for which it is almost fit for purpose.
It's not a case of being lazy. It's a case that writing crypto APIs is hideously difficult and very few apps would have the time or resources to do it, especially when operating systems such as Linux & Windows usually provide their own implementation or a shared library. As an example of how difficult they are to implement, consider that OpenSSL (uquitous in the Unix world), NSS (in Mozilla), Crypto API and Opera's impl are all roughly ten years old and bugs still occasionally crop up.
App often inherit one crypto API or another because they're calling libs such as libcurl, wininet etc. and indirectly pick up whatever that lib is using. It simply is not feasible or reasonable to expect an app to hop from one API to another at the drop of a hat.
It's also worth remembering that every SSL / TLS implementation has suffered from bugs in the past. Bugs are an accepted and entirely predictable occurrence. What matters most with security software is the frequency of the bugs, the criticality of the bugs from a vulnerability perspective and the how long it takes to resolve those bugs. If Mozilla, Opera or whomever can release patches in a timely fashion with 1/100th the resources of Microsoft, then there is no excuse for Microsoft not doing the same. Especially considering the extreme severity of the issue.
Windows 7 Pro, on which I will play games and work, but never enter confidential info - $320 CAD. I've entered credit card numbers on a Windows computer only once in 5 yrs.
This MacBook Pro, which I do trust but think is way too expensive - $1999. Sadly, neither Linux nor Windows would let me code iPhone apps and I needed a new laptop.
Chuckling out loud at Neal5's "informed" opinion - priceless.
Dude, get a clue, from somewhere, they're cheap. MS publishes an OS level API meant to provide crypto/authentication services to apps, as part of the platform. It is broken. Sure, browsers could code their own stuff, but usually the first rule of security is to leverage the work of folks who are presumably better suited to write security code. You would expect at least a security submodule to be well-written, wouldn't you? Not with trivial bugs? Failing that, you would expect it to be patched promptly, wouldn't you? This above your head? Should I type more slowly?
Usually, I sit on the fence on the MS hating folks. There's plenty I don't like with MS, but anti-MS feeling is often quasi-hysterical (Nix & Mac fanbois). In this case though, MS is being just plain sloppy. The only good thing is that it seems the vulnerability requires both the MS bug _and_ a sloppily issued cert which can't be created out of thin air by the hackers.
Would have liked the article to be clearer on that point - can somebody write their own spoofed cert here, or do they _have_ to gull some cert authority, which would be a bottleneck? Couldn't tell from the linked article.
I am in search of more information. I have read the Moxie Marlinspike article. I did see some of the other exploits demonstrated by SSL-Sniff first hand, but am yet to see where this exploit exists in the timeline of Windows + CAPI enabled applications, browsers, email, custom, etc.
Has this vulerability been documented in Microsoft's crypto API? Has there been a test matrix of the various versions of windows, current offerings, and those still in the wild, paired with the posibilities of browser+OS pairings which demonstrate the the "C-String" flaw in Capi?
Please someone educate me on documented cases of this exploit in windows CAPI + CAPI reliant applications.
Thank you in advance.
Gordon~
This bug in the CryptoAPI also means:
a) It's not just browsers affected. Anything than connects over SSL/TLS, e.g. chat clients, mail clients, etc. Harder to exploit, though a poisoned DNS cache would do it.
b) Valid certs for international domains (e.g. ümlaut.com ) in the future will probably then be incorrectly identified as invalid - as I imagine the string containing the domain name will be UTF-8 encoded.
As someone earlier mentioned, it's an ASN.1 string. It would be trivial to verify that the length of the string indeed matches what was specified. Slack programming at the best of times, but in a crypto lib, unforgivable.
I code a little and with my admittedly fairly minor knowledge I think some comments are a little unfair, what sounds like a quite simple thing to fix can often have bizare and unexpected consequence and it can take some time to check that the fix is implemented correctly and will not affect anything else or any programs that rely on the current data handling
also surely most people on here are capable of understanding that if it was really that quick and simple MS would fix it as they are no more keen that the users are to see it stay unfixed as it does not exactly do any favoiurs for their reputation .
it also doesn't exactly help when users insist on buy their viagra from those nice friendly people who emailed them out of the blue...
regarding>> I am in search of more information.
This issue is confirmed.
I am not able to generate a request with a null character prefix CN using Microsoft's CAPI (via CertEnroll API),
Unfortunately I am able to reproduce this quite easily by creating a certificate with other widely used crypto API's.
When I view the cert which I generated in a recent supported version of windows I can confirm the issue is still present.
"Crypto Shell Extentions" which uses MS CAPI API's allows me to see the certificate's subject as only the portion before the null.
In my opinion CAPI's handing of directory strings using CString V.S. AS1 DERPrintableString is broken.
While CAPI is smart enought to not let us generate a signing request with broken RDN components, certificate subject validation + display is indeed broken.
This is not good.
~Gordo
Dude, are you just trolling or are you really not understanding the issue?
Have you actually worked with SSL?
FQDN checking is done at the CryptoAPI's level, *not* the browser level. SSL connections are usually initiated with some open_connection("blah.site.com", 443); call, and the Crypto Provider does the rest. It is that API the one wrongly validating the null-prefixed certs. This is basic validation, the kind you learn in basic programming courses!!
Of course, the CAs should also be at fault, as they were stupid enough to sign a cert like this; however, these certs shouldn't be passing through something as sensitive as the SSL FQDN check!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
