November 2009

Introduction

Late last week it was disclosed by security researchers Marsh Ray and Steve Dispensa that a design flaw in TLS (the IETF implementation of SSL) could allow an attacker to successfully inject data in an encrypted session using a man-in-the-middle (MITM) attack.   The primary problem occurs during the renegotiation of the TLS channel when client certificates are employed.  Their documents the vulnerabilities in the TLS protocol as well as how the vulnerabilities could be exploited to violate the integrity of the data stream between a web client and server.  Even though the encrypted data cannot be read by the attacker, it is possible to inject arbitrary data into an authenticated session and it will be treated by the server as if it came from the client.  I will discuss the risks associated with this important discovery and outline some potential attack scenarios.

Putting the Risk Into Perspective

• As mentioned previously, this vulnerability primarily affects sessions in which client certs are in use.  The vast majority of secured TLS sessions today do not involve client certs which limits the impact of this vulnerability.  For example, if you are shopping online or connecting to your bank over the Internet, it is almost certainly the case that a client cert is not in use.  Where client certs are sometimes used is in enterprise applications such as external access to corporate email.  Some companies require the use of client certs in this scenario.  Also, TLS sessions between systems used as part of a web application (e.g. SOAP calls) sometimes utilize client certs for greater security.  However, for most users client side certs are a non-issue which limits the scope of this vulnerability.

• Another limiting factor of this vulnerability is the fact that it can only be exploited via a MITM attack.  MITM attacks are fairly difficult to successfully execute as it requires the interception of the network traffic between the client and the server.  While this is not impossible, it certainly would require some additional work.  In many cases, the hacking that would be necessary just to pull of the MITM attack would lead to greater potential rewards than the hacking of the TLS connection.  Some examples of MITM techniques include:

1. Compromising the network of either the client or the server (e.g. ARP poisoning)
2. Manipulating the DNS server of the client
3. Taking advantage of an unsecured WIFI network connected to either the client or the server
4. Using social engineering to compromise either the client or the server
5. Compromising a proxy server used by either the client or the server

• The results of an attack against this vulnerability do not allow the attacker to see any encrypted data sent by the client or the server.  It could allow an attacker to inject commands into the session which the server would believe came from the client and would execute.  However, the attacker would not be able to see the results which limits the impact of this vulnerability.  This situation clearly violates the integrity of the session, but the amount of damage that can be done is limited.

• This vulnerability does affect more than just HTTP.  This is the most common protocol to use TLS, but others do as well (e.g. IMAP).  The shear scope of applications and protocols that rely on it warrants a fix to ensure that developers and end users can be confident in the behavior and security of their applications.

Summary

The vulnerability in the TLS protocol disclosed on November 4, 2009 is not likely to lead to a great deal of exploitation.  The primary reasons are the difficulty required to successfully launch an attack and the limited nature of the vulnerability and the how it can be exploited.  Most attacks today are financially motivated and are conducted by groups that understand how to perform a cost benefit analysis.  I suspect that they will look at this vulnerability and decide that there are easier ways to exploit systems for monetary gain and it will not be worth their time to devote resources to develop exploits for this one.  The pay off is simply not high enough.  In sum, I believe the risk to most individuals and organizations is fairly low.  Fixes are already being rolled out, but given the extent to which TLS is used today, it will likely be many years before all applications and devices have been remediated.  Even still, I will be surprised if we read about any significant compromises in the future that are attributable to this vulnerability.

Sources for Additional Reading