Null-Prefix SSL Certificate For PayPal Released
An anonymous reader writes "Nine weeks after Moxie Marlinspike presented at Defcon 17, null-prefix certificates that exploit the SSL certificate vulnerability are beginning to appear. Yesterday, someone posted a null-prefix certificate for www.paypal.com on the full-disclosure mailing list. In conjunction with sslsniff, this certificate can be used to intercept communication to PayPal from all clients using the Windows Crypto API, for which a patch is still not available. This includes IE, Chrome, and Safari on Windows. What's worse, because of the OCSP attack that Moxie also presented at Defcon, this certificate cannot be revoked." Update: 10/06 23:19 GMT by KD: Now it seems that PayPal has suspended Marlinspike's account.
...it is thought that more people are going to be using Macs' and Linux in the future.
Well, we can't say they didn't have enough time to at least try doing something about it...
Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
Thank God I use Firefox!
(More importantly, I have IE 8, Firefox, Chrome, and Opera all installed - that way I can use whichever one is safest each week)
The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.
Taxation is legalized theft, no more, no less.
Moxie Marlinspike - that's a goblin name if I ever saw one.
a bug or a feature?
With CNs like www.paypal.com\0ssl.secureconnection.cc
Shouldn't the CA who issued the certificate bear *some* of the blame here?
It just seems logical....
This includes IE, Chrome, and Safari on Windows. What's worse, because of the OCSP attack [CC] that Moxie also presented at Defcon, this certificate cannot be revoked."
It irks me how much Microsoft and Google products depend on Windows components.
I'm an avid nLiter for my own personal computers. Google uses BITS for updates, and apparently MS Crypto too. This is all stuff that I strip out entirely, because just about all non-Microsoft non-Google software works fine without it.
If there's one thing I've learned about software development, it's that if you depend on system APIs, you're more likely to get attacked. After all, every Windows computer has such libraries, so why wouldn't hackers target it? Short of heavily modified/nLited XP computers, you'd have a 100% attack base if you can find an exploit in the component, or a way to exploit that component's behaviour.
As a developer, if you have an option about what you use to handle something... like crypto or updates... code it yourself and code it properly, or go for a third party library. (perhaps open source) XML Parsing? Code it yourself or use a third party lib, but DO NOT use MS XML parsing. You're asking for trouble if you do!
All Your Base - Are Intercepted BY US!
Set Up Us The Sassle!
And since the null-termination cert *doesn't chain to an EV provider* it's not much of an exploit, really. No green bar, not safe.
-- Cerebus
We could already predicted new elements whats the big it's not really useful as a tool, maybe a teaching tool. Techniques like the bode plot or smith chart are useful.
tach315
Sounds like PayPal should be freezing everyone's account until this is fixed.
Give me Classic Slashdot or give me death!
Because that is totally going to fix the problem.
"I'd just like to emphasise that taking a million years isn't a metaphor here..." -Rich Bradshaw
Because that is totally going to fix the problem.
It sure as hell will. They should have done that 9 weeks ago!
<Complete your profile by adding a signature!>
If you don't shoot the bearers of bad news, people will keep bringing it to you.
FTA :
"It won't work for exploiting the bug for software written with the WIN32 api, they don't accept (for good
reason) *!"
Como?
https://www.accountkiller.com/removal-requested
For more information about null-prefix attacks, the video is here.
If you cause someone grief, don't expect them to be nice to you in return. That's just life. You can be as "correct" as you like, they still have the right to tell you to fuck off.
If you are an asshole to me, you'll find yourself banned from my house, my websites, etc, etc. Doesn't matter if you feel it was justified, or if you feel that you were "helping the world" with what you did. You cause me grief, you become persona non grata to me. I will not associate with you professionally or personally.
Same shit here. He's causing Paypal problems, and in fact will probably cost them business. I'm not surprised they aren't interested in doing business with him any more. He is well within his rights to publish about this vulnerability, they are well within their rights to refuse him service.
..that I closed my PayPal account. :-)
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
I would so love to see some of the paypal directors in prison
Why are you in prison?
No, paypal is just fine. The problem is that Microsoft has not updated its encryption API for Internet Explorer to stop a publicly known exploit for SSL.
Kirk: How is the messenger, Bones?
McCoy: He's dead, Jim.
Kirk: Well, I suppose our mission here is accomplished.
McCoy: Yes, I suppose you're right.
Everything in the Universe sucks: It's the law!
If you don't shoot the bearers of bad news, people will keep bringing it to you.
Awesome. This is a quote I'm going to remember for a long time!
If you cause someone grief, don't expect them to be nice to you in return
Was he causing them grief, really? The vulnerability existed whether he talked about it or not. Given that it's tied to some deep long-term issues with null-terminated strings, it's entirely credible to theorize that there are black hats that knew about it already, and his disclosure gave software developers a chance to do something about it. That keeps PayPal from having to deal with fraud and theft problems associated with the vulnerability. Hardly assholery.
And even if they're within their rights to behave this way, it's more troubling than the existence of vulnerabilities. Everybody makes mistakes, but retaliation every time anyone points one out doesn't build trust, it makes you look insecure and calls into question your ability to improve. How much do *you* trust a company whose response to criticism is to lean on those who level it?
And all this leaves aside the ethical issues inherent to any kind of retaliatory cessation of service. Losing your PayPal account isn't such a big deal, but there are other services for which this kind of behavior would grant heavily inequitable power to providers, particularly in markets where there's a small number of competitors or where the idea of blacklisting takes hold. It's one of the reasons why libertarianism will never, ever work anywhere near like its proponents like to imagine it will.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
If you cause someone grief, don't expect them to be nice to you in return.
Look at it this way: If a doctor jabs you with a mortally-needed anti-venom needle, do you have the right to tell him "Fuck off!"?
I suppose... "He caused me grief!" Yeah, okay. It's a bit of a simplistic metric, really, for determining what is a good response. Appropriate for a young child or a retard. Maybe not for a large corporation. Hopefully not for you.
It does matter what the person's intentions were.
what usually happens:
* you request a cert common-name=serverbox.mydomain.com from a Certificate Authority (CA)
* CA determines you are authorized to make this request on behalf of mydomain.com
* serverbox.mydomain.com serves down the signed cert, your browser makes sure website == common-name == serverbox.mydomain.com
what these clever guys discovered:
* you can request a cert common-name=paypal.com\0.mydomain.com
* CA determines you are authorized to make this request on behalf of mydomain.com
* man-in-the-middle sits in between you and paypal.com, serves down this cert, victim's browser makes sure website == common-name == paypal.com (whoops!)
* victim sees paypal.com in their browser with that reassuring padlock
So paypal violates their own privacy policy by not using working encryption
There is absolutely nothing wrong with Paypal's encryption. There is nothing wrong with the CA that paypal uses for their SSL cert. There is technically nothing wrong with the CA that allowed a null-prefixed SSL cert to be created, although they were stupid to do it. Microsoft needs to fix their ^$@&#.
But I'm using a 64-bit OS, you insensitive clod!
That's just the first step. If the exploit isn't gone in a few days they'll try harder measures, like prank calling his house, and ringing his doorbell and running away before he answers.
--Edward Dassmesser
Since the hole affects Windows Crypto API's, this should now be easily possible. A rootkit virus, which hijacks all the traffic from its local network, intercepts all windows update requests and spreads itself as an update. Implications: if single machine on your network is infected, all windows machines get infected within 24hrs? This is providing you can get a code signing cert with null-prefix, but I don't see why this would be much different than SSL cert (just find an automated CA).
I dunno, they seem fully misunderstood in this case.
http://lkml.org/lkml/2005/8/20/95
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes.
You mean like ssh does? Yes, I've been arguing for this for years. But there's no money to be made there, so it won't happen.
Did anyone else read the stuff this kid has on his site? Moxie is a Sailor/Hacker/Anarchist/Squatter/Hitchhiker enigma. Holy shit this kid has sailed the CA coast in the worst conditions alone. I am duly impressed and green with envy and depressed that I am not living a life like his.
I had a sig, but
Paypal or Ebay do not care if you do any good to them.
At some point about a year ago when Ebay was changing their website I noticed a vulnerability that would show
any user's e-mail address. Spent nearly 2 hours trying to explain it to their "tech support" idiots. Finally, after
being transferred from one person to another on their support chat - they escalated it and the loophole was fixed
in less than 12 hours...
Now, I have several accounts with Ebay. One has nearly 100,000 feedbacks. Another one had 10,000 and had
a small problem with one product thus more than usual customer complaints. It was suspended. Eventually,
I looged in into my dad's account from the same IP to help him buy something, and they suspended his too.
I got rather angry and upset. Called them and asked to reinstate all the accounts. The response I got was
something similar to "sorry sir, you violated our policy". It's been about half a year since then. I moved away
from Ebay and selling much better with other means. The fact that their entire user database with email
addresses could have been stolen by blackhat hackers would I have not disclosed them the issue did not
seem to interfere with their decision process on the "policies".
As such, just as Marlinspike may be somewhat upset that he only did a good thing and got suspended, I am
largely pissed off. And if I ever find anymore problems with Ebay or Paypal, I will not disclose it to their
tech support since I do not feel they value such reports. In fact, I feel just the opposite.
Fenyman went to visit a General in his office one day.
It seems the good professor liked to tinker with locks, and while there tinkered and found, unbeknownst to the General, the combination to the General's safe. The next time he happened to be there, something was needed from the safe, and the General was astonished when Fenyman said "...let me get it for you" and proceeded to unlock the safe and retrieve the item. He explained to the General how the lock on that type of safe was easily broken, and not to be trusted. Time passed. Feynman visited the General's office again and while waiting, noticed a memo posted in the Office. "It is prohibited to let Dr. Feynman near safes..."
I vaguely remember a wave of anti-Paypal protest and an anti-Paypal meme using the meant-to-be-pejorative take-off name "Praypal". But now when I search for "Praypal" on Google I only get legit "find someone to pray with" (and similar) sites. Did I miss some kind of meme revolution, there?
The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings.
Who cares about their dirty (or not) implementation details? The \0 in certificates trick is a bug that was present pretty much all over the place, not just in windows. If you are an ubuntu user and you read the description of security updates when they are pushed to you, you will have seen mention of this bug in at least a dozen different updates already. Hell, today there was one for wget! I agree with the grand parent poster: taking so long to fix this on windows is inexcusable.
For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database.
In fact, ASP.NET has some very sensible options for addressing this issue. Take for example the (infamous) DataGrid. In DataGrid you define columns. The column to "bind" to a datasource (database/collection/etc) is called BoundColumn. It has a property called HtmlEncode. It has a default value of true . Which means that contrary to your claim, if you use this "data binding" control, ASP.NET *will* encode data bound text by *default*
The Literal control is just that. It defaults to displaying literal text. However, it *also* has a property so set whether to pass-through, encode or translate html.
It is true that some controls (like e.g. RadioButtonList) do not support encoding the *text* property. Those controls render in a way where you should never set anything but plain text anyway. If you were binding HTML text to radiobutton lists, checkbox lists or select controls I suggest you take a good long look at the requirement instead.
The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode.
Sorry, but that is just stupid. You should simply have set the encode property of the control you were binding to instead. If you were binding to a control which did not expose such a property, maybe you should have used a control which did?
If you've only ever written a single ASP.NET application, perhaps you refrain from making bold faced criticism on a subject where you are obviously not qualified.
Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
No, it will not be fixed, because it is a feature, not a flaw. This is a case of an unexperienced developer misunderstanding the framework and failing to use the correct components. But there's a fix for that, too.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Suspending his account is the most childish thing in the history of stupid that the PayPal.com people are currently writing.
So if you're a hacker who relies on PayPal, the not-so-subtle message is to make sure your projects steer clear of your online payment processor.
We call this the "don't sh*t where you eat" principal.
I understand they wanted to stay with native OS functionality as long as possible, especially on Windows which they were critiqued for not shipping "native" stuff but we now see the result.
I think Webkit/Safari/Chrome must move to OpenSSL as quickly as possible.
This locate output should explain why I am really surprised by them not using openssl instead, like Opera does: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/openssl
Apple knows OpenSSL and uses it all over the OS. I don't believe OS X can even boot/browse without it.
that Paypal axed the hackers account, I'm tired of these idiots trying to make off with other peoples hard earned money. Why doesn't he get a job like the rest of us?
http://msdn.microsoft.com/en-us/library/system.string.aspx has a nice little warning under the heading "Strings and Embedded Nulls" about what the API's coders should have done to prevent these mixed string types from causing security holes...
I created and deleted the directory without any problems in Vista SP0, SP2 and Windows 7.. those who modded you up - on which system did this trick work? You did test it, right?
BTW to disable creating the useless short file names in order to slightly improve performance:
Set NtfsDisable8dot3NameCreation to "1" in \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem and reboot to finally get rid of the cruft from the early 90's.
Capitalization is the difference between "Helping your uncle jack off a horse" and "Helping your uncle Jack off a horse"
That is the reality. But read what paypal is claiming, which is not that at all.
Paypal disabled the security researchers account for distributing software which they claim has no other use than hacking paypals encryption.
You and I know what is actually going on, but personally I refuse to use that as an excuse to let paypal out right lie about the reasons of their actions, and their press releases.
P.S. Repeating what paypal announced is trolling?
After two (-1) troll moderations it is clear the M$ astroturf gang dosnt like the truth and clarity and is much happier with market speak, so,
to add to the clarity, this was entirely M$ making because they were too lazy to check the CN properly when parsing the CERT in the Windoze (TM) CAPI. OpenSSL and thus Linux and MAC do not suffer from this bug!