Black opspki 2

Black Ops of PKI Or: When I Hear The Word Certificate, I Reach For My Gun Dan Kaminsky Director of Penetration Testing IOActive, Inc. Len Sassaman & Meredith L. Patterson K. U. Leuven copyright IOActive, Inc. 2006, all rights reserved.

Introduction
Hi! I’m Dan Kaminsky!
This is my 10 th talk here at Black Hat!
Focus of most of my talks has been on foundational elements of Internet Security
SSH
TCP/IP
DNS
Web Browser Same Origin Policy
DNS
Visual Pattern Recognition In Binary Data
DNS
SSL

The Crisis Of Authentication
Vulnerabilities / “0-day” get all the press, but…
According to Verizon Business, 60% of actual real world data losses are traced not to software vulnerabilities, but to failed authentication technology
No passwords
Bad passwords
Default passwords
Stolen passwords
My passwords
Passwords are used because they scale well, one at a time
Passwords fail because they fail to scale, as a group

The Two Schools Of Thought
“ We can make passwords work…barely”
Machine generated
Rapidly cycled
l33tpaZ$
As Schneier has noted, still trivially vulnerable to keysniffing
“ We can eliminate passwords entirely, if only we can find a way to get the human out of the memory business”
PKI with X.509 was supposed to do this
“ If only we cared enough, we could stop using passwords. Smartcards for everyone!”

Reality Check
Business has “cared enough” about PKI to invest hundreds of millions of dollars in it over the last ten years
Something is not working
I believe that something is X.509, the technology at the core of present-day PKI
We have learned so much about real-world security since the 90’s, when X.509 was developed. If we’re to get past passwords, we have to start putting that knowledge to use – with DNSSEC.

Rethinking The Foundations Of Internet Security
There are those who think we should create a “New Internet”, which would just “not have any of these security problems”
This is hopeful, but naïve
Similar to building cities without roads or highways in the middle of a forest – “But it will have great mass transit” doesn’t make up for that
However: What we are doing now, the way we are doing it, is not working. Lets talk about why.

Warning
The first fifteen minutes of this talk aren’t that l33t, so as a preview…

DEFCON
Yes, that’s a real certificate
No, I’m not going to tell you who issued it
Jeff Moss knows
Alex Sotirov knows
Yes, I could have just as easily gotten a cert for *00.doxpara.com

Intro to X.509 (the really, REALLY simple version)
X.509 is the identity system behind PKI
Used for SSL, IPSec, pretty much everything except SSH
X.509 allows creation of systems where public keys and subject names of individuals are signed by certificate authorities trusted by many people, such that if you have a specific private key , other people may validate your identity via its matching certificate
Private Key: “Your face”
Public Key: “Your passport photo”
Subject Name: “Your name”
Certificate Authority: “The country you live in”
Certificate: “Passport”
Validation: “If you have the face that’s in the photo, and it’s on a card issued by your country, then you have the name of the person on the passport.”
X.509 is just the digital version of this

X.509 In The Real World: SSL
X.509 has only one real success story: SSL
This is the technology used to secure HTTPS, i.e. the web
Early on, SSL = Can Provide Credit Card #
Probably the single best thing that ever happened to consumer crypto
Only about ~1M SSL endpoints
People are arguing about whether cloud applications require SSL!

Walkthrough: Acquiring An X.509 Certificate For A Website [0]
1) Register a name in DNS, providing an email address as the canonical “user” behind the domain name
2) Generate a public and private keypair.
“ Face”, and “Passport Photo”
3) Provide the public key to a Certificate Authority, along with the name of the website we registered in DNS
This is done with what’s called a “PKCS#10 Certificate Signing Request”, or CSR

Walkthrough: Acquiring An X.509 Certificate For A Website [1]
4) The Certificate Authority, or “CA”, asks DNS for the email address of the user who administers that website, and then emails the user making sure it’s OK to bind that website to that public key
“ Heh, is this ‘passport photo’ actually you?
Technically, asks the WHOIS database
5) Click the link provided in the email to the canonical address.
6) Receive a certificate, which can be loaded into your web server to prove it is the real www.whatever.com

I’m Oversimplifying, Aren’t I?
What I just described is called Domain Validation – there are many CA’s that offer much more stringent validation
DUNS lookups
Phone calls
Lawyers who show up at the door and take a blood sample
Just kidding
Doesn’t matter, because of flaw #1…

X.509 Cannot Exclude (without great pain)
There are dozens and dozens of CA’s out there trusted by everyone
Every CA can issue certificates for every single name
“ Zimbabwe can issue American passports”
Even if your CA runs you through the wringer, that doesn’t mean every other one will
Security of the whole is equal to security of the weakest link
Anything more is, unfortunately, security theatre
There are many very good, very responsible, very responsive CA’s out there. X.509 does not allow them to provide a more secure solution than their competitors
Technical term: “Race to the bottom”

DNS Is Very Good At Excluding
DNS has three layers
The root: There is only one root.
Classic quote: “The CA system is only as secure as the money they refuse to take.” The root – as is, anyway – won’t take your money. Root is part of State system.
The Registries: Verisign has exclusive control over .com. Afilias has exclusive control over .org.
One of the TLD’s had a real problem with malware. The registry behind that TLD recognized the problem and cleaned it up.

DNS Is Very Good At Excluding [2]
The Registrars: I have registered www.doxpara.com through Network Solutions. Network Solutions has exclusive control over my domain. If they screw up, I can move that domain to eNom, who will then have exclusive control.
When my domain is controlled by eNom, no other registrar can mess it up
I can manage my risk with DNS, I cannot manage my risk with X.509
There are “elite” registrars that are able to provide a higher level of security
MarkMonitor

X.509 Exclusion Is Painful
Possible to exclude “untrusted CA’s”
Can run a private CA
Very expensive
Very difficult to maintain
What happens when you need to interoperate with other individuals behind other private CA’s?
Federal Bridge CA
The people who made this work deserve a medal
This problem shouldn’t require awarding medals the few times its actually solved

Interop: Not actually optional
Theory: You only need to authenticate to your own organization – how often is your house key used in other homes?
Reality: Cross-organizational authentication is the rule and not the exception
Partnerships with other companies
Interactions with other groups
There are many organizations in each company
Software As A Service / Cloud Services
Passwords interoperate well.

X.509 Cannot Delegate (without great pain)
Each time I need a new certificate for a node in my organization, I must interact with an external CA, to get a certificate for that particular node
Expensive
Operationally inconvenient
Potential information disclosure issues
Integrates very poorly with devices
Almost all of which end up with self-signed certificates
“ Name Constraints” were supposed to fix that
You were supposed to be able to get a certificate that allowed you to sign for *.doxpara.com or whatnot
Very weak support in field, so you can’t buy this from anyone
Can also fix with wildcards, which aren’t a great idea either
Every node can read traffic from every other node?!

DNS Delegates Very Well
The root delegates to Verisign for .com
.com delegates to my servers for doxpara.com
I add and remove servers from doxpara.com all I want, never talking to the root, Verisign, or Network Solutions

X.509 Delegation Is Painful
Serious demand for being able to issue a certificate using your Private CA, that is valid outside your own organization
Can’t do this securely without Name Constraints
Solution: Do this anyway
Forget hacking CA’s. Prove you’re a business of some size, and sign an insurance policy, and you get an intermediate certificate that allows you to sign for any name on the planet
At least two companies offer this, probably more
No way of knowing how many intermediates are out there
It’s not that the companies don’t take security seriously. It’s that the technology doesn’t allow them to offer anything better.

2008: Not A Good Year For X.509 CA’s
Mike Zusman: Bypassed Thawte’s security checks by claiming www.live.com was the “name of an internal server” and thus not subject to validation at all
Also bypassed Startcom’s checks via a web interface hack
Me: Bypassed almost all CA’s validation mechanisms by hijacking the DNS query used for the Domain Validation email
Pilosof: Showed that any node with BGP access could silently sniff SSL validation emails as well

The Big SSL Hack Of 2008: Stevens and Sotirov v. MD5 [0]
When a Certificate Authority (“country”) deems you worthy of a Certificate (“passport”), it signs (“creates a passport with a hologram”) your public key (“your photo”)
Signing requires two steps
First: Securely “Hash” the certificate, summarizing it down to a small number of bits
A hash is considered “secure” if it’s too difficult to find another file with the same hash
Second: Sign the hash with the CA’s private key
Problem: RapidSSL was using MD5 as its hashing algorithm
MD5 is not secure
We’ve known this since 1996
We’re still using it 

The Big SSL Hack Of 2008: Stevens and Sotirov v. MD5 [1]
Stevens’ (with Lenstra) contribution: “Chosen Prefix Collision Attacks”
Given two different beginnings, create a “blob” that when appended gives them the same hash
Hash(“aabbcc” + X) == Hash(“xxyyzz” + X)
Attack
CA signs a certificate that looks innocent
Attacker shifts out the innocent content, replaces with the intermediate certificate that can sign for anything
Hash(“innocent” + X) == Hash(“intermediate” + X) so signature from one is transferable to the other
Required some really interesting timing work to manage the CA serial number, which had to be accounted for

There’s More Where That Came From
X.509 is remarkably fragile
At pretty much every depth it’s examined, ambiguities and risks are found
Consider hashing functions
MD5 is not the only insecure hash function supported by validators
MD2 is also supported
Predecessor function to MD5, known now to be even less secure than it
If a certificate is signed with MD2RSA, everything (except GnuTLS) will accept it

Shouldn’t This Not Matter?
Stevens and Sotirov required a CA to actively sign specially formed blobs with MD5RSA, in order to exploit the insecurity of MD5
There’s nothing signing with MD2RSA anymore, so everything should be OK, right?

The Final Destination Theory of Cryptographic Vulnerabilities
Cryptographic vulnerabilities tend to be subtle, and telegraphed years, sometimes decades in advance
We don’t know how they’ll burn us
We don’t know when they’ll burn us
We do know we’re going to get burned
It will probably be epic
The relationship to the Final Destination series of movies is left as an exercise to the reader

So it turns out that one of Verisign’s core root certificates is self-signed with MD2
$ openssl x509 -in VeriSign.cer -inform der -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit): …
Exponent: 65537 (0x10001)
Signature Algorithm: md2WithRSAEncryption

The Mystery That Is Self-Signatures
In normal X.509, your public key and subject name are signed by the Certificate Authority
In self-signed X.509, you sign your own public key and subject name with your own private key.
Why?
Assertion: “I am me, says I.”
This is a meaningless assertion!
Presumably there only for consistency
X.509 Certificates are supposed to be signed, so we’ll sign them…it’s harmless, right?
But why sign with MD2?

It was the 90’s.
Peter Guttmann: VeriSign were, as of March 1998, still issuing certificates with an MD2 hash, despite the fact that this algorithm has been deprecated for some time. This may be because they have hardware (BBN SafeKeypers) which can only generate the older type of hash.
RFC 2313 (March 1998): MD2, the slowest of the three, has the most conservative design. No attacks on MD2 have been published.

On The Subject Of Insecure Hashes
There are many ways a hash can fail
Collision: Create two things with the same hash
What Xiaoyun Wang did to MD5, caused my “MD5 To Be Considered Harmful Someday” paper
Chosen-Prefix Collision: Create something that, when appended to two things with different hashes, causes them to have the same hash
What Stevens and Sotirov did to MD5, caused their “MD5 To Be Considered Harmful Today” paper
Preimage: Given a hash, create something new with that hash
SHA-1 has no problems here.
MD5 has no problems here.
MD4 has no problems here.
MD2 has problems here.

Attack #1: VeriSign’s MD2 Root Can Be Exploited By Creating A Malicious Intermediate With The Same MD2 Hash As Its Parent and Transferring The Signature From The Root To The Malicious Intermediate
1) Generate a new Intermediate certificate, allowing any name to be signed for, claiming to be signed by the Verisign root
2) Use a preimage attack to give this Intermediate certificate the same MD2 hash as the root certificate
3) Transfer the self-signature from the parent to the Intermediate
4) The Intermediate will now appear to be signed by the root, since it has the root’s signature across its own MD2 hash
The signature was the root’s self-signature (useless cruft), but now it’s actually doing something (validating a malicious intermediate)
Does depend on there actually being a MD2 preimage attack

MD2 Is The Only Production Hashing Algorithm To Suffer From Preimage Threat
2004: Frédéric Muller, 2^104 complexity
2005: Lars Knudsen, 2^97 complexity
2008: Søren S. Thomsen, 2^73 complexity
Largest known computational efforts, 2^63 complexity

I Can Haz Trend?

Two Options
1) We can wait until the situation is absolutely intolerable
2) We can run faster than the bear
We have no major runtime dependency on MD2 signatures. Nothing has needed it for validation for years. How about we fix something in Crypto before it blows up in our face?

Fixes for CVE-2009-2409 [0]
OpenSSL
1.0beta3 disables MD2
0.9.8cvs disables MD2
0.9.8 release in August disables MD2
NSS (core of Firefox)
NSS 3.12.3 has MD2 disabled already
Used in Firefox 3.5
Firefox 3.0 series getting fixed “soon”
RedHat
Already shipped new NSS to RHEL5
RHEL4 and RHEL3 shipping new NSS after talk

Fixes for CVE-2009-2409 [1]
Verisign
Reissuing Class 3 Certificate as SHA-1
Nothing is actually using the self-signature, remember?
Opera
Waiting on Verisign
Apple
Testing fixes
Microsoft
Testing fixes
Google
Android to have MD2 disabled in August/September
Windows version of Chrome waiting on Microsoft CryptoAPI
GnuTLS
Disabled MD2 a while ago 

And Blow Up It Will: Client Authentication Bypass

IIS adds Verisign Class 3 Root to CTL (Certificate Trust List) because of EKU
CTL is public knowledge, preauth – you can ask a server what roots it accepts to assert arbitrary client names
/C=US/O=First Data Digital Certificates Inc./CN=First Data Digr Ctal Certificates Inc. Certification A uthority /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Basic CA/emailAddress=personal-basic@thawte.com /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) Tanusitvanykiado…
Remember what I said about Exclusion: It doesn’t matter if your CA runs you through the wringer, if some other CA can make the same assertions
Check CTL’s!

The MD5 Root Stevens and Sotirov did not have Client Auth EKU

This Wasn’t Just Verisign’s Problem
VeriSign was the one company to put MD2 into one of their root certs
But many companies were signing web server certs with MD2RSA up into the early 2000’s – and as Stevens/Sotirov showed, if you can corrupt a server cert, you can create an Intermediate with absolute power
Doesn’t matter that they’ve all expired; you can change the date
DOES matter that they’re almost all off the Internet.
Only one left.

FINAL DESTINATION
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Subject: C=US, ST=Tennessee, L=Nashville, O=Rubicon, Inc., OU=Rubicon Research, CN=*.rubic.com
Algorithm: md2WithRSAEncryption

Doesn’t This Need To Be Fixed Immediately?
Relax. It needs to be addressed, but not in a panic.
Went to talk to Bart Preneel of University of Leuven
Len Sassaman’s advisor
Response (paraphased): “There is not likely to be a public preimage attack of less than 2^63 complexity within the next six months, even with this knowledge disbursed.”
Commented specifically that memory requirements must also be addressed
As such, not pushing the emergency sync button (makes things much easier)
Friendly request: Please try not to publicly break MD2 in the next six months, Xiaoyun Wang 
That being said, this is an offline attack, so we wouldn’t see (for example) a flood of requests into existing CA’s

Manipulating Existing CA’s: HOWTO
MD2 attack has no link to present-day CA operations
Verisign hasn’t been signing with MD2 for years
Is it possible to bypass protections in present-day CA operations?

How We Got Here
Meredith L. Patterson: “I’m going to go home and figure out the precise grammar of a certificate, and see just what I can put in there!”
This is the quote that spawned this entire talk
There are two sorts of parsing vulnerabilities
Those that cause the system to misuse memory (traditional exploits)
Those that cause the system to parse a different message than was intended (semantic exploits)

Semantics and Language Theoretic Security
A CA and a Browser “talk” to each other via certificates
CA: “Browser, I tell you that this public key is linked to that subject name”
Browser: “CA, I hear that this public key is linked to this subject name.”
How do we know that what the CA says is what the browser hears?
Language Theoretic Security is the field that attempts to explore this sort of semantic question
Describes how to build parsers that will always parse the same message in the same way, using formal methods
Was first used in 2005 as the theory behind Dejector (grammatical SQL injection defense)
Formalized by Patterson and Sassaman
X.509 was developed long before Dejector / LTS
It shows

The CA Pipeline
1) User generates public and private key
2) User submits “X.509 Subject Name” with public key in a PKCS#10 CSR
Subject name contains many things – Country, State, City, Organization, Organizational Unit…
Only element browsers care about: CN, or “Common Name”
3) If CA approves of Common Name, can do one of two things
(More) Secure: Generate a certificate with the validated components of the X.509 Subject Name (just the CN, validated through DNS)
“ Scrubbing”
Easy: Sign the certificate with the X.509 Subject Name intact

“ Easy” Ways To Use OpenSSL To Build A CA [0]
Sign, and then make sure you approve of the CN before sending
$ openssl x509 -req -in request.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O=Foo Inc./CN=www.foo.com Getting CA Private Key

Dump the PKCS#10 request to text and parse it:
$ openssl req -in request.pem –text Certificate Request: Data: Version: 0 (0x0) Subject: O=Foo Inc., CN=www.foo.com

Dump the generated certificate, then audit the Subject
$ openssl x509 -in modded.crt –text Certificate: Data: Version: 1 (0x0) Serial Number: 127 (0x7f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd Validity Not Before: Feb 8 23:56:39 2009 GMT Not After : Mar 10 23:56:39 2009 GMT Subject: O=Foo Inc., CN=www.foo.com

Problem…

Text Injection Really Easy In This Model
$ openssl x509 -req -in request.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O= Badguy Inc/CN=www.badguy.com /OU=Hacking Division/CN=www.bank.com Getting CA Private Key
OpenSSL Command Line has modes to deal with text injection – “nameopt” option changes output to RFC2233 or Oneline or Multiline, all of which have better filters
None of which are on by default 
Exploitability depends on how text auditor handles multiple CN’s
Multiple CN’s actually something of an open problem

Attack 2A: Multiple Common Names in one X.509 Name are handled differently by different API’s.
An X.509 Subject Name contains multiple entities, only one of which really matters
The “Common Name”
What happens if there are multiple Common Names?
It completely depends on the implementation, and even the software using the implementation

So Many Choices
OpenSSL: First CN wins (usually)
CryptoAPI / IE: All-Inclusive – any CN in the Certificate is acceptable
NSS / Firefox: Last CN wins
RFC: “Most Specific” (which is not defined in RFC)
FAIL

“ Usually?”
Possible to use OpenSSL API to return all CN’s in Certificate
int loc; X509_NAME_ENTRY *e loc = -1; for (;;) { lastpos = X509_NAME_get_index_by_NID(nm, NID_commonName, lastpos); if (lastpos == -1) break; e = X509_NAME_get_entry(nm, lastpos); /* Do something with e */ }

But Nobody Does It
Most common pattern: X509_NAME_get_text_by_NID (subj, NID_commonName, data, 1024); return data;
Seen in Claws, Open1x, Wget, Bacula, Neon, OpenLDAP
A CA based on X509_NAME_get_text_by_NID would only see/validate the first CN

So What Would You Do?
Wildcard policy
Netscape has an unlimited wildcard policy – if you can get a cert for *, you win
IE has a “chicken” wildcard policy – they’re only accepted two labels in (*.xxx.yyy)
Three CN’s in one PKCS#10 Request
CN=www.attacker.com // for OpenSSL
CN=www.bank.com // for IE
CN=* // For Netscape

But What Is A CN, Anyway?
X.509 is written to ASN.1, something of a precursor to XML
Designed to be very fast to parse
Actually very fast to crash under fuzzing
In 2002, the PROTOS project fuzzed SNMP and pretty much destroyed every router on the planet
Every CA has an ASN.1 listener via PKCS#10
Should be based on a standard stack, hardened after 2002, but there’s random custom code all over the place out there

Warning: Also a channel for SQL Injection
Apparently, XKCD’s Little Bobby Tables caused some people to realize this might show up in a certificate (courtesy of Peter Guttmann):
125 40: SET {
127 38: SEQUENCE {
129 3: OBJECT IDENTIFIER commonName (2 5 4 3)
134 31: TeletexString 'Bob';DROP TABLE certificates;--'
: }

Names and Numbers
In ASN.1, “Common Name” is not expressed by text, but by an “Object Identifer” or “OID”
2.5.4.3 is the OID for Common Name
How is this encoded?

ASN.1 OIDs
ASN.1 BER (Basic Encoding Rules) is a TLV (Tag-Length-Value) file format
OIDs – Tagged 0x06 – have multiple numbers in a row, which may be larger than an individual byte
Numbers are encoded in Base 128 – if the high bit is set(>0x80) then the next number is part of this subdigit
06 = six
86 = six, and there’s another digit coming

Simple OID
2.5.4.3 (Common Name)
T=06 (Object Identifier) L=03 (Length==3) V= 55: 2.5 // Don’t ask, really stupid compression 04: .4 03: .3

More Complex OID
RSA Encryption ( 1.2.840.113549.1.1.1 )
T=06 (Object Identifier)
L=09 (Length==9)
V=
2A: 1.2
86 48: (6 * 128) + 72 = .840
86 F7 0D: (6 * 128 * 128) + (119 * 128) + 13 = .113549
01: .1
01: .1
01: .1
Or, in full: 06 09 2A 86 48 86 F7 0D 01 01

Subattack 1: Leading 0’s
T=06 (Object Identifier) L=03 (Length==4) V= 55: 2.5 04: .4 80 03: (0 * 128) + 3 == .3
This has been seen for a couple of LDAP attacks, but we’re using it semantically now
Suppose we added “2.5.4.03 == www.bank.com ” to an X.509 Subject Name. What would be seen?

Leading 0’s v. OpenSSL: Parses to 2.5.4.3, but not CN
$ openssl req -in test.der -inform der -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: O=Badguy Inc, CN=www.badguy.com, OU=Hacking Division/ 2.5.4.3=www.bank.com
$ openssl x509 -req -in modded.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt
Signature ok
subject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/ 2.5.4.3=www.bank.com
Getting CA Private Key

Leading 0’s v. NSS: Parses to 2.5.4.3, but not CN

Leading 0’s v. IE: We have CN!

Subattack 2: Semantic Integer Overflow
One of the most common vulnerabilities in software – the Integer Overflow
Programmers forget that if you add too much to a hardware counter, it loops back to zero
We have an algorithm that multiplies and adds
What if we make it do this past 2^64?
2.5.4.2^64+3
06 0D 55 04 82 80 80 80 80 80 80 80 80 80 03

OpenSSL: Not fooled
OpenSSL has a bignum library – it simply cannot overflow
$ openssl x509 -req -in modded.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/ 2.5.4.2361183241434822606851=www.bank.com Getting CA Private Key

Netscape: Overflows, but not exploitably

IE: 2.5.4.2^64+3 == 2.5.4.3 == CN

That Being Said
Realistically, most CA’s extract a CN and throw away the rest
Good!
Is there anything malicious we could get into the CN?
Can’t throw that out, that’s what we’re actually validating

So What’s In A Common Name Anyway?
Object Identifier: 2.5.4.3
T: 06 (OID) L: 03 (Length==3 V: 55 (2.5) 04 (.4) 03 (.3)
Printable String: www.doxpara.com
T: 13 (Printable String) L: 0F (Length==15) V: 77 77 77 2E 64 6F 78 70 61 72 61 2E 63 6F (www.doxpara.com)

Some Extra Special Magic We Can Do Because It’s ASN.1
ASN.1 has ~13 different string types
Interesting: BMPString (2-byte Unicode, Fixed Length), UniversalString (4-byte Unicode, Fixed Length)
Why Interesting?
Trivial Read AV in OpenSSL PKCS#10 Parser

Code Snippet
while(p != q) { // DK: Stop reading once we’re at the end of the string ... case 4: // DK: advance four bytes, even if this extends past the end of the string c = ((unsigned long)*p++) << 24; c |= ((unsigned long)*p++) << 16; c |= ((unsigned long)*p++) << 8; c |= break;
Alas, not exploitable – doesn’t write any memory after overflowing, so it eventually just reads off into unallocated space
Fixed anyway, quietly
There’s some other fun stuff with strings, I’ll talk about it later

Fun With Printable Strings
There are two ways of ending a string of text
With an explicit length field (ASN.1)
With the 0x00 “Null Terminator” (C)
What happens when you put 0x00 in the middle of a CN?
OpenSSL: CN=www.defcon.orgx00www.ohexohoh.com
“ This is part of the ohexohoh.com domain!”
Domain Validation thus goes to ohexohoh.com

WIN (again)
Yes, that’s a real certificate
No, I’m not going to tell you who issued it
Yes, I could have just as easily gotten a cert for *00.doxpara.com

Null In CN Being Fixed In Browsers as CVE-2009-2408
Genuinely worried about this bug
Most CA’s should be clean, but we really want this client side
NSS 3.2.13 already contains fix, thus Firefox 3.5 is covered
Firefix 3.0 will be moved to NSS 3.2.13 “soon”
Opera should also be covered
IE / Safari “testing”

So What Am I Suggesting
Move everyone to DNSSEC and get rid of the CA’s?
No. The Certificate Authorities are actually really useful – they’re just doing the best they can with a really fragile technology
They are the only entities with sufficient local knowledge to be able to handle Semantic Name Collisions like www.bank-of-america.com
If you think that’s easy, imagine doing it for banks in Turkey and India and China, and not in English
DNS does not and cannot provide this service
Yes, people keep asking 
Extended Validation is the mechanism, built via X.509 Extensions, by which special CA knowledge is bubbled up to the user (via “Green Bar”)

On EV
Extended Validation has gotten some noise lately
If somebody has the DV version of your certificate, they can hijack the EV version of your site
This is by design
If you couldn’t deploy EV without disabling all DV SSL includes, nobody would be running EV besides Paypal

Surprise?
People are unusually surprised by this, even though Collin Jackson and Adam Barth discussed it two years ago and it was in my slide deck last year
Some CA’s got out of sync with browser makers, told people EV solved the DV problem
Mike Zusman and Alexander Sotirov have some really cool demos of exploiting the DV/EV bridge
EV only handles semantic collisions – and it does it well

What We Do
We get the DNS root signed so DNSSEC development can start in earnest
Server work to get hosting stable
Client work to get end-to-end trust
We use DNSSEC to bootstrap cross-organizational trust for most other protocols
SSH, IPSec, PGP, SSL
Put the hash of the cert in DNS
Since DNSSEC inherits DNS’s exclusivity, the existence of the hash of an EV cert in DNSSEC will exclude any corrupt DV cert
This is how you end up defending EV from DV, while still allowing CA’s to perform their semantic assertions

Summary
X.509 is Messy
Operationally, lack of segregation and delegation makes it really expensive to use, forces really painful decisions
Technically, the technology is oddly fragile
Organizations are doing the best they can
Browser manufacturers work very closely with CA’s in CAB Forum
Everybody has been very responsive
People working this hard deserve a better base on which to build

Black opspki 2

by dakami on Nov 28, 2010

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Black opspki 2 Presentation Transcript