Slashdot Mirror


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.

27 of 351 comments (clear)

  1. So let me get this right... by Darkness404 · · Score: 5, Insightful

    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.
    1. Re:So let me get this right... by QuoteMstr · · Score: 5, Insightful

      All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. 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. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

      To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.

    2. Re:So let me get this right... by nametaken · · Score: 4, Insightful

      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. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks.

      I would be pretty upset if everything I pulled from DB was automagically HTML encoded. I protect against XSS where it needs to be done. There are places where HTML encoding your data would not work. I do, however, always use parameterized inserts to protect against sql injection on top of an appropriate string cleaning function. Few things aggravate me like shitty ad-hoc inserts and the absence of string cleaning tied to a client-driven interface.

    3. Re:So let me get this right... by techeddy · · Score: 2, Insightful

      Actually they have addressed the HTML encoding in ASP.net 4.0: http://haacked.com/archive/2009/09/25/html-encoding-code-nuggets.aspx Although I agree it has taken quite a while, but sometimes one does need to output with and without the encoding, so I find it nice to have an explicit and easily identifiable way to do both.

    4. Re:So let me get this right... by bertok · · Score: 2, Insightful

      All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. 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. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

      To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.

      There's no backwards compatibility, ASP.NET was a completely new framework, written from the ground up. It should have done escaping correctly, right from the start. Ideally, it should be a flag that you can toggle on and off on the level of individual text fields, controls, or a whole page, and the default should be safe.

      Storing HTML in databases is one thing, and there are controls for emitting such data, such as XML, Literal or Placeholder controls, but that's a special case where a page is assembled from HTML fragments, which is actually relatively rare(*). The common case is a simple text field bound to a database column such as "user name", or "product name". There is just no good reason to allow arbitrary HTML in all database columns that are potentially user writeable. This is how you end up with shit databases that have encoded characters like "&" in them, which breaks sorting, comparisons, and non-HTML applications such as reporting engines.

      Oblig XKCD: http://xkcd.com/327/

      (*) at least it SHOULD be rare, because it totally breaks the separation between UI, Code and Data, by mixing all three together into one huge mess.

    5. Re:So let me get this right... by bertok · · Score: 3, Insightful

      I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.

      Well, I just tested it with 3.5, and it's still just as broken as when I first tried it with 2.0.

      First of all, "div" and "span" aren't controls at all, but are simply markup elements, and neither support data binding (which is what I was talking about), and neither do any kind of encoding at all, so I think you might be missing my point entirely. Also, "Label" is not that rare - it's the default control inserted by the GUI designer in Visual Studio if you bind a text field in a FormView, and as you noticed, it fails to encode.

      Second, while some controls do perform encoding, this only works sometimes, usually if the target control is a "Literal", or effectively the same (e.g.: If a Literal control is generated by a data bound control as a child control). As far as I know, the Literal control is the only control that has a "Mode" property that can be used to toggle HTML encoding modes, so most other text fields are not encoded.

      For example, if you bind the "Text" property of a HyperLinkField of a DataGrid, then no HTML encoding is done, and no encoding options are available. The only option is to do a manual bind to a code-behind method that performs the encoding for you.

      What particularly shits me is how random the encoding is. Sometimes it works (literals), sometimes it doesn't (hyperlinks), but then sometimes it randomly works again, such as the Alt text of Image fields. It's not documented either!

      Is this the quality and attention to security you'd expect from the world's biggest software company? Random, unpredictable, undocumented, insecure behavior in their flagship web framework? Really?

    6. Re:So let me get this right... by mpe · · Score: 2, Insightful

      Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.
      This is what I mean when I say Microsoft's attitude to security is still half-assed.


      Or rather that's their attitude to standards. With the security issues being one of the consequences.

  2. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 5, Insightful

    This has to be the worst advice I've ever heard.

  3. Re:Such dependancies annoy nLite users! by sakdoctor · · Score: 4, Insightful

    NO! Don't roll your own crypto. This is madness!
    *Kicks BikeHelmet into pit*

    OpenSSL is available for windows; use that.

  4. "...PayPal has suspended Marlinspike's account." by magsol · · Score: 5, Insightful

    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
  5. Re:Such dependancies annoy nLite users! by TheRealMindChild · · Score: 2, Insightful

    It irks me how much Microsoft and Google products depend on Windows components.

    So you are saying reinvent the wheel? Don't use the system resources at your disposal? Should we just all go back to DOS way of doing things?

    --

    "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
  6. Re:Paypal uses an EV cert. by dopodot · · Score: 2, Insightful

    Do you really think the average user is going to notice a lack of green bar? Internet Explorer is going to accept this certificate as valid for https://www.paypal.com/ and there will be no hints to the user that it's actually illegitimate. Unless there's some other mechanism in Internet Explorer that will notice it got an EV cert in the past and is no longer getting it, then this cert is entirely usable for a man in the middle.

  7. Re:Such dependancies annoy nLite users! by just+fiddling+around · · Score: 3, Insightful

    Amen brother, bad coders re-making existing functions or API's is what fills up The daily WTF

    --
    You're not old until regret takes the place of your dreams.
  8. Re:Such dependancies annoy nLite users! by True+Vox · · Score: 2, Insightful

    Yeah, I'll just echo Sakdoctor... Being able to make "rolling your own crypto" a good idea is for a VERY rare breed of person... and even they generally don't like to do it.

    --
    "Gratuitous complexity is akin to chaos" - True Vox
  9. Re:Paypal uses an EV cert. by Vellmont · · Score: 2, Insightful


    *doesn't chain to an EV provider* it's not much of an exploit,*doesn't chain to an EV provider* it's not much of an exploit, really. No green bar, not safe. really. No green bar, not safe.

    Have you lost your mind, or are you joking?

    Assuming a rubber room is being prepared for you, I have to wonder why you would think anyone knows to look for green bars.

    I might actually agree with you that this isn't a huge problem, but for very different reasons. MITM attacks are relatively hard to exploit. You're essentially limited to wireless networks, or hostile LANs. Also, this isn't a big deal since if you can already perform a MITM attack there's countless ways to trick the user into thinking the site is secure without even touching SSL.

    --
    AccountKiller
  10. Re:Wow? by The+Archon+V2.0 · · Score: 2, Insightful

    You do know what a marlinspike is right?

    Yeah, it's the place where Captain Haddock lives. (I'm sorry, I know what the actual object is, but my childhood Tintin reading and viewing has forever fused the word "marlinspike" to the word "hall".)

  11. Re:Yay Choices! by Excelsior · · Score: 5, Insightful

    I am not a security expert, but does switching to Firefox really solve the issue? For browsing, sure. But everyone is saying this is part of the core crypto API in Windows. Certs are used in more things than just IE.

    When the app you want to install says it is signed by Microsoft, Mozilla, or Nullsoft, can you still be sure that it really is? Can you be sure the Windows Update software is actually retrieving updates without a man-in-the-middle?

    I really don't know the answers to these questions. But I would be surprised if switching to Firefox is a cure to a bug in the core Win32 apis. Helpful: yes. A solution: probably not.

  12. Re:No, but by QuoteMstr · · Score: 4, Insightful

    AFAIK, the law supports your position. But I really think we need to examine whether that's the kind of society we want. It's perfectly fine for a small business to arbitrarily refuse to have a relationship with a particular person. That person can go elsewhere, and the small business is only hurting itself. But large companies like PayPal are different. They form an integral part of the fabric of modern life. When one of these large companies denies service to an individual, that person's quality of life is reduced without an opportunity for rebuttal, or for a fair judgment by his peers. These companies have become de facto utilities, and just as the electric company cannot turn off your lights because of a personal grudge, PayPal should not be able to arbitrarily cripple your ability to send and receive money.

    When a company gains quite a bit from being large enough to matter in this way; it should give something in return.

  13. Re:What about the CA that issued it? by ekhben · · Score: 5, Insightful

    Ahh, you've discovered why SSL on the web is fundamentally broken -- CAs have no incentive to act responsibly, since their customers are certificate requestors, not relying parties. And certificate requestors like CAs who don't have heavy process and high fees.

    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. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.

  14. ow, retaliate! by Onymous+Coward · · Score: 5, Insightful

    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.

  15. Re:No, but by lilrobbie · · Score: 5, Insightful

    From Paypal's justification of their banning:
    "We do not, however, allow PayPal to be used in the sale or dissemination of tools which have the sole purpose to attack customers and illegally obtain individual customer information," the spokeswoman, Sara Gorman, wrote in an email. "We consider whether there is any legitimate use in helping to strengthen the defenses of one's site when determining violation of our policy."

    The problem with your statement is that he did not cause Paypal problems in the way that you think. He showed a widespread security flaw, using Paypal as an example... and Paypal suddenly decided that the tools he was producing "have the sole purpose to attack customers and illegally obtain individual customer information". This is a complete and utter load of bollix.

    So yes, Paypal may not be happy they have a vulnerability... the same vulnerability that every other SSL cert user has I might add... but he was not breaking their TOS. What they did was infantile and very counter-productive.

    This kind of behaviour means the only people that know the flaws in your system are the hackers who want to exploit them for nefarious means, rather than these researchers, who are doing it partially to "help the world", but also to HELP YOU.

    I wouldn't trust a company who discourages security penetration testing and thorough investigations of their systems in these ways. Because you can bet your pants, the black-hat hackers will do their homework and find these flaws if our researchers don't.

  16. This is a scary scenario by misnohmer · · Score: 2, Insightful

    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).

  17. Re:In other news... by ProfessionalCookie · · Score: 2, Insightful

    2010, the year that Windows got A LOT more expensive than Mac.

  18. Re:Such dependancies annoy nLite users! by shutdown+-p+now · · Score: 2, Insightful

    XML parsing. Those are pretty easy to implement properly in an app

    No, no, God, no. I'm sick to death of crappy applications not handling Unicode element names, not understanding XML namespaces properly (I've seen several that thought that prefix is the namespace, and required you to use specific prefixes), not properly parsing CDATA, not understanding XML whitespace rules or xml:space, not understanding DOCTYPE and entities, and so on.

    XML is not simple. Don't think you can whip up a parser in an evening unless you really know the W3C spec well, including all corner cases (if you don't know any corner cases, then you don't know it well).

    Use a mature, stable, preferably open source third party library, and you'll make your users and future maintainers happy.

  19. Re:Yay Choices! by Anonymous Coward · · Score: 1, Insightful

    Can you be sure the Windows Update software is actually retrieving updates without a man-in-the-middle?

    Certainly for Vista and above, Windows Updates themselves have to be signed by a key descended from the Microsoft Root Authority (if not part of a domain with WSUS enabled). The Common Name is completely decorative on those keys; it is never checked, so this vulnerability is completely irrelevant there.

    There may be a related attack on Authenticode. This has not to my knowledge been published. Comodo also issues Authenticode keys, certainly. It should not be possible to obtain one now, however.

    Very mean-spirited of PayPal, I must say. Bad form.

  20. Re:Yay Choices! by maxwell+demon · · Score: 2, Insightful

    The point is, you get only the Firefox security after you've installed Firefox, and only assuming you've installed the real version, not a hacked one. And how do you check if you have a real version when installing your first version of Firefox? You can't check with Firefox because it's not yet installed. Checking with Firefox after the fact is pointless, too, because a hacked Firefox will certainly claim it's legitimate. Actually, even when Microsoft patches the vulnerability and you get it through Windows Update, you can't be completely sure, because after all someone might have intercepted Windows Update with a fake certificate.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  21. Re:Yay Choices! by Anonymous Coward · · Score: 1, Insightful

    So I may as well just switch off the computer and go and do some gardening?