copyright IOActive, Inc. 2006, all rights reserved.

Black Ops of PKI

Or: When I Hear The Word Certificate,I Reach For My Gun

Dan KaminskyDirector of Penetration Testing

IOActive, Inc.

Len Sassaman& Meredith L. Patterson

K. U. Leuven

Introduction

• Hi! I’m Dan Kaminsky!– This is my 10th 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?

MD2 Cracking Complexity

0

20

40

60

80

100

120

2004 2005 2006 2007 2008

Date

Co

mp

lexi

ty

Theory

Warning Line

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 Authority/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 oksubject=/O=Foo Inc./CN=www.foo.comGetting CA Private Key

“Easy” Ways To Use OpenSSL To Build A CA [1]

• Dump the PKCS#10 request to text and parse it:

• $ openssl req -in request.pem –textCertificate Request: Data: Version: 0 (0x0) Subject: O=Foo Inc., CN=www.foo.com

“Easy” Ways To Use OpenSSL To Build A CA [2]

• 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 oksubject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/CN=www.bank.comGetting 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 oksubject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/2.5.4.2361183241434822606851=www.bank.comGetting 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 stringc = ((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.org\

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