As a form of term paper for the Computers and Networks Security class at Roma Tre University, students have been asked this year to contribute to a wiki. I obviously picked the class and I’ve been assigned to a group in charge to write a threats analysis over the SSL / TLS protocol. Since I already had a look at presentations by independent researcher Moxie Marlinspike, I wrote an hopefully detailed report of the attacks he presented at Defcon17 last August. I discussed this report few days ago and since the wiki will be probably kept private for students, i’m going to publish this relation here, that follows.

SSL / TLS

Secure Sockets Layer (SSL) and its successor Transport Layer Security TLS are cryptographic protocols that aim to provide security for data transmitted over networks.
While the SSL wording refers to the original specifications developed by Netscape Corporation , TLS is an IETF standard, last updated in rfc2546, that anyway is based on the SSL specification, explaining why the word ”SSL” is often used to indicate the actual TLS protocol.
While the protocol is widely used to secure overlaying application level insecure protocols, such as HTTP, FTP, SMTP or VoIP applications, it may be used to secure tunneling virtually any other protocol.

How the protocol works

The protocol works encrypting the segments of network connections at the transport layer end-to-end, and is able to provide integrity of data, (optional) confidentiality and (again, optional) end-point authentication.

There are two main phases, the handshake, and the data exchange.

The Handshake

In the Handshake phase, the end points agree on some parameters used to establish the connection, such as cipherSuites, random numbers, and a ”pre-master secret” usually generated by the client. The ”pre-master secret” exchange is typically secured using RSA, or Diffie-Hellman, or DH-Effimeral that provide Perfect forward Secrecy. Moreover, at this step one or both the end-points may authenticate themselves by presenting their Certificates.

Details

• One of the end-points ( from now referred ad the client ) sends a ClientHello specifying his supported versions of the protocol, cipherSuites, compression methods and a random number. A cipherSuite is basically a propose of algorithms to use for pre-master secret exchange, symmetric data exchange cryptography (that may be NULL) and integrity check. ( E.g. a ciphersuite for TLS that imply the use of RSA for pre-master secret exchange, Triple DES for channel symmetric cryptography and SHA hash functions for integrity checks looks like TLS_RSA_WITH_3DES_EDE_CBC_SHA ). For those first messages sent in clear and without any check the ciphersuite in use is something like TLS_NULL_NULL_NULL, that should be available for the very first handshake only.
• The other end-point (from now referred ad the server ) sends back a ServerHello message, picking the strongest cipherSuite it support, the chosen compression method and another random number.
• Now the server may or not send its Certificate to be authenticated.
• The server may also optionally require the client’s Certificate with a CertificateRequest message.
• If that happened, the client sends back its own Certificate providing mutual authentication.
• The server sends a ServerHelloDone advertising that it’s ready for the key exchange phase.
• The client issue a ChangeCipherSpec message to advertise that the negotiated cipherSuite is going to be used.
• Depending on the chosen cipherSuite, the client issue a ClientKeyExchange that starts the RSA, DH, DHE or whatever key exchange algorithm has been negotiated.
• The end-points follow the chosen algorithm to exchange the pre-master secret generated by the client, from which, along with the random numbers previously exchanged, they compute the encryption key and the integrity key for the next phase.

The Data Exchange

In the Data Exchange phase, the protocol provide optional confidentiality with symmetric cryptography using an encryption key function of the pre-master secret and of the random numbers exchanged in the handshake.

Is also guaranteed the integrity of every segment, since every cipherSuite except the first all-null used for the first handshake provide an hash function for the integrity check.

Details

• Each record to be transmitted in the the data exchange phase, is at first made of a sequence number, a Record Header and the data.
• *An HMAC of this entire record ( computed using the hash function in the ciphersuite and an integrity key obtained from pre-master secret and random numbers exchanged ) is appended to the only data, and then the result is padded to match the record payload length.
• If the cipherSuite provide a not-NULL encryption algorithm this is then encrypted ( with the cryptographic algorithm in the ciphersuite using an encryption key computed from pre-master secret and random numbers exchanged ) and the result is appended to the Record Header to build the SSL record that is going to be transmitted.
• The sequence number of the original record is not transmitted because it can be recomputed on the other end-point since TCP assure the correct order of the packet stream and then it can be recomputed in order to rebuild the original record needed to match the integrity check.

The first transmission into the encrypted channel of the Data Exchange phase is a mutual HMAC of the previous messages to avoid ciphersuite tampering from any man-in-the-middle between the end-points. If this check fail, no further data is transmitted and the connection is killed. This is performed only after the first handshake because the first cipherSuite is all-NULL, but is not necessary in further handshakes such as in case of renegotiation, since that happend inside the already established tunnel that should provide integrity check.

Check of X509 Basic Constraints

It’s now described an old (and hopefully outdated) vulnerability by which most SSL implementations were afflicted.

Certificates, CA and Verification process

When attempting to establish a secure connection, there is often the need to verify the identity of the other side of the communication. SSL protocol provide this to be achieved by retrieving and verifying something from the other side, called SSL Certificate. Certificates are basically public keys presented in standard data structure by entities ( subjects of the certificate ) interested in having their own identity verified, and are therefore signed by some other entity ( called CA: Certification Authority ) that is assumed trusted or that is further verified. Signs can be verified themselves when signer CA certificates are known and trusted or can be verified, so their public key may be used for the check.

In the contest of web surfing, the process of certificates verification is performed by web browsers that build and verify an arbitrary length certificates chain in which each node is signed by the entity certified by the previous one. The root of the chain is a root CA certificate, that is trusted since is embedded in the browser. Any other node in the chain but the leaf act as an intermediate and represent a CA whose certificate is not embedded in the browser, but is assumed trusted if signed by a root CA or by another CA whose certificate is signed on cascade from a root CA. In order to validate the chain, the browsers start from the leaf node and follow these steps:

1. Verify that the node has the same name of the site requested
2. Verify that the node has not expired
3. Check the signature ( must match the next entity in the chain )
4. If the next entity is in the list of root CA embedded in the browser stop and trust the leaf
5. Otherwise, move to the upper entity in the chain and repeat these steps.

The missing check

Back to few years ago, most of the implementations used a simple recursive function to validate the certificates chains, mostly focused on the signature validation and on verifying the complete chain. The missing piece was that only CA should be allowed to sign certificates for other domains, and that should be expressed as the X.509 standard states, in a section of the certificate called Basic Constraints.
But back in times, most CA didn not explicitly set Basic Constraints “CA=FALSE” in the certificates they sign for leaf entities and most alarming, lots of web browsers and other SSL implementations did not even check that, whether the field was there or not.
As a result, anyone with a valid leaf node certificate could create and sign a leaf node certificate for any other domain. Then, when presented with the complete chain most browsers considered it valid.

Even if someone says some implementations still doesn’t check basic constraints, the most common fixed this problem just post disclosure. We checked against this problem the newest releases of Mozilla NSS, OpenSSL and GNUTLS, that results in doing this check .

SSLSniff ( Original Purpose )

The SSLSniff tool by Moxie Marlinspike was originally developed to exploit this vulnerability.

From the SSLSniff page

 It is designed to MITM all SSL connections on a LAN and dynamically generates certs for the domains
 that are being accessed on the fly. The new certificates are constructed in a certificate chain that is
 signed by any certificate that you provide.

Attacking the bridge to HTTPS

Secure Connections in WWW

Pervasiveness of SSL/TLS: introducing https

Along with the widespread of e-commerce and sensitive applications served to users through the web, security of connections to preserve both integrity and confidentiality of data has become a critical feature that any ( at least money involved ) service provider should care about. For this reason, a standard for secure HTTP comunication has been stated in rfc2818 to describe the use of HTTP over SSL and its successor TLS. The resulting HTTPS protocol ( ”Hypertext Transfer Protocol over Secure Socket Layer” ) basically states that HTTP client is supposed to act as the TLS client and send all the HTTP data as TLS ”application data”.
The default mechanism to start this kind of interacion between client and server is a request for an URI that looks like “ https://domain.tld/[...] ” that is by default for a service on port 443. However, unless using bookmarks or typing the url itself ( with the ”https” protocol specified ), people surfing the web typically reach secure pages served with HTTPS through links or redirects ( eg. 302 HTTP Status Code ).

Positive feedbacks, negative feedbacks and trends

Mass culture suggested for long time users to look for indicators deployed to designate that a page is secure, as a positive feedbacks from the applications they use, such as icons displaying locks or comforting words upon login prompt s such as Secure Site, Protected against viruses!, in order to trust what trey are using. At the beginning, browsers attitude was to enforce this trend: when using HTTPS, Firefox URL bar turned gold, MS Internet Explorer showed a big lock image in the status bar, and so on. Neverthless, the most considered feedbacks were the ones embedded in the page and actually in plain HTTP protocol, most of these feedbacks may be emulated without any user awareness, example giving in a phishing contest or by a man in the middle who is modifying the traffic. This may be the reason why most browsers changed their trend and started giving less emphasis to positive feedbacks and more on alerting users to problems, if they occur. Nowadays, Firefox golden bar is gone, there are less locks around and users tipically assume applications to be trusted unless they are given really invasive error messages such as Firefox “Secure Connection Failed” or MS Internet Explorer “Website Security Certificate Problem” that actually block the navigation. Here we deliberately ignore the chance that the user stressed by issues that doesnʼt consider his own concern simply add an exception, even if this often take place, but we suppose he somehow cares about his service security. In this contest such a negative feedback force the user to avoid the use of his service because considered, maybe temporarily, untrusted. Negative feedbacks really capture the attention of the users at the point that now the absence of positive feedback is almost ignored. Clear evidence of this condition can be found in the trend of many web services that propose plain HTTP pages with forms that point to HTTPS target links or with frames carrying the sensitive data which are retrieved over https. Their source looks like :

 <form name="secure-form" method="POST" action="https://path/to/ secure/authpage.html”>...</form>

or

 <FRAME src="https://path/to/secure/page.html” marginHeight="0" marginWidth="0" noresize />

MITM without SSL/TLS between Target and Attacker

The problem of the (missing) positive feedback

As explained, in the actual trend the emphasis on positive feedbacks is minimal to the point that users trust their applications unless they get a negative one. This is particularly troublesome if an attacker can intercept and modify an unsecure connection that is supposed to lead to a secure one, because without positive feedback it will be hard for the user to be aware that the secure connection has really been established between its own machine and the server or not. Consider the problem of an HTML form that point to an action over HTTPS to send login credentials for some service. Since it is a form, the typical “Submit” element the user click on to submit the data is a button, so no target link get displayed in the browser status bar. The only way to know which is the form target action is look at the page code. Also consider the iframes retrieved over https and embedded in plain http pages. The user has no way to be sure that frame comes over a secure connection between his own machine and the server unless he looks at the actual code of the page his browser had just interpreted. Even ignoring that typical users never looks at their page code, popular browsers like Firefox actually perform another request if the user ask for the page code, so the code showed is not necessarily the same one that the browser interpreted to present the page.

The actual target of the attack that is going to be described is the bridge that from http leads to https. Since users mostly reach HTTPS pages throughout HTTP via direct links or redirects, the setup of the secure connection is decided based on data retrieved via HTTP, and since HTTP is not a secure protocol, an attacker can modify that data to avoid the establishing of the secure connection between the user and the server. Instead, acting as the man in the middle ( from now indicated as MITM ), the attacker can provide an unsecure connection to the user and then establishing himself the secure connection with the server. The core of the problem is that the user will not see the difference unless he doesnʼt look for positive feedbacks that cannot be emulated. However, in lots of cases such as frames with source over HTTPS but embedded in plain HTTP pages, there are no differences at all in the user experience with the service, because no positive feedbacks are provided both in the foreseen use-case and under this kind of attack. Also negative feedbacks are avoided, since there is no attempt to enstablish a secure connection that involve the user machine, thus there is no verification that can eventually fail.

SSLStrip

In the contest described an attack based on the concept of MITM results really effective. This kind of attack has been presented by Moxie Marlinspike at Black Hat DC 2009 Conference and Defcon 17 in August 2009. He also released a tool that realize the attack, that can be found at his page.

The attack imply the attacker to be able to perform a well known MITM attack. To simplify, suppose the attacker to be on the same unmonitored LAN of his victim and poisoning his victim ARP table to be in the middle between him and their gateway. The attacker then can use the SSLStrip tool to:

transparently hijack the victim traffic looking for HTTPS links or redirects
and mapping those into look-alike HTTP links keeping map of what is changed.

When the victim will eventually request one of the changed links, the attacker will proxy that request out as HTTPS to the server, and then the response will instead be forwarded to the victim in plain HTTP, since that was actually the protocol of the victim request.

The result of this kind of attack is that the server doesnʼt see any difference in the comunication from the client, even if actually itʼs connected with the MITM. The victim itself is not aware of what is going on because has no positive feedback of any secure connection and doesnʼt expect them, and because no error message is raised. The attacker on his side, achieve his goal because since his connection with the victim is simple http he can see and log all the victim’s traffic.
To improve the victim experience the attacker can also use the sslstrip options to provide addictional, emulated, positive feedbacks. Example giving, when an HTTPS link is mapped to an HTTP look-alike link and a favicon is requested, the tool in the middle can provide a cute lock icon to suggest the victim the site he is visiting is secure.

Limits and Countermeasures

From the attacker view, the main problem with this technique is that its scope is limited to situations in which victims exposes the bridge between HTTP and HTTPS, that is the actual point of the process that is attacked. That means requests for secure pages reached through bookmarks or by typing HTTPS links cannot be stripped, and also that other protocols such as imaps, smtps, pop3s, irc, that works over SSL but donʼt expose such a bridge are not vulnerable to this kind of attack.
Another limitation however, is that enlighted clients can figure out that their connections are not over SSL/TLS, by looking at the url for entire known-to-be over-https pages, or sniffing on their own interfaces rather than looking at the page source code in the contest of embedded frames or forms that should be pointed to https links but under attack are instead pointed to some other plain http link.

Countermeasures consists in avoiding to expose the bridge, explicitly requesting the secure connection. That means

• reach https (specially login) pages throughout bookmarks
• type the entire HTTPS url
• avoid relying on links or redirects

Also, when presented http pages that embed frames or form that pointed to https sources, possible countermeasures are

• look at that pages code to check the https source
• sniff your own traffic to be sure your connections are over SSL/TLS

Traceroute your lan gateway may also, as all the known methods to detect a MITM, indicate the presence of the attacker. Traceroute detection can be however avoided by the MITM, e.g. increasing the TTL of the incoming packets, in order to avoid them to expire on the machine but at least on the next hop.
Keep in mind anyway that, despite it’s a really common case, MITM is not effective only when between the victim and the lan gateway, but when in any point of the network path between the victim and the server where the traffic is not encapsulated inside other encrypted protocols ( eg. think about the attacker that gained the control of the lan gateway itself, or that is running an exit node of the Tor network ).

Also a firefox plugin called SSLPasswdWarning is available to provide a modal dialog when the user clicks on a password input field that will transmit insecurely over a non-HTTPS connection but it’s really annoying every time the user sends anything in a post form that is not over https.

MITM with SSL/TLS between Target and Attacker

What attackers would actually like to able to do, when performing a MITM attack, is establishing an SSL/TLS connection with the victim in such a way that the victim is convinced to be talking to the real server. But then the attacker should send a certificate, that will be checked by the victim to prove that the MITM is who claims to be, and he is not. Infact, MITM cannot send the real server certificate because it presents the server public key and the MITM of course has not the corresponding private key, so as soon as the victim starts encrypting messages, the MITM will not be able to decrypt them. So the MITM has to send another certificate, whose private key is known to him, but that the victim may acknowledge as the certificate for the requested subject.

Combination with Homograph Attacks

Homograph characters are characters that looks like other characters but are actually different.
Rather than register domain names that looks like the domain where a secure page reside to perform some kind of phishing, attackers can register domain names like fgh.je, than get a valid SSL Certificate for *.fgh.je, and then use the stripping technique to swap HTTPS links to links that looks like them, using for example the character “ ∕ “ that looks like a slash “ / “ but itʼs not. The difference between the fake character and the original one depends on the font used, so don’t look at this example considering how they look different when displayed here, but try to copy and paste the last sentence in your browser URL bar and look at it there. Example giving, consider the following URL

https://authentication.uniroma3.it/login.pl?action=login&destination=google.com

of which the only some first part is visible in the url bar of the browser, turning into

https://authentication.uniroma3.it∕login.pl?action=login&destination=google.com∕token=8YJ9Q.fgh.je

The difference is really hard to be noticed, and for the second URL the MITM can provide a real and valid SSL certificate since it is actually a subdomain of fgh.je and this swapping can be applied to url coming from different named domains. This way, the victim get an HTTPS page with a valid certificate, and will probably consider it trusted.

Anyway the link swapping technique still require the bridge between http and https to be exposed to perform an effective attack.

Countermeasures

Users should check that the subject of the valid certificate used to identify the source of critical pages is issued by the same subject they expect to be connected to. In the previous example infact, the certificate is valid, but it claims to be valid for ”*.fgh.je” and not for ”authentication.uniroma3.it”.

Demo

The demo realized for this attack is available on vimeo .

Validation of Malicious Certificates

CA business process in the past and today

Back to few years ago, the core process of CAs, as the identification of the subjects they were going to sign certificates for, was really different from today. That process used to involve lawyers, papers to be signed and that were checked by different people, real CA employee talking on the phone to verify contact information, and all other sorts of interaction between human beings to ensure the identity of the subject that was requesting the CA sign on his certificate. That implicitly made the data provided by the subject checked by the CA workers, so that when the subject identity was ensured, the signed certificate and its content could be treated as a trusted input.

Online Domain Validation process

Today things are changed. The core process of most CAs has turned into “online domain validation” . That basically means that, when a subject wants his certificate to be signed by a CA, he must provide a CSR to some web application on the CA website, that can be generated with a proper tool from his certificate. The Certificate Signing Request is a data structure defined by Public Key Cryptographic Standards #10, rfc.2986, that contains among other details, the subject who is requesting the sign on the certificate and his public key. The value of this field of the CSR is exactly the same that CAs will later include in the signed certificate as subject. The CA process proceed looking at the root domain of the subject included into the CSR, then performing a WHOIS lookup on that, to verify the contact information by mail or phone call. With this purpose, they totally ignore the subdomain requested, just consider the root domain that is extracted with an automated process. The subject by the way, is not actually just a string but it is a data structure itself, called Distinguished Name ( since now called DN ), defined in the X.509 standard.

The ”messy” standard problem

The X.509 standard however seems to be a real mess to deal with, because when revised was published with some unclear passages that were then corrected, but not before some implementations implemented the corrupted version of the standard. Also parts of the standard seems to had been literally lost, then found again. Since these episodes are quite known, developers know the standard says something, but then there were episodes about which everyone has his own idea, so then implementations behave in uncertain way when checking the data structures for validation.
Anyway, the idea of the standard was that DN would fit into some ”Global Information Tree”. In practice, due to the standard unclear definitions, everyone treat this structure differently and the Global information Tree never materialized. When filling the DN fields, people follow their common sense: ”Country” suggest to insert the two capital letter of their own country, as well as State, Locale, Organization and Organization Unit and Common name, that convention wants to be filled with the domain name the requesting subject wish to have his certificate signed for. Since the standard is not clear, implementations often don’t check at all what people insert in these fields.

 There is nothing in any of these standards that would prevent me from including 1 gigabit
 MPEG movie of me playing with my cat as one of the RDN components of the DN in my certificate
                                                  -- Bob Jueneman on IETF-PKIX

Null-prefix attack

Background

Since the Global Information Tree never materialized, the CA software often just ignore everything except for the Common Name. In the DN Data structure the Common Name is represented as a sequence of character followed by one of the String Types supported. The most common String Type we can imagine is an ASCII String, which is basically the US implementation of the IA5 String ( International Reference Alphabet No.5 ). IA5 Strings are represented with one byte (0×16) that indicates the string type, then one byte length field that indicates the actual length of the string, then finally the actual value of the string, one byte per character.
Eg. “uniroma3.it” looks like:

 0x16 0x11 0x75 0x6E 0x69 0x72 0x6F 0x6D 0x61 0x33 0x2E 0x69 0x74

The CN are essentially represented the same way Pascal strings were, with the length that precede the values of characters. That is really different from how C strings are represented. In C, to which most implementations belong, the reference to the string is an actual pointer to the first character of the string, and to know its length, a program should walk through the string itself until it encounter a null character. In Pascal-like strings however, a null character has no special meaning, but it’s just a common character like the others.

First Hint

Since CA software doesn’t care about subdomains because the standard does not impose any constraints on that, but just extract the root domain from the CN in order to perform the WHOIS lookup and extract contact information, nothing prevents the attacker owner of verybadguy.org to request certificates for i.can.put.whatever.in.here.verybadguy.org or even uniroma3.it\0.verybadguy.org ( where ‘\0′ is a null character ) , and no one will care about that because the extraction of the root domain is an automated process. The software will always end up to extract verybadguy.org, will perform the WHOIS lookup and will probably contact admin@verybadguy.org to confirm contact informations.

Once achieved in having his certificate signed for uniroma3.it\0.verybadguy.org the attacker can now perform a MITM attack intercepting secure connections to uniroma3.it and presenting the signed certificate when performing the handshake. The victim’s client, e.g. a web browser, will first check the subject, comparing the string of the requested url with the subject on the certificate. The comparison may take place this way:

char* url = getRequestedUrl();
char* commonName = getCertificateCn();
bool areEquals = (strcmp(url,commonName)==0);

Strcmp, testing uniroma3.it\0 against uniroma3.it\0.verybadguy.org will walk throughout the strings comparing characters by characters the two with the same index, until a null character occurs. If the null character is also matching, to the strcmp function, the two strings are equals. Proceeding, the victim’s client will verify the signatures and the integrity of the certificates chain, and since the certificate presented by the attacker is authentic, it will be considered by most implementations of the victim’s client completely valid for uniroma3.it.

When under this kind of attack, there is no difference in the user experience at all. Also if the victim inspect the certificate it will claim to be valid for uniroma3.it because the browser will display the C string ignoring anything after the null character ” \0 “.

Wildcard certificates

The kind of attack described seems deadly but the attacker need to register a different certificate for each domain where secure pages of its interest resides. What the attacker would actually prefer to be able to do is MITM an entire network and get everything that pass through. Luckily, some implementations supports wildcards in the subject string because eventually some CA signs certificates for a subject and all of its subdomains, so the attacker can register *\0.verybadguy.org and that will match anything.

From one of  Moxie Marlinspike speeches:

This is actually better than having a CA cert, because if you have a CA cert
you have to create another certificate and sign it to present it to someone.
If you have this thing you can just send the same thing over and over for everything

Some implementations also support grouping, so if the attacker doesn’t want to spend money for a wildcard certificate whose price is higher than a group one, he can register e.g.

(uniroma3.it|uniroma2.it|uniroma1.it|unisi.it|polimi.it|polito.it)\0.verybadguy.org

Buffer Overflow Vulnerability

To support grouping, some implementation may allocate a buffer based on the CN string length, that strlen compute from the beginning to the null character. Then they may parse the string, passes the opening bracket and keep walking on the string looking for the closing bracket that may be after the null character, ignoring anything else but incrementing a counter. Then when they find the closing bracket, copy the counter-length string they assume to be the group substring into the buffer they allocated with the length of the string till the null character, overflowing the buffer.

E.g. when the CN:

(whatever|\0 shellcode-here ).verybadguy.org

is parsed, the buffer is allocated based on the length of the substring till the null character, but then the whole string inside the brackets is copied inside.
This vulnerability has been presented by Moxie Marlinspike at Defcon 17 conference in August 2009 against Mozilla NSS code, that should be (hopefully) fixed now.

OCSP Attack

Once the attacker has registered a null-termination or wildcard certificate, it will be unfortunately to him if that certificate gets revoked.

The task to find out whether a certificate has been revoked or not mat be achieved in 2 ways:

• Consulting a Certificate Revocation List
• Using the OCSP (Online Certificate Status Protocol)

Since CRL may be huge and their updates may use considerable bandwidth, OCSP is preferred as the default behaviour of most clients. The protocol itself is really simple: whenever an SSL/TLS stack sees a new certificate it never saw before in the running session, it perform a quick request to the OCSP Provider url that the signing CA embedded in the certificate. Then the SSL/TLS stack receives a signed response from the OCSP Provider that says whether the certificate has been revoked or not.

Actually, the OCSP Response is a sequence of a Response Status byte and, depending on the Response Status, the actual Response Bytes data, which is a data structure itself composed by the Response Type code and the actual Response, that again is a structure whose interesting part is the Response Data that is signed, and is so followed by the Signature Algorithm code and by the Signature itself.

Being the MITM, the attacker can drop the OCSP Request and forge an ad-hoc response to confirm the certificate he presented is still valid, but then he should sign the OCSP Response Data, and he can not because doesn’t know the OCSP Provider private key. But looking at the standard, the signature over the OCSP Response Data does not even cover even the Response Status, but just some of the Response Data bytes. And depending on the Response Status, the Response Bytes may be actually optional.

Possible Response Status are:

• 0 – Successful ( the certificate is still valid, ”Response Data” is attached )
• 1 – Malformed Request
• 2 – Internal Error
• 3 – Try Later
• 4 – ( Not Used )
• 5 – Require Signed Request
• 6 – Unauthorized Request

Response Data and its signature is required for successful Response Code. Also Malformed Request and Internal Error don’t sounds as a good confirmation of the certificate validity to the SSL/TLS stacks. But then the Try Later Response status suggest maybe the OCSP Provided is under big load, and maybe the certificate in the OCSP Request is actually valid, but the confirm may arrive in a second time. It turns out that most SSL/TLS implementations are just fine with that. And the Try Later Response Status does not require signed Response Data. So what the attacker has to do as the MITM in order to confirm his certificate validity, defeating the entire standard described in the rfc2560 is just dropping the OCSP Request and send back, spoofing the OCSP Provider, the 0×33 byte, as the Response Status code 3.

An entire standard, the whole OCSP thing, can be defeated, by the number 3
-- Moxie Marlinspike

Software Updates Injection

Along with the growing of complexity in software, the increasing number of chance for bugs and mistakes leads to the need for self-updating platforms in order to fix problems quickly. The idea behind self-updates is that software should connect to some server, declaring its name, version and details, and then if are there updates available, download and run them. This means connections to the update servers really should be managed to be trusted. But actually, what most software does is just rely on SSL/TLS.

As a case of study, when installing e.g. Mozilla products, they come with automatic update services enabled by default. And that service works establishing an SSL/TLS connection with an update server, then if are there updates for the given client and version, download an unsigned bunch of data to install, that comes in the form of a binary diff or of a brand new binary image of the software. Moreover, by default Minor Updates, classified by the update server, are downloaded and installed silently, prompting the user for restart only when everyhing is done. That means if SSL/TLS may be defeated e.g. with one of the discussed attacks, and if victim uses self-updating software when connected to untrusted networks, an attacker can install and run anything on the victim machine, from rootkits to keyloogers passing through inserting some certificates in the victim’s browser root CA list.

SSLSniff

SSLSniff that was originally developed to demonstrate and exploit the missing check of  X509 basic constraints vulnerability, has been updated post disclosure of the null prefix attacks, to support the null-prefix attacks and to deny the OCSP.

From SSLSniff page:

These allow for completely silent MITM attacks against SSL/TLS in the NSS, Microsoft CryptoAPI,
and GnuTLS stacks, ultimately allowing for SSL communication in Firefox, Internet Explorer,
Chrome, Thunderbird, Outlook, Evolution, Pidgin, AIM, irssi, and every other client that
uses the Microsoft CryptoAPI to be intercepted.

It works watching network, fingerprinting clients for level of vulnerability, intercepting connections of vulnerable clients, presenting a null-termination certificate if available among the set that the attacker provided to the tool, or a wildcard certificate if the SSL implementation of the specific client is vulnerable, leaving alone non-vulnerable clients to avoid detection.

Moreover, SSLSniff watch for OCSP requests, and if their subject match a domain for which a null-termination or wildcard certificate had been presented, it drops the request and spoofing the OCSP provider whose link is embedded in the presented certificate, sends back an OCSP Response with the single Response Status byte 0×33 to represent the code “3″, that means “Try Later”, and is accepted by SSL implementation that then assume the certificate has not been revoked.

Also it may be loaded with proper options to watch for software updates requests, intercepting their SSL/TLS communications and sending back a given, eventually binary, payload as part of the specified platform update response, so that the victim software will run it.

Sources & See also

TLS on Wikipedia
IETF – RFC5246
Moxie Marlinspike – Thoughtcrime.org
SSLSniff Page
SSLStrip Page
Moxie Marlinspike – Null Prefix Attack Paper
Moxie Marlinspike – OCSP Attack Paper

Credits

Mostly based on research by Moxie Marlinspike
and his presentations from DEF CON and Black Hat conferences.