Forgot your password?
typodupeerror
Security The Internet

Null Character Hack Allows SSL Spoofing 280

Posted by timothy
from the cannot-anticipate-all-evil dept.
eldavojohn writes "Two researchers, Dan Kaminsky and Moxie Marlinspike, came up with exact same way to fake being a popular website with authentication from a certificate authority. Wired has the details: 'When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. 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.'"
This discussion has been archived. No new comments can be posted.

Null Character Hack Allows SSL Spoofing

Comments Filter:
  • \0wned (Score:5, Funny)

    by Hatta (162192) * on Thursday July 30, 2009 @02:44PM (#28885851) Journal

    \0\0ps.

    • Re:\0wned (Score:5, Funny)

      by Lord Fury (977501) on Thursday July 30, 2009 @02:47PM (#28885893)

      I don't get it, you didn't post anything.

    • by commodore64_love (1445365) on Thursday July 30, 2009 @03:49PM (#28886861) Journal

      I don't get it.

      Isn't this just the same company?

      • by commodore64_love (1445365) on Thursday July 30, 2009 @03:57PM (#28886987) Journal

        P.S.

        Obligatory explanation: In the early 2000s, paypal.com was arbitrarily closing customers' account and keeping the money for themselves. (You can read more detail at paypalsucks.com) After a couple of years of this, the Bush adminstration's FTC investigated, found paypal guilty, and required paypal.com to refund all the money they had taken. Some people received full refunds while others received flat payouts. I was one of those who received a $50 check.

        So long story short - Paypal.com and Badguy.com are synonymous for many people.

        Another action Bush's FTC took was against record companies. They found the companies had created an illegal cartel to pricefix retail sales of CDs (gee what a surprise), and the companies agreed to settle the case by issuing refunds. I received an $18 check, ditto my brother, ditto my mom, and ditto my two nieces. It might take-awhile but eventually the law catches-up to illegal corporate activities.

        • by QuoteMstr (55051)

          Obligatory explanation: In the early 2000s, paypal.com was arbitrarily closing customers' account and keeping the money for themselves.

          In the early 2000s!? This happened to our organization last week! If you can, avoid Paypal like the plague.

          • by EkriirkE (1075937)
            Never link to a bank (check) account, use a CC where you have some power to withhold transactions
  • by characterZer0 (138196) on Thursday July 30, 2009 @02:48PM (#28885915)

    If not, the CA should not have issued the cert in the first place. Which CA was it?

  • by Tyler Eaves (344284) on Thursday July 30, 2009 @02:49PM (#28885941)

    *sigh* Why is anyone still using null-terminated strings? It's almost a shame that Pascal didn't become dominant...many of these bugs would simply not occur.

    • by tylersoze (789256)
      Yeah and you'd have the Twitter-like limitation of all strings being no more 255 characters long. :) Of course, I'm sure they would've eventually implemented a UTF-8 style thing where you'd examine the initial bits to determine the byte size of the initial string length indicator.
    • by QuoteMstr (55051)

      If Pascal strings had become standard, we'd be dealing with 256-bytes length limits all over the place as Pascal only use eight bits to store the string length. I imagine there'd be attacks that involved making the length counter overflow. We'd still have bugs, but different bugs.

      • by Gramie2 (411713)

        Or they would have done what Delphi (Pascal-based) did, in fact, do: strings are reference-counted and copy-on-write and can contain any characters. They can also be treated as c-type strings when necessary (called a PChar, meaning a Pointer to an array of char), because assigning to a string automatically adds in a null byte at the end. But you can still get around the string handling and screw things up if you try hard enough.

      • by wfstanle (1188751)

        Actually, the limit for standard pascal strings is 255 characters. Byte 0 of the string is the length of the string and 1 to ??? is the actual string. The limit could be overcome by storing the length separately from the data. However, pascal style strings are not inherently more secure than C style strings. You could invent a hack that plays around with length bit ( or field ).

    • Re: (Score:3, Funny)

      by Desler (1608317)
      I agree. 255 characters ought to be enough for anyone!
    • by Anonymous Cowar (1608865) on Thursday July 30, 2009 @03:10PM (#28886245)
      Two strings walk into a bar.

      The first string says to the bartender, "Give me a beer." The bartender turns to the second string and says, "and what about for you?" To which the second string replies, "I would also like a beer#@a9101gb230b81;kajf3#$B89*#()*13!$%#@$"" and goes on and on spewing gibberish.

      The bartender, shocked, asks the first string, "What is your buddy's problem?"

      The first string answers, "Oh, you'll have to excuse him, he isn't null terminated."
      • by commodore64_love (1445365) on Thursday July 30, 2009 @04:05PM (#28887137) Journal

        >>>"I would also like a beer#@a9101gb230b81;kajf3#$B89*#()*13!$%#@$""

        When I first read this I thought something was wrong with my modem. This is how online surfing used to appear prior to the advent of error-correction. Random noise could suddenly appear in the middle of your test. ..... Well I think I'm done for the day. Goodbye all!

        +++

        ATH

        bio#OP*qe! B89*#()*13!B89*#()*13!B89*#()*13! (click)

        CARRIER LOST

    • Agreed, it is a shame, the null terminated came in C very late in game when byte counting wasn't too expensive any more. I really don't get the replies of only 256 byte (octet?) max length? Pascal (PL/I, Algol, etc) strings can have up to unlimited length depending on language, computer, etc implementation. Any modern(?), intelligent language should be able to handle a continuous string of bytes (mostly octets but even NLS and other "strings") without any terminator or special API, it's so lame! And it is d

    • Perhaps one should use a ';' [xkcd.com] to end strings instead.

      Seriously, I would say the problem is not C strings, but the CA *not* using C strings instead. If they properly recognized the null character as a string terminator, they wouldn't issue a certificate for paypal.com to badguy.com.

    • by BikeHelmet (1437881) on Thursday July 30, 2009 @04:53PM (#28888023) Journal

      Java strings!

      32bit signed int, max length 2GB.

      That ought to be enough for anybody. ;) If you need longer, there's special buffer classes that can go longer.

      The string also chooses between ASCII and Unicode when initialized, (you can manually set char encoding, as well) so properly cleaned/trimmed ASCII strings don't waste any memory. (Except for the 3 bytes extra that go into a length int, instead of a null char - but those 3 bytes also give you an amazing speedup when you need to know the length of the string.)

      I believe C# implements Strings in a similar way.

  • by Anonymous Coward on Thursday July 30, 2009 @02:54PM (#28886023)

    Go do something else for a while. If it were not for you we all would be safer !!

  • So now... (Score:5, Funny)

    by mhkohne (3854) on Thursday July 30, 2009 @02:55PM (#28886033) Homepage

    All we have to do is get the CAs to pay attention to the certs they issue, correct?

    Uh-oh. We're screwed.

    • Re:So now... (Score:5, Insightful)

      by Anonymous Coward on Thursday July 30, 2009 @02:59PM (#28886087)

      No, all we have to do is make CA's liable for the certs the issue.

      • by Imagix (695350)
        Isn't that why they charge huge amounts for the certs?
        • Re: (Score:3, Interesting)

          by julesh (229690)

          Isn't that why they charge huge amounts for the certs?

          No, I think that's called rampant profiteering. And because competition has driven the price down too low for them (oh no, they can only get away with charging ~50 euros for an automatically-generated chunk of data) they've introduced extended validation certs, where they actually do what they were supposed to be doing in the first place and charge yet more money for it...

  • by girlintraining (1395911) on Thursday July 30, 2009 @03:05PM (#28886183)

    If you ask me, networks of trust such as PGP are far more difficult to compromise than a central authority. Anything centralized is going to have only a handful of people, who are easy to find, and being private citizens, easily compromised. On the other hand, an integrated cryptographic interface where anyone can vouch for the authenticity of a site, ie; a reputation-based evaluation schema, would be (relatively speaking) more secure.

    I have a reputation amongst my friends and family of being "tech savvy". They trust my advice on technology. If that advice could be included in a database an integrated directly into the browser, then others they know that are also "tech savvy" (and trust) could inform their browsing actions much more than a single profit-orientated organization. I could, for example, add "l0pht industries" to my list of trustees, or "Bruce Schneider"... Or even "Rob Malda", and those people would become part of the trust network that my friends would then rely on. This is where the technology should go -- but because it conflicts with monied interests and in a capitalist society it is only the dollar value of a thing that makes our institutions protect it, it probably never will.

    Trust is really the central issue, not cryptography. Cryptography enables us to extend our trust relationships into the digital world.

    • Re: (Score:3, Informative)

      by Hatta (162192) *

      If you ask me, networks of trust such as PGP are far more difficult to compromise than a central authority. Anything centralized is going to have only a handful of people, who are easy to find, and being private citizens, easily compromised. On the other hand, an integrated cryptographic interface where anyone can vouch for the authenticity of a site, ie; a reputation-based evaluation schema, would be (relatively speaking) more secure.

      Really? It seems to me that with a centralized system, you have one enti

      • Re: (Score:3, Informative)

        by QuoteMstr (55051)

        CAs should be non-profit, or at least heavily penalized for issuing false certificates, if this is going to work.

        The problem is the same with Moody's, actually: the central issue is that the people doing the auditing are being paid by the people they're auditing. Simply having browser users pay CAs (or investors pay rating agencies) would put the economic incentives in the right place, but that idea doesn't sit well with a lot of people.

        So instead, we're left with imperfect and leaky regulation. CAs really

      • If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.

        Yes, and compromising any one entity results in a 1/m damage, where m is the member count. The benefit here is that the number of compromises a person can make in a trust network before discovery (the risk) is exponential, not linear -- that is to say, two people are more than twice as likely to discover the subversion from a single source.

      • Re: (Score:3, Funny)

        by Simetrical (1047518)

        Really? It seems to me that with a centralized system, you have one entity controlling trust. If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.

        Well, one thing I certainly can't trust is Slashdot users' ability to do arithmetic.

    • by Gramie2 (411713) on Thursday July 30, 2009 @03:37PM (#28886669)

      I'd rather add "Bruce Schneier" to my list of trustees, but your friend "Bruce Schneider" may be okay too.

      I'm really not trying to be a smartass. I just want people to get his name right; he deserves it.

    • I could, for example, add "l0pht industries" to my list of trustees, or "Bruce Schneider"... Or even "Rob Malda", and those people would become part of the trust network that my friends would then rely on.

      Bruce Schneider, Chiropractor and Cranio-Sacral therapist [drbruceschneider.com]? He does seem pretty trustworthy, I guess.

    • Re: (Score:3, Insightful)

      by Lord Ender (156273)

      The modern CA hierarchy IS a web of trust. You have the control over which CAs and even which individual certificates you trust. If you go with the default trust relationships provided by your browser or OS vendor, and you aren't satisfied, you have no one to blame but yourself.

      • Re: (Score:3, Insightful)

        by dkf (304284)

        The modern CA hierarchy IS a web of trust.

        No, it's properly a forest (i.e., multi-rooted tree). All the trust flows one way, from the CA roots. That works better because smaller numbers of people need to know what they're doing. Normal people, even normal website admins, don't need to know the details. By contrast, a web of trust will only work between people who understand the security implications of getting it wrong and who are therefore appropriately cautious. So small groups of techies are ideal, the general public... less so.

    • Web of trust is easy to spoof, provided a certain level of autonomy in the system. All a hacker would have to do is spoof Millions (billions, trillions) of trust relationships making it look like something is highly trusted by lots of people. Suddenly that badbuy.com website looks highly trusted to someone who has never seen it before.

      And what happens when geeks gets a hold of the technology and slashdots the web of trust for Microsoft.com as -1 EvilCorp?

      Let us assume for a second that both the cases above

  • More significantly, an attacker can also register a wildcard domain, such as *\0.badguy.com, which would then give him a certificate that would allow him to masquerade as any site on the internet and intercept communication.

    That doesn't sound that bad, does it?

  • This isn't really a browser issue.

    The browser is going "Show me that this cert is valid for paypal.com" and the CA is going "Here it is, for paypay.com" , at least as far as the browser is concerned.
    This is no more a flaw then if the CA just started letting anyone buy certs for paypal.com.

    Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.
    • Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.

      Sort of, but with regards to your personal security it's really just as secure as the least secure CA that is in the trusted list of the browser of your choice. Not that it makes this any better.

      I think browsers should start removing CAs who aren't doing human verification..

  • Someone would just get a certificate that managed to put the ".badguy.com" part starting at byte 255 of some string.

    Null is not a legal character in a domain name, even if you're using UTF strings. It shouldn't be allowed in a certificate.

  • Great summary (Score:5, Insightful)

    by Bromskloss (750445) <auxiliary,address,for,privacy&gmail,com> on Thursday July 30, 2009 @03:30PM (#28886559)

    The summary really explained what it's all about, rather than sound like a newspaper who want's you to read more. This is great! Too few summaries are like this. Editors, you should make sure every story get such a good presentation on Slashdot.

  • Defense-in-depth (Score:2, Informative)

    by davidwr (791652)

    Yes, the CAs should have clear standards on what they can and cannot issue a certificate for.

    However, browser makers need to assume some CAs will issue non-compliant certificates.

    They should also assume some compliant certificates will be confusing to end users, whether it is because of a look-alike character, such as 1/l/!, 0/O, or many such UNICODE pairings. This applies not just to certificates but also second-level domains where an authoritative server run by badguy.com might return an address for a do

  • by VeriSign Allen (1349129) on Thursday July 30, 2009 @04:49PM (#28887939) Homepage
    Tim Callan, vice president of product marketing at VeriSign, responds (in more detail) to these Black Hat presentations in his new SSL blogpost: https://blogs.verisign.com/ssl-blog/2009/07/busy_day_at_black_hat.php [verisign.com] He fills some of the holes that Marlinspike and Kaminsky dug.
  • by ei4anb (625481) on Thursday July 30, 2009 @06:17PM (#28889327)
    of the day I found a similar exploit in IE6. During a pentest I noticed that a company had a password reset site with a url like "passwordedit.info.example.com" so I regestered "passwordedit.info" and sent e-mails to some employees saying "your password will soon expire, please go to passwordedit.info.example.com and change it". However the 'e' in "example" was a Unicode character thet looked/displayed like ASCII 'e' but was not.
    The trick was that IE stopped parsing the url at the bogus 'e' and went to "passwordedit.info" (my site) while displaying "passwordedit.info.example.com" in the url bar.
    My site recorded the new passwords while forwarding the change request to the real site
    IE6 was fixed and no press release was made (we are discreet)
    domains and URLs have been changed to protect the guilty
  • Hmmm... (Score:3, Funny)

    by Kingrames (858416) on Thursday July 30, 2009 @10:48PM (#28891833)
    Would this mean that there's a similar site out there called Slashnaught.org?

    Or would that be Slashdot's good twin?
  • Moxie at Black Hat (Score:4, Informative)

    by TheCabal (215908) on Friday July 31, 2009 @01:07AM (#28892581) Journal

    Moxie's presentation was very enlightening. Out of all the presentations I saw over the last two days, his was easily the most interesting.

    First, he went over his last presentation- that due to CA sloppiness, it is possible for an attacker to issue valid SSL certificates as an intermediary CA. No hack involved.
    Second, the null character exploit. This was the bulk of his presentation, and he went into detail why this works, and why Firefox pre-3.5 plus a bunch of other SSL stacks are vulnerable. Dont want to get a cert for every site you want to spoof? Get a wildcard \0 cert.
    Third, it is possible to defeat OCSP with the number 3.
    Fourth, he demonstrated how, due to these bugs in SSL and OCSP, it is possible to deploy your own "software updates" whenever Firefox or other program attempts to auto-update.

    I hope he puts his presentation up sometime soon.

Nothing is impossible for the man who doesn't have to do it himself. -- A.H. Weiler

Working...