5 ms·

Null-prefix certificate for paypal

63 points by bensummers 17y ago

markpercival 17y ago
For anyone that wants to know more about what a null-prefix cert is: http://daniel.haxx.se/blog/2009/08/12/curl-fooled-by-null-prefix/ http://daniel.haxx.se/blog/2009/08/12/curl-fooled-by-null-pr...
hapless 17y ago
To be clear: this is a two-part hack. Part 1: The null-prefix cert bug is still in the Windows SSL stack. Any browser that uses the Windows SSL libs will take this cert, issued to CN=www.paypal.com\0someoneelse.es, and use it for CN=www.paypal.com. Part 2: The certificate has already been revoked by its issuer, but a man-in-the-middle attack will prevent the client from discovering that. Moxie Marlinspike's sslsniff + arp spoofing can be run anywhere within the layer 2 broadcast domain in order to deceive the client when it tries to verify the cert.
- ComputerGuru 17y ago
  If I'm not mistaken, the same trick you mention in "Part 2" can be used to deceive the client for any false certificate, not just a null-prefix certificate.
  - sp332 17y ago
    But you need to have a cert signed by an authority the browser trusts, which is why you need the null-prefix attack.
wizard_2 17y ago
I'm going to have to write an article about "no public wifi" and setup a proper vpn for everyone I know. I just finished reading about hijacking google analytics's js and setting the cache expiration for a year in the future. This means someone can hijack every page that uses tracking in your browser until you clear your cache. The thing that kills me is that there's just no need for it, lets move vpn's into common practice and lets update our ssl libraries (microsoft!) That caching trick also means, if you get your paypal "jacked" once, it can persist when you're back on a secure connection.
- holdenk 17y ago
  VPNs however add considerable latency as well as cost and complexity. Its not like there is no down side to using VPNs. If your using SSH and a web browser which isn't susceptible to the current SSL exploits, I don't see why I would want to use a VPN over Wi-Fi.
  - thwarted 17y ago
    DNS lookups are not currently signed nor authenticated, neither of which go through ssh or the browser's SSL stack, which is a major attack vector for MITM.
    - tptacek 17y ago
      SSL was designed not to care that DNS is insecure. Heading off one likely response to this comment: it is silly to look at a bug in probably the best-tested piece of security code on the planet (Microsoft's CryptoAPI/schannel code) and arrive at the conclusion that DNSSEC, a protocol nobody has ever deployed successful at scale, isn't hiding many worse bugs. The same obviously goes for SSH, which uses key continuity so as not to care that DNS is insecure.
      - thwarted 17y ago
        While all that's true, it's not the design of SSL that is at issue, but rather bugs in the SSL stack, such as this null-prefix certificates issue. While I don't know the state of Microsoft's stack for this bug, ubuntu just released a patch for wget yesterday for it (USN-842-1, CVE-2009-3490). No one is really talking about DNSSEC, but if you were using a wifi connection (the original use case in this thread of using a VPN over wifi) and thought you were secure because you were using SSL, MITM via DNS is still a possible attack vector, as hapless points out elsewhere in these comments. Obviously a VPN over wifi wouldn't secure you for accessing paypal.com via SSL (which is a public resource), but other, private resources secured with only SSL but resolved via public DNS are at risk (wifi or not).
agl 17y ago
Also, a more correct ASN.1 parser (at the CA, or in the client) could have saved them. The CN field is a PrintableString type which has a limited character set specified. NUL is not an allowed character in a PrintableString.
- tptacek 17y ago
  I've tested a lot of ASN.1 implementations and I've never seen a BER or DER parser that even managed to check lengths or parse pathological OID arcs properly, let alone handling restricted character sets in strings. You might as well say they'd have been better served with a unicorn.
alexkon 17y ago
If you're using Firefox, set security.OCSP.require to true. There is also UI for it under Preferences -> Advanced -> Encryption -> Validation -> When an OCSP connection fails, treat the certificate as invalid. I don't know whether it protects against all OCSP attacks but it's obviously better than the default option.

63 points by bensummers 17y ago

For anyone that wants to know more about what a null-prefix cert is: http://daniel.haxx.se/blog/2009/08/12/curl-fooled-by-null-prefix/ http://daniel.haxx.se/blog/2009/08/12/curl-fooled-by-null-pr...

hapless 17y ago

To be clear: this is a two-part hack. Part 1: The null-prefix cert bug is still in the Windows SSL stack. Any browser that uses the Windows SSL libs will take this cert, issued to CN=www.paypal.com\0someoneelse.es, and use it for CN=www.paypal.com. Part 2: The certificate has already been revoked by its issuer, but a man-in-the-middle attack will prevent the client from discovering that. Moxie Marlinspike's sslsniff + arp spoofing can be run anywhere within the layer 2 broadcast domain in order to deceive the client when it tries to verify the cert.

ComputerGuru 17y ago
If I'm not mistaken, the same trick you mention in "Part 2" can be used to deceive the client for any false certificate, not just a null-prefix certificate.
- sp332 17y ago
  But you need to have a cert signed by an authority the browser trusts, which is why you need the null-prefix attack.

wizard_2 17y ago

I'm going to have to write an article about "no public wifi" and setup a proper vpn for everyone I know. I just finished reading about hijacking google analytics's js and setting the cache expiration for a year in the future. This means someone can hijack every page that uses tracking in your browser until you clear your cache. The thing that kills me is that there's just no need for it, lets move vpn's into common practice and lets update our ssl libraries (microsoft!) That caching trick also means, if you get your paypal "jacked" once, it can persist when you're back on a secure connection.

holdenk 17y ago
VPNs however add considerable latency as well as cost and complexity. Its not like there is no down side to using VPNs. If your using SSH and a web browser which isn't susceptible to the current SSL exploits, I don't see why I would want to use a VPN over Wi-Fi.
- thwarted 17y ago
  DNS lookups are not currently signed nor authenticated, neither of which go through ssh or the browser's SSL stack, which is a major attack vector for MITM.
  - tptacek 17y ago
    SSL was designed not to care that DNS is insecure. Heading off one likely response to this comment: it is silly to look at a bug in probably the best-tested piece of security code on the planet (Microsoft's CryptoAPI/schannel code) and arrive at the conclusion that DNSSEC, a protocol nobody has ever deployed successful at scale, isn't hiding many worse bugs. The same obviously goes for SSH, which uses key continuity so as not to care that DNS is insecure.
    - thwarted 17y ago
      While all that's true, it's not the design of SSL that is at issue, but rather bugs in the SSL stack, such as this null-prefix certificates issue. While I don't know the state of Microsoft's stack for this bug, ubuntu just released a patch for wget yesterday for it (USN-842-1, CVE-2009-3490). No one is really talking about DNSSEC, but if you were using a wifi connection (the original use case in this thread of using a VPN over wifi) and thought you were secure because you were using SSL, MITM via DNS is still a possible attack vector, as hapless points out elsewhere in these comments. Obviously a VPN over wifi wouldn't secure you for accessing paypal.com via SSL (which is a public resource), but other, private resources secured with only SSL but resolved via public DNS are at risk (wifi or not).

agl 17y ago

Also, a more correct ASN.1 parser (at the CA, or in the client) could have saved them. The CN field is a PrintableString type which has a limited character set specified. NUL is not an allowed character in a PrintableString.

tptacek 17y ago
I've tested a lot of ASN.1 implementations and I've never seen a BER or DER parser that even managed to check lengths or parse pathological OID arcs properly, let alone handling restricted character sets in strings. You might as well say they'd have been better served with a unicorn.

alexkon 17y ago

If you're using Firefox, set security.OCSP.require to true. There is also UI for it under Preferences -> Advanced -> Encryption -> Validation -> When an OCSP connection fails, treat the certificate as invalid. I don't know whether it protects against all OCSP attacks but it's obviously better than the default option.