My recent talk at thelinuxsociety.org.uk on Moxie Marlinspike’s Null Prefix Attack, used in defeating SSL/TLS.  Has been released on HPR.  You can find the Notes and Slides that accompany the talk here

A .mp3 version of the talk can be found here

Finux

Note Added 10/12/09

Video (.avi) of the talk can be downloaded here

Howdie Guys,

Hope everyone had a good weekend, and sorry this post is a little late. As some of you may know I twitter’ed last week that I was going to the Open Source Awards 2009 on Friday (20^th). I’ve been meaning to go since they started a few years ago, I also received an email saying that I had been nominated for an award, and I had been short list. It had surprised me somewhat, a pleasant shock, and I dutifully made plans to go along to the awards night.

It was being held in Edinburgh University new School of Informatics building, which I remember was in the beginning stages of getting built the last time I was in the part of Edinburgh for DebConf a couple of years previous. The building looked magnificent and was full to the brims with a mix of familiar faces, and other patrons of Free and Open Source Software.

As I had twitter’ed before I was very flattered to have been nominated and short listed, however I didn’t think I was in for much of a shout. The award I was nominated for was SICSA (Scottish Informatics and Computer Science Alliance) Student Award. I wasn’t given too much detail about it really, but its connected to a user group at university that I help set up, and was the president of. I did the job for three years and I learned a lot about Linux and Free and Open Source Software. Anyone that has listened to any of my shows at HackerPublicRadio.Org will know that i’m very passionate about Free and Open Source Software. The Linux Society has grown a lot in three years, and i’m very proud to have been a part of that.

So it was a very enjoyable evening, and I must say a good spread of foods and beers where supplied and enjoyed, a great compère Sam Collins from Techmeetup, and giving the keynote the legend that is Ian Ritchie, as a self confessed geek it was an awesome night. The night was topped off by them reading my name out for the award. It completely took me by surprise and I was left speechless for quite sometime. Its a lovely honour and i’m very proud, I was awarded it for “Exemplary advocacy of Open Source software”. I find it still a little hard to accept that they gave me an award for talking about something that I find easy to talk about. Free and Open Source software makes sense to me, I believe that arguments about certain software companies having monopolies is a tad dated, I prefer to engage using scalability, reliability, affordability, usability that free and open source software provides its users with, when I talk about it. So really I think now would be the time that I thank all the Free and Open Source Software developers and users, like yourselves for making it easy for people like me to talk passionately about it.

So i’ve done the shameless blog post about it, which I have dreaded doing but at least its out the way.

I leave you with this joke, which I thank Ian Ritchie for;

Q. How many Software Developers to it take to change a light bulb?

A. None, its a Hardware problem!

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;

• Certificate

  • Version

  • Serial Number

  • Algorithm ID

  • Issuer

  • Validity

    • Not Before

    • Not After

  • Subject

  • Subject Public Key Info

    • Public Key Algorithm

    • Subject Public Key

  • Issuer Unique Identifier (Optional)

  • Subject Unique Identifier (Optional)

  • Extensions (Optional)

    • …

• Certificate Signature Algorithm

• Certificate Signature

**

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

Well sorry dude’s to blog spam once again, however I’m playing catch up and i have had two shows out on HackerPublicRadio.Org recently.  Well when i say i have had two that’s not quite true.  Robert Ladyman from File-Away Ltd, recently gave a fantastic and insightful talk at this years Software Freedom Day Dundee 2009.  Robert’s use of Free and Open Source Software, in the business environment has given him an expertise which lucky enough he agreed to share with us.

The talk is aimed at everyone, and is not one of technical spiel but of good advice.  I recommend if you did not make it Software Freedom Day Dundee Event, that you download and listen to this fantastic talk.

Robert’s company can be found at www.file-away.co.uk

A .mp3 version of the show can be downloaded from here