SSL Wars: The Return Of The SSLi

The content of my last few posts has looked at SSL implementations and vulnerabilities. Today’s post is no different, as I will be discussing the importance of patching vulnerabilities in specific implementations of SSL. I have always found it ironic when vulnerabilities are discovered in technologies which have the sole purpose of providing security. As of late a couple of interesting SSL vulnerabilities have surfaced which caught my attention. The CVE IDs of the two vulnerabilities I will briefly discuss are CVE-2010-2566 and CVE-2009-2510.

CVE-2010-2566 is a vulnerability found in Microsoft’s Schannel.dll. Per Microsoft’s Security Bulletin Schannel (Secure Channel) is “a Security Support Provider (SSP) that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Internet standard authentication protocols”. The Schannel vulnerability is a heap based corruption which is the result of “the code that validates client certificate requests sent by the server.” If successfully exploited this vulnerability could lead to remote code execution on the victim’s machines (http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-a-remote-code-execution-vulnerability-in-schannel-cve-2010-2566.aspx). In order to exploit this vulnerability, an attacker would need to cause the victim to visit a webpage where the attacker has set up a malicious web server. This vulnerability has been addressed in Microsoft Security Bulletin MS10-049.

We can learn two very important lessons from a vulnerability like this. The first lesson we can learn from this vulnerability is that it is important to apply critical patches as soon as possible. New vulnerabilities are always being discovered and it is critical the patches which remediate these vulnerabilities are applied as soon as possible. The second lesson we can learn from this vulnerability is the fact that there is always a danger when visiting any web site which you do not directly control. Sites which appear shady or have a large number of ads and pop-ups are especially dangerous, but even legitimate sites can be compromised and forced to serve malware to unsuspecting guests. The New York Times fell victim to an attack in which people visiting their website were greeted with a pop-up telling the unsuspecting victim that their machine was infected with Malware and that they should download fake antivirus. Although attacks originating from otherwise reputable websites are not extremely common, it is important to note these kinds of attacks have been found in the wild.

Suppose an attacker were the first one to identify and develop a working exploit for CVE-2010-2566. The attacker could set up a fake website and find ways to entice people into visiting these websites. Upon simply visiting the site, the attacker would have control over the victim’s machine. The scary thought is we are really unsure how many zero days are in the wild. These web servers may be waiting for someone to connect and take control of the victim’s machine.

The second vulnerability I will discuss is CVE-2009-2510. An attack known as the “NULL Prefix Attack” exploits this vulnerability in order to trick a client into connecting to a spoofed site. This vulnerability was first discovered by Moxie Marlinspike and is easily exploitable through his SSLSniff tool (http://www.thoughtcrime.org/software/sslsniff/). This vulnerability exists because of the way most SSL implementations treat the fields in the certificates used by the SSL implementations.

SSL uses certificates which are based on the X.509 standard. X.509 certificates are formatted using ASN.1 notation. All string types in this notation are essentially some variation of PASCAL strings. PASCAL strings are stored in memory as a series of bytes. The length of the string is stored in memory followed by the bytes of the actual string data. Therefore the PASCAL string “hello” would be stored in memory as follows “0x060x680x650x6C0x6C0x6F”. This string would be read as follows:

0x06 = The next six bytes are part of this string
0x68 = h
0x65 = e
0x6C = l
0x6C = l
0x6F = o

This vulnerability is the result of the fact that most SSL implementations treat the X.509 fields as C strings instead of PASCAL strings. These SSL implementations use string parsing functions which treat the X.509 fields as C strings. Unlike PASCAL strings C strings are stored in memory as a series of bytes which indicate the end of the string through a NULL character. The C string “hello” would be stored in memory as follows “0x680x650x6C0x6C0x6F0x00”. This string would be read as follows:

0x68 = h
0x65 = e
0x6C = l
0x6C = l
0x6F = o
0x00 = Null character indicating the end of the string.

Because of the differences in the way strings are stored in memory between C and PASCAL a very interesting exploit which uses this vulnerability has been developed. Suppose I own the domain evilhacker.com. Since I own evilhacker.com I can obtain certificates for this domain signed by a trusted signing authority like VeriSign. Since I own this domain I can also own valid certificates for any sub domain of evilhacker.com like awesome.evilhacker.com, incredible.evilhacker.com or even www.paypal.com\0.evilhacker.com (\0 is the literal constant for the NULL character). Since X.509 fields are formatted with ASN.1 notation, having a NULL character in the Common Name is not a problem. The problem occurs when the web browser treats the Common Name as a C string and tries reading the Common Name field. The web browser would read the certificate’s Common Name all the way up to “\0”; because of this the browser would see the Common Name in the attacker’s certificate as www.paypal.com. The common name is identical to the domain name of the website and the browser will connect to the attacker without giving any error messages to the victim. I will try to give the NULL prefix attack greater context by showing an example of how it can be utilized.

I am an evil hacker who goes by the hacker handle “Cain” and I own the domain evilhacker.com. I decide I would like to use the NULL Prefix Attack to steal victim’s PayPal credentials. I download SSLSniff and have a certificate created for www.paypal.com\0.evilhacker.com. I have the certificate for www.paypal.com\0.evilhacker.com signed by VeriSign and head over to my favorite coffee house in the galaxy . . .Mos Eisley Cantina (Yes. . .In my world they serve coffee here as well). The coffee house has free public Wi-Fi and within minutes I am Man in the Middling the entire coffee house’s traffic. I passively monitor and forward customer traffic waiting for someone to go to www.paypal.com. A man in the coffee house named Belinda is browsing a scented candle website when he finds a cinnamon macadamia chocolate scented candle that he cannot live without. Belinda goes to www.paypal.com to make sure his account information is up to date before making his $5000 candle purchase. Belinda enters “www.paypal.com” in his browser and presses “ENTER”. SSLStrip intercepts the request to PayPal and presents the victim’s web browser with its own certificate of www.paypal.com\0.evilhacker.com. The browser checks the certificate to see if the certificate’s Common Name (www.paypal.com\0.evilhacker.com) is actually the name of the site Belinda typed into his browser (www.paypal.com). Belinda’s browser starts to read the certificate’s Common Name until it reaches the NULL character, at which point the browser believes it has reaches the end of the Common Name. The browser believes my certificate’s Common Name is www.paypal.com, it verifies the certificate has not expired, and it verifies the certificate was signed by a trusted certificate authority (In this case VeriSign). Belinda’s browser creates a secure connection with Cain’s machine believing it to be www.palpal.com. SSLStrip then establishes a secure connection with www.paypal.com. My machine acts as a secure proxy by encrypting all traffic between my machine and Belinda’s machine, decrypting the information on my machine, and forwarding the information over the secure tunnel already established with PayPal. Using this information I go out and buy a new computer with Belinda’s PayPal account.

The CVE-2009-2510 vulnerability teaches us two great lessons. First we can see once again the importance of patching. This vulnerability in the Microsoft CryptoAPI is addressed in Microsoft Security Bulletin MS09-056. Please note that other SSL implementations which are vulnerable to this attack may have a different CVE ID and will require a different patch. The second lesson we can learn from this vulnerability is that there are additional risks associated with connections made over a possible hostile network (Like coffee houses, airports, TOR tunnels, etc). The NULL Prefix Attack could easily be implemented before patches to remediate this vulnerability were available. In addition to the NULL Prefix attack, attackers may implement attacks based on the SSLStrip tool (Addressed in my previous blog), generate self signed certificates pretending to be legitimate sites (Addressed in a different blog), or implement a number of other attacks which are associated Man in the Middle scenarios. There should always be a level of caution when connecting to an un-trusted network.

By Gary McCully, Information Security Staff Consultant

Read more!

Information Security Policies and Procedures, Part 6

This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.

Part 1 , Part 2 , Part 3 , Part 4 , Part 5

Knowing Your Audience

A natural human behavior is assuming that the majority of the world’s people are similar to us; similar in thoughts, assumptions, knowledge, opinions etc. Psychologists may see this as the consensus effect, a form of cognitive bias. If you love ballet, you likely assume that far more people also like it than actually do.

What does this have to do with documentation?

When creating the various types of documentation, it is important to know your audience and understand their comprehension of the topic. In many cases, things that are second nature to you will be completely foreign to the majority of the world. If you are reading this, chances are you know what https means, but there are many people who only know that it sometimes goes in front of a web address, if they even know that.

For general distribution documentation, including companywide policies, you generally want to stay around a fifth grade reading level. (If you want to know why, fire up your favorite search engine and enter “reading comprehension levels of college graduates.”) Of course, nothing is ever that easy, because on the other side of the coin you want to make sure that you aren’t talking down to certain audiences. If you are creating a highly technical specification to be used solely by engineers, you can leave out the explanations of basic math.

Also keep in mind that the same word or abbreviation can have multiple meaning to multiple audiences. DC? To tech folks, that is the datacenter. If you work in a warehouse, it is the distribution center. Electricians will take it as Direct Current. To generation Y, DC is a shoe company, and to their parents it is a comic book company. DC is also shorthand for the District of Columbia. The list could go on and on, and that is just one example. So be certain to explain any abbreviations or acronyms the first time you use them within each document.

We must also consider not just denotation, but also connotation, especially in view of the vast range of connotations a general audience may have. The right amount of detail is essential. This becomes even more important when users may not be native speakers of English.

Writing to the correct audience is one of the most important elements of creating effective documentation. If the documentation is too technical for the audience, they will not understand it and likely not read it. Conversely, if the documentation is too simple for the audience, they may skim over important points.

In the next installment, we will discuss some of the intricacies of language. Should you read it, or must you read it?

Read more!