Slashdot Mirror


Null Character Hack Allows SSL Spoofing

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.'"

7 of 280 comments (clear)

  1. Is the null character valid in a domain name? by characterZer0 · · Score: 4, Interesting

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

    --
    Go green: turn off your refrigerator.
  2. Only as secure as the gate-keeper. by MaerD · · Score: 2, Interesting

    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.

    --
    I put on my robe and wizard hat..
    1. Re:Only as secure as the gate-keeper. by jpmorgan · · Score: 2, Interesting
      The browser never sends a request to the CA. The browser has a copy of the CA's public key in a local store, so it can verify the cert itself. And the cert is perfectly valid... it's just for the wrong website! How SSL certs are supposed to work:
      1. The browser checks that the certificate has been signed by a trusted CA, by comparing it against its own local repository of CA public keys.
      2. The browser verifies that the certificate has not expired or been revoked.
      3. The browser verifies that the certificate matches the website it's trying to access.

      In this attack, the certificate is valid, and has not expired or been revoked, because the certificate was issued by a valid CA and is compliant with all the rules.So Firefox checks 1 and 2 they pass, as they should. But what's supposed to happen is firefox checks the 3rd part, and should detect the mismatch and generate an error. But firefox implements check #3 wrong, this is the problem. Firefox is improperly treating the domain name as null terminated, when the strings are supposed to be length delimited. This is a browser bug, plain and simple.

  3. Re:When C Strings Attack! by commodore64_love · · Score: 3, Interesting

    >>>"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

    --
    "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
  4. Re:When C Strings Attack! by BikeHelmet · · Score: 4, Interesting

    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.

  5. gentlemen that reminds me... by ei4anb · · Score: 3, Interesting

    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

  6. Re:So now... by julesh · · Score: 2, Interesting

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