Hi Guys,
I’m just posting my notes and slides from my flash talk last night at the Linux Society, it seemed to go well. It maybe better for me to explain what the Linux Society flash talk nights are all about. The basic concept is that is that three to four speakers volunteer to do a small 10 minute talk on any subject they wish. The aim is that the member’s of the Linux Society get to hear about three or four new things that they may never have heard about before.
I volunteered to talk about Moxie Marlinspike’s Null Prefix Attack, in defeating SSL/TLS. It was a little tight to get it squeezed into 10 minutes. I’ve posted my notes and my slides from the talk, as for those there i had to cover a lot of ground very fast. It maybe of some interest to someone out there. Someone was videoing the talks, and i also recorded the audio for HackerPublicRadio.Org so i’ll let you guys know.
My Notes From The Talks: – ** indicates change of slide
Moxie Marlinspike’s Null Prefix Attack – Deafening SSL/TLS
Linux Society Flash Talk
19th September 2009
By Arron Finnon
Good evening ladies and gentleman, my name is Arron Finnon and I will be talking to you this evening about Moxie Marlinspike’s Null Prefix Attack. Ever since I first heard about this attack I have been fascinated by it. I was also lucky enough to interview the security researcher who discovered this particular attack.
**
The talk should outline and you should hope to know the following by the end;
What is the Null Prefix Attack
What are SSL Implementations
What is Online Domain Validation
The process used in Certificate requests and revocations
What a Universal Wild Card Cert is
And how OCSP was defeated
**
My intro
So tonights aim is for me to give you a crash course in this particular attack, and the vulnerability it exploits its only suppose to wet your appetite. I will give you a couple of web addresses and suggestions at the end if you want to know more. This one is going to be a tight squeeze to fit it in to 10 minutes, I have a lot of ground to cover in very little time but I think I should just about do it.
**
So in short tonights talk focuses on an implementation vulnerability in the secure protocol SSL/TLS, which was left unpatched on some operating systems for well over 10 weeks. At its heart the null prefix attack had the potential ability for an attacker to intercept and decrypted secure browser traffic, reading usernames and passwords entered for sites such as paypal, gmail, facebook without them or their users knowing. SSL/TLS had been effectively broken not just in browsers, but in vast arrays of software that is dependent on SSL/TLS implementations. All though this attack has predominately been patched i’m not going to imply that there still isn’t a real world threat from this, however its more than likely that this threat will fade away over time.
In October 2009 nearly 2% of Firefox users where running a vulnerable version of Firefox, which may not sound like a big number, but when you look at Firefox having a 47% market share for that same month it starts to become a vast number. In addition most of Microsoft’s product range where vulnerable during the first half of October too. In fact Microsoft took an astonishing 10 weeks to fix the problem.
**
In laying the ground work I want to very quick touch on what TLS and its predecessor SSL is, and where it is in common use today. However it is not my aim for this to be a definitive guide, but just a reference, if you decide to find out more about SSL/TLS there is a lot of content about it available.
In short Transport Layer Security or TLS and Secure Socket Layer or SSL, are a cryptographic protocols, who’s aim is to provide security for communications over networks such as the Internet. The protocols are in widespread use in applications such as web browsers, email, instant messaging, VoIP, and some VPN’s. TLS is based on the earlier SSL specifications developed by Netscape Corporation.
TLS allows client/server programs to communicate over networks in method that makes eavesdropping, data tampering and message forgery hard to accomplish. In a typical deployment such as a web browser, TLS authentication is unilateral: which means that only the server is authenticated. The client knows the server’s identity, the client remains unauthenticated
So a simple TLS handshake where the server is authenticated by its certificate would work like so;
**
A negotiation phase would start with a client sending a ClientHello message, in that message the client will inform the server of the TLS protocol versions it supports, a random number, list of preferred cyphers and compression methods.
The server then responds with a ServerHello message, and within that message the chosen TLS protocol version, a random number, and the selected cypher suite and compression method. It may also contain a session ID to preform resumed handshakes. The server will then send a certificate message, followed by a ServerHelloDone, indicating that the negotiation phase has finished.
The client then responds with a ClientKeyExchange message, which contains a PreMasterSecret and a public key. Both the client and the server use the random numbers from the negotiation phase, and the PreMasterSecret to compute a common “master secret”. Key Data for this connection will be derived from the master secret and the random numbers generated earlier, which is passed through a pseudo-random function which has been carefully designed.
The client will then send a ChangeCipherSpec record informing the server that all communication will be authenticated. The client will then follow this up with an authenticated and encrypted Finished Message which contains the hash of the previous handshake message. The server will try and decrypt the client’s Finished message and match the Hash, if the server fails to verify the hash then the handshake will be considered failed and the connection torn down. The server will follow up by sending a ChangeSipherSpec to the client, informing the client that everything now passed to you from me will be authenticated, and a Finished Message encrypted with the hash of the previous message, the client will then attempt to decrypt and verify.
**
The certificates that are generally used in browsers is the X.509 type, and its a crucial part to how the null prefix attack is implemented. The X.509 is a standard for public key infrastructure also known as PKI, it has standard formats for public key certificates and, certificate revocation lists.
X.509 was initially issued on July the 3rd, 1988 and was in association with the X.500 standard. It assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. In the X.509 system, a CA issues a certificate binding a public key to a particular Distinguished Name as was before in the X.500 tradition, however it can also be to an Alternative Name such as an e-mail address or a DNS-entry. Browsers such as Internet Explorer, Netscape/Mozilla, Opera and Safari come with root certificates pre-installed, so SSL certificates from larger vendors will work instantly; in effect the browsers’ developers determine which CAs are trusted third parties for the browsers’ users. Although these root certificates can be removed or disabled, users rarely do so. X.509 as I have also mentioned includes standards for certificate revocation list (CRL) implementations. The IETF-approved way of checking a certificate’s validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default.
Defeating OCSP is also a key aspect of this attack, however I will discuss it a little later
**
If we look at the X.509 structure for a digital certificate, it is as follows;
**
Now for the SSL/TLS protocol it is “common name” field within the Subject field that is used to identify servers presenting certificates over the Internet. So when paypal request a certificate they will list www.paypal.com, if ebay request a certificate they will list www.ebay.com, and of course if I where requesting a certificate then I would list www.finux.co.uk.
When requesting a Certificate Signing Request to a Certificate Authority also known as a CA, the request is validated by establishing ownership of the domain. This can be as simple as checking the WHOIS database of the root domain and sending an confirmation email to the details listed. So in our example the CA would look up the root domain for www.ebay.com, which of course is ebay.com, and we would find the administration email is host...@ebay.com. Confirmation request is sent to them informing them that a request for a certificate has been made and could they please confirm the request.
Only the root domain is looked up and everything else is ignored by the CA, its an automated process. So we can register anything in the common name in the subject field and only the root domain is checked and validated, so we could request foobar.finux.co.uk, certificate.authorities.suck.finux.co.uk, even this.subdomain.is.fictional.finux.co.uk and all CA would see and validate is finux.co.uk.
It is at this point that the attack begins to take place. X509 certificates are formatted using ASN.1 notation, which supports lots of different string types. However all of them are represented in some variation of PASCAL. When in memory PASCAL strings are represented by a series of bytes, specifiying the length of the string, and then the string data. One character per byte. It is very important to pay attention to this being very different to how C reads a string, which is a series of bytes, one character per byte terminated by a single NULL character. In PASCAL NULL characters have no special meaning.
So we could be free to request www.paypal.com\0.finux.co.uk and the verification will be sent to finux.co.uk.
As we have earlier discussed with CA’s they tend to ignore everything before the root domain, and we are free to insert a NULL Character with in our request the NULL character has no special meaning in PASCAL.
However most modern SSL/TLS implementation will view the data from an X.509 certificate as an ordinary C string, using standard functions for comparisons and manipulation. One of the consequences of this is if we take our issued certificate with www.paypal.com\0.finux.co.uk in the CN field, in C the termination will happen at the Null Character, so when we go to verify that the trusted CA cert used to identify www.paypal.com it will compare only the www.paypal.com part of our CN. This enables us amongst other things to deploy a man in the middle attack, and present to the client a valid signed cert by a CA, which will compare to to the site we’re eavesdropping on.
It is here where authenticity of SSL/TLS is defeated.
However the story really doesn’t end here, as I mentioned previously we still have the issues of Online Certificate Status Protocol to worry about, it was designed to be quick and effective way of revocation to CA signed certificates. So it would be easy for the CA to check its records and find certificates that contained NULL characters.
OCSP was designed to support a light weight requests from the clients who have been presented with a certificate that they haven’t seen before, or recently. Within each CA signed certificate is an OSCP url for the issuer, which browsers like firefox will quickly check before accepting the certificate.
This could be fatal when deploying a Null Prefix Certificate in a MiTM (Man in The Middle) attack, if the CA has revoked our certificate.
However Moxie Marlinspike who discovered the Null Prefix Attack, also managed to defeat OCSP with similar easy. It is not far to say this whole protocol has been defeated by one single byte
After studying the response codes, Moxie has noticed that the code 3 which informed the browser to check the OCSP URL later did not generate any negative indicators on the browsers, and would continue. During that he discovered that ResponseByte structure had a signature from the CA which would be hard to forge, but that signature only covered ResponseData which is an optional. It however doesn’t cover the ResponseStatus.
Enumeration of the OCSPResponseStatus followed;
**
successful (0)
malformedRequest (1)
internalError (2)
tryLater (3)
sigRequired(5)
unauthorised (6)
Successful response would be hard to sign the subsequent ResponseData, however malformedRequests’s, internalError, sigRequired, unauthorised, and tryLater do not. Then OCSP requests can be watched for during our MiTM attack, and an appropriate 3 will be supplied. Meaning the browser never actually gets to check the validity of the certificate.
**
OCSP Defeated by the Number 3
**
I’m going to pick on firefox for little moment here, I must admit they react well and in a timely manner. NSS the library firefox uses was vulnerable to two other attacks that splinted off the null prefix attack.
It is possible to request a universal wild card for your domain, it costs a little extra. The idea is that a domain like google would only need to manage on cert, so they could request something like *.google.com. The way that NSS varified wildcards enabled Moxie to request from the CA’s and was issued an X509 cert for the common name;
*.\0.thoughtcrime.org
Firefox would then check this and validate any site with it. So the same certificate could be used to catch, gmail, facebook, paypal, ebay, amazon just to name a few. This was named a Universal Wild Card Certificate as you only needed one to intercept anything on Firefox.
**
Which then led to probably the most scary part of this attack as a platform. Think of a piece of software on your system, that contacts a server out on the Internet, this server will tell it to download an unsigned data blob and run it, conducted over SSL/TLS. I have described to you the process of auto-updates on firefox, which is turned on by default. The same process is also used for firefox addon-s.
We could in theroy upgrade the vulnerable firefox, to a non-vulnerable version of firefox, of course embedding our own root CA certificate. We could also bind it with a number of other nasty surprises such as boot and rootkits keyloggers, or something crazy like wubi.exe install for windows.
**
I think it important to mention here that the tools for preforming these attacks are released under the GPL Version 3, and you are free to download and examine the code. It is available from Moxie’s website www.thoughtcrime.org in the Software Section
Sslsniff has been updated to support Null Prefix Certificates, including the universal wildcard certificate, OCSP Denial, Firefox Auto-Update hijacking. I managed to get it working on Ubuntu 8.10 I haven’t tried it on anything other than 9.10. Your free to try it on any platform.
**
SCREEN SHOTS
**
So in closing tonight I hope that I have demonstrated how the Null Prefix Attack is deployed, enlightened you to potential targets for attackers with this attack, potential payloads that can be deployed, OCSP being defeated, and software that you can try at home.
Any Questions
End of Notes
Slides Available
Here – PDF
Here – PPT
Here – ODP
As i have said when the audio and video are available from the flash talk then i’ll post
Finux
Moxie Marlinspike’s Null Prefix Attack – Deafening SSL/TLS
Linux Society Flash Talk
19th September 2009
By Arron Finnon
Good evening ladies and gentleman, my name is Arron Finnon and I will be talking to you this evening about Moxie Marlinspike’s Null Prefix Attack. Ever since I first heard about this attack I have been fascinated by it. I was also lucky enough to interview the security researcher who discovered this particular attack.
**
The talk should outline and you should hope to know the following by the end;
What is the Null Prefix Attack
What are SSL Implementations
What is Online Domain Validation
The process used in Certificate requests and revocations
What a Universal Wild Card Cert is
And how OCSP was defeated
**
My intro
So tonights aim is for me to give you a crash course in this particular attack, and the vulnerability it exploits its only suppose to wet your appetite. I will give you a couple of web addresses and suggestions at the end if you want to know more. This one is going to be a tight squeeze to fit it in to 10 minutes, I have a lot of ground to cover in very little time but I think I should just about do it.
**
So in short tonights talk focuses on an implementation vulnerability in the secure protocol SSL/TLS, which was left unpatched on some operating systems for well over 10 weeks. At its heart the null prefix attack had the potential ability for an attacker to intercept and decrypted secure browser traffic, reading usernames and passwords entered for sites such as paypal, gmail, facebook without them or their users knowing. SSL/TLS had been effectively broken not just in browsers, but in vast arrays of software that is dependent on SSL/TLS implementations. All though this attack has predominately been patched i’m not going to imply that there still isn’t a real world threat from this, however its more than likely that this threat will fade away over time.
In October 2009 nearly 2% of Firefox users where running a vulnerable version of Firefox, which may not sound like a big number, but when you look at Firefox having a 47% market share for that same month it starts to become a vast number. In addition most of Microsoft’s product range where vulnerable during the first half of October too. In fact Microsoft took an astonishing 10 weeks to fix the problem.
**
In laying the ground work I want to very quick touch on what TLS and its predecessor SSL is, and where it is in common use today. However it is not my aim for this to be a definitive guide, but just a referencer, if you decide to find out more about SSL/TLS there is a lot of content about it available.
In short Transport Layer Security or TLS and Secure Socket Layer or SSL, are a cryptographic protocols, who’s aim is to provide security for communications over networks such as the Internet. The protocols are in widespread use in applications such as web browsers, email, instant messaging, VoIP, and some VPN’s. TLS is based on the earlier SSL specifications developed by Netscape Corporation.
TLS allows client/server programs to communicate over networks in method that makes eavesdropping, data tampering and message forgery hard to accomplish. In a typical deployment such as a web browser, TLS authentication is unilateral: which means that only the server is authenticated. The client knows the server’s identity, the client remains unauthenticated
So a simple TLS handshake where the server is authenticated by its certificate would work like so;
**
A negotiation phase would start with a client sending a ClientHello message, in that message the client will inform the server of the TLS protocol versions it supports, a random number, list of preferred cyphers and compression methods.
The server then responds with a ServerHello message, and within that message the chosen TLS protocol version, a random number, and the selected cypher suite and compression method. It may also contain a session ID to preform resumed handshakes. The server will then send a certificate message, followed by a ServerHelloDone, indicating that the negotiation phase has finished.
The client then responds with a ClientKeyExchange message, which contains a PreMasterSecret and a public key. Both the client and the server use the random numbers from the negotiation phase, and the PreMasterSecret to compute a common “master secret”. Key Data for this connection will be derived from the master secret and the random numbers generated earlier, which is passed through a pseudo-random function which has been carefully designed.
The client will then send a ChangeCipherSpec record informing the server that all communication will be authenticated. The client will then follow this up with an authenticated and encrypted Finished Message which contains the hash of the previous handshake message. The server will try and decrypt the client’s Finished message and match the Hash, if the server fails to verify the hash then the handshake will be considered failed and the connection torn down. The server will follow up by sending a ChangeSipherSpec to the client, informing the client that everything now passed to you from me will be authenticated, and a Finished Message encrypted with the hash of the previous message, the client will then attempt to decrypt and verify.
**
The certificates that are generally used in browsers is the X.509 type, and its a crucial part to how the null prefix attack is implemented. The X.509 is a standard for public key infrastructure also known as PKI, it has standard formats for public key certificates and, certificate revocation lists.
X.509 was initially issued on July the 3rd, 1988 and was in association with the X.500 standard. It assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. In the X.509 system, a CA issues a certificate binding a public key to a particular Distinguished Name as was before in the X.500 tradition, however it can also be to an Alternative Name such as an e-mail address or a DNS-entry. Browsers such as Internet Explorer, Netscape/Mozilla, Opera and Safari come with root certificates pre-installed, so SSL certificates from larger vendors will work instantly; in effect the browsers’ developers determine which CAs are trusted third parties for the browsers’ users. Although these root certificates can be removed or disabled, users rarely do so. X.509 as I have also mentioned includes standards for certificate revocation list (CRL) implementations. The IETF-approved way of checking a certificate’s validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default.
Defeating OCSP is also a key aspect of this attack, however I will discuss it a little later
**
If we look at the X.509 structure for a digital certificate, it is as follows;
**
Now for the SSL/TLS protocol it is “common name” field within the Subject field that is used to identify servers presenting certificates over the Internet. So when paypal request a certificate they will list www.paypal.com, if ebay request a certificate they will list www.ebay.com, and of course if I where requesting a certificate then I would list www.finux.co.uk.
When requesting a Certificate Signing Request to a Certificate Authority also known as a CA, the request is validated by establishing ownership of the domain. This can be as simple as checking the WHOIS database of the root domain and sending an confirmation email to the details listed. So in our example the CA would look up the root domain for www.ebay.com, which of course is ebay.com, and we would find the administration email is host...@ebay.com. Confirmation request is sent to them informing them that a request for a certificate has been made and could they please confirm the request.
Only the root domain is looked up and everything else is ignored by the CA, its an automated process. So we can register anything in the common name in the subject field and only the root domain is checked and validated, so we could request foobar.finux.co.uk, certificate.authorities.suck.finux.co.uk, even this.subdomain.is.fictional.finux.co.uk and all CA would see and validate is finux.co.uk.
It is at this point that the attack begins to take place. X509 certificates are formatted using ASN.1 notation, which supports lots of different string types. However all of them are represented in some variation of PASCAL. When in memory PASCAL strings are represented by a series of bytes, specifiying the length of the string, and then the string data. One character per byte. It is very important to pay attention to this being very different to how C reads a string, which is a series of bytes, one character per byte terminated by a single NULL character. In PASCAL NULL characters have no special meaning.
So we could be free to request www.paypal.com\0.finux.co.uk and the verification will be sent to finux.co.uk.
As we have earlier discussed with CA’s they tend to ignore everything before the root domain, and we are free to insert a NULL Character with in our request the NULL character has no special meaning in PASCAL.
However most modern SSL/TLS implementation will view the data from an X.509 certificate as an ordinary C string, using standard functions for comparisons and manipulation. One of the consequences of this is if we take our issued certificate with www.paypal.com\0.finux.co.uk in the CN field, in C the termination will happen at the Null Character, so when we go to verify that the trusted CA cert used to identify www.paypal.com it will compare only the www.paypal.com part of our CN. This enables us amongst other things to deploy a man in the middle attack, and present to the client a valid signed cert by a CA, which will compare to to the site we’re eavesdropping on.
It is here where authenticity of SSL/TLS is defeated.
However the story really doesn’t end here, as I mentioned previously we still have the issues of Online Certificate Status Protocol to worry about, it was designed to be quick and effective way of revocation to CA signed certificates. So it would be easy for the CA to check its records and find certificates that contained NULL characters.
OCSP was designed to support a light weight requests from the clients who have been presented with a certificate that they haven’t seen before, or recently. Within each CA signed certificate is an OSCP url for the issuer, which browsers like firefox will quickly check before accepting the certificate.
This could be fatal when deploying a Null Prefix Certificate in a MiTM (Man in The Middle) attack, if the CA has revoked our certificate.
However Moxie Marlinspike who discovered the Null Prefix Attack, also managed to defeat OCSP with similar easy. It is not far to say this whole protocol has been defeated by one single byte
After studying the response codes, Moxie has noticed that the code 3 which informed the browser to check the OCSP URL later did not generate any negative indicators on the browsers, and would continue. During that he discovered that ResponseByte structure had a signature from the CA which would be hard to forge, but that signature only covered ResponseData which is an optional. It however doesn’t cover the ResponseStatus.
Enumeration of the OCSPResponseStatus followed;
**
successful (0)
malformedRequest (1)
internalError (2)
tryLater (3)
sigRequired(5)
unauthorised (6)
Successful response would be hard to sign the subsequent ResponseData, however malformedRequests’s, internalError, sigRequired, unauthorised, and tryLater do not. Then OCSP requests can be watched for during our MiTM attack, and an appropriate 3 will be supplied. Meaning the browser never actually gets to check the validity of the certificate.
**
OCSP Defeated by the Number 3
**
I’m going to pick on firefox for little moment here, I must admit they react well and in a timely manner. NSS the library firefox uses was vulnerable to two other attacks that splinted off the null prefix attack.
It is possible to request a universal wild card for your domain, it costs a little extra. The idea is that a domain like google would only need to manage on cert, so they could request something like *.google.com. The way that NSS varified wildcards enabled Moxie to request from the CA’s and was issued an X509 cert for the common name;
*.\0.thoughtcrime.org
Firefox would then check this and validate any site with it. So the same certificate could be used to catch, gmail, facebook, paypal, ebay, amazon just to name a few. This was named a Universal Wild Card Certificate as you only needed one to intercept anything on Firefox.
**
Which then led to probably the most scary part of this attack as a platform. Think of a piece of software on your system, that contacts a server out on the Internet, this server will tell it to download an unsigned data blob and run it, conducted over SSL/TLS. I have described to you the process of auto-updates on firefox, which is turned on by default. The same process is also used for firefox addon-s.
We could in theroy upgrade the vulnerable firefox, to a non-vulnerable version of firefox, of course embedding our own root CA certificate. We could also bind it with a number of other nasty surprises such as boot and rootkits keyloggers, or something crazy like wubi.exe install for windows.
**
I think it important to mention here that the tools for preforming these attacks are released under the GPL Version 3, and you are free to download and examine the code. It is available from Moxie’s website www.thoughtcrime.org in the Software Section
Sslsniff has been updated to support Null Prefix Certificates, including the universal wildcard certificate, OCSP Denial, Firefox Auto-Update hijacking. I managed to get it working on Ubuntu 8.10 I haven’t tried it on anything other than 9.10. Your free to try it on any platform.
**
SCREEN SHOTS
**
So in closing tonight I hope that I have demonstrated how the Null Prefix Attack is deployed, enlightened you to potential targets for attackers with this attack, potential payloads that can be deployed, OCSP being defeated, and software that you can try at home.
Any Questions