BlackOpsPKI.ppt

7/27/2019 BlackOpsPKI.ppt

1/84

copyright IOActive, Inc. 2006, all rightsreserved.

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


2/84

Introduction Hi! Im Dan Kaminsky!

This is my 10thtalk here at Black Hat!

Focus of most of my talks has been onfoundational elements of Internet Security

SSH

TCP/IP

DNS

Web Browser Same Origin Policy

DNS

Visual Pattern Recognition In Binary Data

DNS

SSL


3/84

The Crisis Of Authentication Vulnerabilities / 0-day get all the press, but

According to Verizon Business, 60%of actual real world datalosses 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


4/84

The Two Schools Of Thought We can make passwords workbarely

Machine generated

Rapidly cycled

l33tpaZ$

As Schneier has noted, still trivially vulnerable tokeysniffing

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!


5/84


6/84

Reality Check Business has cared enough about PKI to invest

hundreds of millions of dollars in it over the last tenyears

Something is not working

I believe that something is X.509, thetechnology at the core of present-day PKI

We have learned so much about real-world

security since the 90s, when X.509 wasdeveloped. If were to get past passwords, wehave to start putting that knowledge to usewithDNSSEC.


7/84

Rethinking The Foundations Of

Internet Security

There are those who think we should create aNew Internet, which would just not have any of

these security problems

This is hopeful, but nave

Similar to building cities without roads orhighways in the middle of a forestBut it willhave great mass transit doesnt make up for

that

However: What we are doing now, the way we aredoing it, is not working. Lets talk about why.


8/84

Warning

The first fifteen minutes of this talk arent

that l33t, so as a preview


9/84

DEFCON Yes, thats a real certificate

No, Im 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


10/84

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 wherepublic keys and subjectnames of individuals are signed by certificate authoritiestrusted bymany people, such that if you have a specific private key, otherpeople may validateyour 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 thats in the photo, and its on acard issued by your country, then you have the name of theperson on the passport.

X.509 is just the digital version of this


11/84

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!


12/84

Walkthrough: Acquiring An X.509

Certificate For A Website [0]

1) Register a name in DNS, providing an emailaddress 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 registeredin DNS

This is done with whats called a PKCS#10

Certificate Signing Request, or CSR


13/84

Walkthrough: Acquiring An X.509

Certificate For A Website [1]

4) The Certificate Authority, or CA, asks DNS forthe email address of the user who administers thatwebsite, and then emails the user making sure its

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 realwww.whatever.com


14/84

Im Oversimplifying, Arent I? What I just described is called Domain Validation

there are many CAs that offer much more

stringent validation DUNS lookups

Phone calls

Lawyers who show up at the door and take a

blood sample

Just kidding

Doesnt matter, because of flaw #1


15/84

X.509 Cannot Exclude (without great

pain)

There are dozens and dozens of CAs out there trusted by

everyone

Every CA can issue certificates for every single name

Zimbabwe can issue American passports

Even if yourCA runs you through the wringer, that doesntmean every other one will

Security of the whole is equal to security of the weakestlink

Anything more is, unfortunately, security theatre

There are many very good, very responsible, very

responsive CAs out there. X.509 does not allow them to

provide a more secure solution than their competitors

Technical term: Race to the bottom


16/84

DNS Is Very Good At Excluding DNS has three layers

The root: There is only one root.

Classic quote: The CA system is only assecure as the money they refuse to take.The rootas is, anywaywont take yourmoney. Root is part of State system.

The Registries: Verisign has exclusive control

over .com. Afilias has exclusive control over.org.

One of the TLDs had a real problem withmalware. The registry behind that TLDrecognized the problem and cleaned it up.


17/84

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

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
http://www.doxpara.com/http://www.doxpara.com/


18/84

X.509 Exclusion Is Painful Possible to exclude untrusted CAs

Can run a private CA

Very expensive

Very difficult to maintain

What happens when you need to interoperate with otherindividuals behind other private CAs?

Federal Bridge CA

The people who made this work deserve a medal This problem shouldnt require awarding medals the

few times its actually solved


19/84

Interop: Not actually optional Theory: You only need to authenticate to your

own organizationhow often is your house keyused in other homes?

Reality: Cross-organizational authentication is therule and not the exception

Partnerships with other companies

Interactions with other groups

There are many organizations in eachcompany

Software As A Service / Cloud Services

Passwords interoperate well.


20/84

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 thatparticular 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 allowedyou to sign for *.doxpara.com or whatnot

Very weak support in field, so you cant buy this from anyone

Can also fix with wildcards, which arent a great idea either

Every node can read traffic from every other node?!


21/84

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


22/84

X.509 Delegation Is Painful Seriousdemand for being able to issue a certificate using

your Private CA, that is valid outside your own organization

Cant do this securely without Name Constraints

Solution: Do this anyway Forget hacking CAs. Prove youre a business of

some size, and sign an insurance policy, and you getan intermediatecertificate that allows you to sign forany name on the planet

At least two companies offer this, probably more

No way of knowing how many intermediates are outthere

Its not that the companies dont take security seriously.

Its that the technology doesnt allow them to offer

anything better.


23/84

2008: Not A Good Year For X.509

CAs

Mike Zusman: Bypassed Thawtes security

checks by claiming www.live.comwas the nameof an internal server and thus not subject to

validation at all

Also bypassed Startcoms checks via a web

interface hack

Me: Bypassed almost all CAsvalidationmechanisms by hijacking the DNS query used forthe Domain Validation email

Pilosof: Showed that any node with BGPaccess could silently sniff SSL validation emails

as well
http://www.live.com/http://www.live.com/


24/84

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 ahologram) your public key (your photo)

Signing requires two steps First: Securely Hash the certificate, summarizing itdown to a small number of bits

A hash is considered secure if its too difficult to findanother file with the same hash

Second: Sign the hash with the CAs private key

Problem: RapidSSL was using MD5 as its hashing algorithm

MD5 is not secure

Weve known this since 1996

Were still using it


25/84

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) sosignature from one is transferable to the other

Required some really interesting timing work to manage theCA serial number, which had to be accounted for


26/84

Theres More Where That Came From

X.509 is remarkably fragile

At pretty much every depth its examined,ambiguities and risks are found

Consider hashing functions

MD5 is not the only insecure hash functionsupported by validators

MD2 is also supported

Predecessor function to MD5, known now tobe even less secure than it

If a certificate is signed with MD2RSA,everything (except GnuTLS) will accept it


27/84

Shouldnt This Not Matter?

Stevens and Sotirov requireda CA to

actively sign specially formed blobs with

MD5RSA, in order to exploit the insecurityof MD5

Theres nothing signing with MD2RSA

anymore, so everything should be OK,right?


28/84

The Final Destination Theory of

Cryptographic Vulnerabilities

Cryptographic vulnerabilities tend to be subtle, and

telegraphed years, sometimes decades in

advance We dont know how theyll burn us

We dont know when theyll burn us

We do know were 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


29/84

So it turns out that one of Verisigns 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 PublicPrimary 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 PublicPrimary Certification Authority Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit):

Exponent: 65537 (0x10001)

Signature Algorithm: md2WithRSAEncryption


30/84

The Mystery That Is Self-Signatures

In normal X.509, yourpublic key and subject namearesigned 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 well

sign themits harmless, right?

But why sign with MD2?


31/84

It was the 90s. Peter Guttmann: VeriSign were, as of March

1998, still issuing certificates with an MD2 hash,

despite the fact that this algorithm has beendeprecated 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 thethree, has the most conservative design. No

attacks on MD2 have been published.


32/84

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 BeConsidered Harmful Someday paper

Chosen-Prefix Collision: Create something that, whenappended to two things with different hashes, causes them tohave the same hash

What Stevens and Sotirov did to MD5, caused their MD5To 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.


33/84

Attack #1: VeriSigns MD2 Root Can Be Exploited By

Creating A Malicious Intermediate With The Same MD2

Hash As Its Parent and Transferring The SignatureFrom The Root To The Malicious Intermediate

1) Generate a new Intermediate certificate, allowing anyname to be signed for, claiming to be signed by the Verisignroot

2) Use a preimage attack to give this Intermediate certificatethe same MD2 hash as the root certificate

3) Transfer the self-signature from the parent to theIntermediate

4) The Intermediate will now appear to be signed by the root,since it has the roots signature across its own MD2 hash

The signature wasthe roots self-signature (uselesscruft), but now its actually doing something (validating amalicious intermediate)

Does depend on there actually being a MD2 preimageattack


34/84

MD2 Is The Only Production Hashing

Algorithm To Suffer From PreimageThreat

2004: Frdric Muller, 2^104 complexity

2005: Lars Knudsen, 2^97 complexity

2008: Sren S. Thomsen, 2^73 complexity

Largest known computational efforts, 2^63

complexity


35/84

I Can Haz Trend?MD2 Cracking Complexity

0

20

40

60

80

100

120

2004 2005 2006 2007 2008

Date

Complexity

Theory

Warning Line


36/84

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. Howabout we fix something in Crypto before

it blows up in our face?


37/84

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


38/84

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


39/84

And Blow Up It Will: Client

Authentication Bypass


40/84

IIS adds Verisign Class 3 Root to CTL

(Certificate Trust List) because of EKU

CTL is public knowledge, preauthyou can ask a serverwhat 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/[email protected]/C=US/O=VeriSign, Inc./OU=Class 3 Public PrimaryCertification 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) 1998VeriSign, 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 doesnt matter ifyour CA runs you through the wringer, if some other CA canmake the same assertions

Check CTLs!


41/84

The MD5 Root Stevens and Sotirov

did not have Client Auth EKU


42/84

This Wasnt Just Verisigns 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 2000s and as Stevens/Sotirovshowed, if you can corrupt a server cert, you can create anIntermediate with absolute power

Doesnt matter that theyve all expired; you can change

the date

DOES matter that theyre almost all off the Internet. Only one left.


43/84

FINAL DESTINATION Issuer: C=ZA, ST=Western Cape, L=Cape Town,

O=Thawte Consulting cc, OU=Certification

Services Division, CN=Thawte Server

CA/[email protected]

Subject: C=US, ST=Tennessee, L=Nashville,

O=Rubicon, Inc., OU=Rubicon Research,

CN=*.rubic.com Algorithm: md2WithRSAEncryption
mailto:CA/[email protected]:CA/[email protected]:CA/[email protected]:CA/[email protected]


44/84

Doesnt 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 Sassamans advisor

Response (paraphased): There is not likely to be a public

preimage attack of less than 2^63 complexity within the next sixmonths, even with this knowledge disbursed.

Commented specifically that memory requirements mustalso be addressed

As such, not pushing the emergency sync button (makes thingsmuch easier)

Friendly request: Please try not to publicly break MD2 in thenext six months, Xiaoyun Wang

That being said, this isan offline attack, so we wouldnt see (forexample) a flood of requests into existing CAs


45/84

Manipulating Existing CAs: HOWTO

MD2 attack has no link to present-day CA

operations

Verisign hasnt been signing with MD2for years

Is it possible to bypass protections in

present-day CA operations?


46/84

How We Got Here Meredith L. Patterson: Im going to go home and

figure out the precise grammar of a certificate, andsee 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 misusememory (traditional exploits)

Those that cause the system to parse adifferent message than was intended(semantic exploits)


47/84

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 thatsubject name

Browser: CA, I hear that this public key is linked to thissubject name.

How do we know that what the CA says is what the browserhears?

Language Theoretic Security is the field that attempts toexplore this sort of semantic question

Describes how to build parsers that will always parse thesame 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


48/84

The CA Pipeline 1) User generates public and private key

2) User submits X.509 Subject Name with public key in aPKCS#10 CSR

Subject name contains many thingsCountry, State,City, Organization, Organizational Unit

Only element browsers care about: CN, or CommonName

3) If CA approves of Common Name, can do one of twothings

(More) Secure: Generate a certificate with the validatedcomponents of the X.509 Subject Name (just the CN,validated through DNS)

Scrubbing

Easy: Sign the certificate with the X.509 Subject Name

intact


49/84

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 -CAca.pem -CAkey ca.key -CAserial ca.srl -out

modded.crt

Signature oksubject=/O=Foo Inc./CN=www.foo.com

Getting CA Private Key


50/84


Build A CA [1]

Dump the PKCS#10 request to text and

parse it:

$ openssl req -in request.pemtextCertificate Request:

Data:

Version: 0 (0x0)Subject: O=Foo Inc.,

CN=www.foo.com


51/84


Build A CA [2] Dump the generated certificate, then audit the Subject

$ openssl x509 -in modded.crttextCertificate:

Data:Version: 1 (0x0)Serial Number: 127 (0x7f)Signature Algorithm: sha1WithRSAEncryptionIssuer: C=AU, ST=Some-State, O=Internet Widgits Pty

LtdValidity

Not Before: Feb 8 23:56:39 2009 GMTNot After : Mar 10 23:56:39 2009 GMT

Subject: O=Foo Inc., CN=www.foo.com


52/84

Problem


53/84

Text Injection Really Easy In This

Model $ openssl x509 -req -in request.pem -CA ca.pem -CAkey

ca.key -CAserial ca.srl -out modded.crtSignature oksubject=/O=Badguy

Inc/CN=www.badguy.com/OU=HackingDivision/CN=www.bank.comGetting CA Private Key

OpenSSL Command Line has modes to deal with textinjectionnameopt option changes output to RFC2233 orOneline or Multiline, all of which have better filters

None of which are on by default

Exploitability depends on how text auditor handles multipleCNs

Multiple CNs actually something of an open problem


54/84

Attack 2A: Multiple Common Names in

one X.509 Name are handled differentlyby different APIs.

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 theimplementation, and even the software

using the implementation


55/84

So Many Choices OpenSSL: First CN wins (usually)

CryptoAPI / IE: All-Inclusiveany CN in

the Certificate is acceptable NSS / Firefox: Last CN wins

RFC: Most Specific (which is not defined

in RFC) FAIL


56/84

Usually? Possibleto use OpenSSL API to return all CNs in Certificate

int loc;X509_NAME_ENTRY *eloc = -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 */}


57/84

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 onX509_NAME_get_text_by_NID would onlysee/validate the first CN


58/84

So What Would You Do? Wildcard policy

Netscape has an unlimited wildcard policyif

you can get a cert for *, you win IE has a chicken wildcard policy theyre only

accepted two labels in (*.xxx.yyy)

Three CNs in one PKCS#10 Request

CN=www.attacker.com // for OpenSSL

CN=www.bank.com // for IE

CN=* // For Netscape


59/84

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 andpretty much destroyed every router on the planet

Every CA has an ASN.1 listener via PKCS#10

Shouldbe based on a standard stack,hardened after 2002, but theres random

custom code all over the place out there


60/84

Warning: Also a channel for SQL

Injection

Apparently, XKCDs Little Bobby Tables caused

some people to realize this might show up in acertificate (courtesy of Peter Guttmann):

125 40: SET {

127 38: SEQUENCE {

129 3: OBJECT IDENTIFIERcommonName (2 5 4 3)

134 31: TeletexString 'Bob';DROPTABLE certificates;--'

: }


61/84

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?


62/84

ASN.1 OIDs ASN.1 BER (Basic Encoding Rules) is a TLV (Tag-

Length-Value) file format

OIDsTagged 0x06have multiple numbers in arow, which may be larger than an individual byte

Numbers are encoded in Base 128if the high bit

is set(>0x80) then the next number is part of this

subdigit 06 = six

86 = six, and theres another digit coming


63/84

Simple OID 2.5.4.3 (Common Name)

T=06 (Object Identifier)

L=03 (Length==3)V=

55: 2.5 // Dont ask, really stupid compression

04: .403: .3


64/84

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


65/84

Subattack 1: Leading 0s T=06 (Object Identifier)

L=03 (Length==4)V=

55: 2.504: .480 03: (0 * 128) + 3 == .3

This has been seen for a couple of LDAP attacks,

but were using it semantically now Suppose we added 2.5.4.03 == www.bank.com

to an X.509 Subject Name. What would be seen?
http://www.bank.com/http://www.bank.com/


66/84

Leading 0s 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 -CAkeyca.key -CAserial ca.srl -out modded.crt

Signature ok

subject=/O=Badguy Inc/CN=www.badguy.com/OU=HackingDivision/2.5.4.3=www.bank.com



67/84

Leading 0s v. NSS: Parses to

2.5.4.3, but not CN


68/84

Leading 0s v. IE: We have CN!


69/84

Subattack 2: Semantic Integer

Overflow One of the most common vulnerabilities in

softwarethe Integer Overflow

Programmers forget that if you add too much toa 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


70/84

OpenSSL: Not fooled OpenSSL has a bignum libraryit 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=HackingDivision/2.5.4.2361183241434822606851=www.b

ank.com



71/84

Netscape: Overflows, but not

exploitably


72/84

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


73/84

That Being Said Realistically, mostCAs extract a CN and

throw away the rest

Good! Is there anything malicious we could get

into the CN?

Cant throw that out, thats what wereactually validating


74/84

So Whats 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)
http://www.doxpara.com/http://www.doxpara.com/


75/84

Some Extra Special Magic We Can

Do Because Its ASN.1

ASN.1 has ~13 different string types

Interesting: BMPString (2-byte Unicode,

Fixed Length), UniversalString (4-byteUnicode, Fixed Length)

Why Interesting?

Trivial Read AV in OpenSSL PKCS#10Parser


76/84

Code Snippet while(p != q) { // DK: Stop reading once were 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++)


77/84

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 ofa CN?

OpenSSL:CN=www.defcon.org\x00www.ohexohoh.com

This is part of the ohexohoh.com domain!

Domain Validation thus goes toohexohoh.com


78/84

WIN (again) Yes, thats a real

certificate

No, Im not going to

tell you who issued it

Yes, I could have just

as easily gotten a cert

for *\00.doxpara.com


79/84

Null In CN Being Fixed In Browsers

as CVE-2009-2408 Genuinely worried about this bug

Most CAs should be clean, but we reallywant

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


80/84

So What Am I Suggesting Move everyone to DNSSEC and get rid of the CAs?

No. The Certificate Authorities are actually really usefultheyre 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 likewww.bank-of-america.com

If you think thats easy, imagine doing it for banks in

Turkey and India and China, and not in English DNS does not and cannotprovide this service

Yes, people keep asking

Extended Validation is the mechanism, built via X.509Extensions, by which special CA knowledge is bubbled

up to the user (via Green Bar)
http://www.bank-of-america.com/http://www.bank-of-america.com/http://www.bank-of-america.com/http://www.bank-of-america.com/http://www.bank-of-america.com/http://www.bank-of-america.com/


81/84

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 couldnt deploy EV without

disabling all DV SSL includes, nobodywould be running EV besides Paypal


82/84

Surprise? People are unusually surprised by this, even

though Collin Jackson and Adam Barth discussedit two years ago and it was in my slide deck last

year Some CAs got out of sync with browser

makers, told people EV solved the DV problem

Mike Zusman and Alexander Sotirov havesome really cool demos of exploiting the DV/EV

bridge EV only handles semantic collisionsand it does

it well


83/84

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 formost other protocols

SSH, IPSec, PGP, SSL

Put the hash of the cert in DNS

Since DNSSEC inherits DNSs exclusivity, the existence of

the hash of an EV cert in DNSSEC will excludeany corruptDV cert

This is how you end up defending EV from DV, while stillallowing CAs to perform their semantic assertions


84/84

Summary X.509 is Messy

Operationally, lack of segregation anddelegation 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

CAs in CAB Forum Everybody has been very responsive

People working this hard deserve a better baseon which to build

Date post:	14-Apr-2018
Category:	Documents
Upload:	arteepu4
View:	216 times
Download:	0 times

BlackOpsPKI.ppt

Documents