DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
Â
Black opspki 2
1. copyright IOActive, Inc. 2006, all rights
reserved.
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. 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
3. 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
4. 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!â
5.
6. 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.
7. 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.
8. Warning
⢠The first fifteen minutes of this talk arenât
that l33t, so as a previewâŚ
9. 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
10. 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
11. 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. 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
13. 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
14. 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âŚ
15. 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â
16. 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.
17. 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
18. 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
19. 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.
20. 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?!
21. 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. 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.
23. 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
24. 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 ď
25. 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
26. 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
27. 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?
28. 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
29. 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
30. 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?
31. 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.
32. 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.
33. 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
34. 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
35. 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. 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?
37. 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. 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. And Blow Up It Will: Client
Authentication Bypass
40. 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!
41. The MD5 Root Stevens and Sotirov
did not have Client Auth EKU
42. 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.
44. 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
45. 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?
46. 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)
47. 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
48. 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
49. â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
50. â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 âtext
Certificate Request:
Data:
Version: 0 (0x0)
Subject: O=Foo Inc.,
CN=www.foo.com
51. â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
53. 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
54. 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
55. 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
56. â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 */
}
57. 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
58. 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
59. 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
60. 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;--'
â : }
61. 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. 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
65. 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?
66. 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
69. 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
70. 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.b
ank.com
Getting CA Private Key
73. 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
74. 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)
75. 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
76. 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
77. 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
78. 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
79. 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â
80. 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â)
81. 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
82. 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
83. 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
84. 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