Slashdot's headline "SSL/TLS Vulnerability Widely Unpatched" on Monday, June 20, suggested that Yahoo!, like a large number of other major websites, has been negligent in updating their web servers to protect against a known and patched issue. Being a member of the central security team at Yahoo!, I was at that time asked frequently whether or not we were vulnerable to the given issue, which is why I wrote up a version of this article for our internal security blog to help our developers and engineers better understand the possible impact at the time.
Before explaining whether or not we were susceptible to an attack based on this protocol flaw, it proved useful to first try to understand the problem itself. I actually really like this particular vulnerability and have used it in the past as a case study to teach students about system security. The reason for that is that it's a seemingly obscure protocol flaw that does not appear to immediately enable an attacker to gain any information or wreak havoc; however, as things aren't always as obvious as they seem, under certain circumstances this protocol flaw can be exploited. In addition, it being a protocol flaw (and not an implementation issue in one specific piece of software), it was a nearly universally applicable issue, as made clear in CVE-2009-3555:
The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions [...]
If you read this again, you'll notice that all common libraries are vulnerable -- isn't that fun! You'll also notice that even though this appears to effect about everybody on the internet, it seems understandable why the risk posed by this vulnerability was initially rated as low: first, you have to mount a man-in-the-middle (MITM) attack; secondly, all you get to do is insert data. That is, you do not magically gain access to the already encrypted data, you cannot read the response from the server, all you can do is add a few bytes of your own data.
So, back in 2009 (I know, right? Like... so long ago and stuff! Most internets didn't even use OAuth back then. Hmmm, I wonder why Twitter started using OAuth.) people seemed to dismiss this vulnerability as not posing a great risk. Alas, no thing is always absolutely so, and if you're clever enough, you actually can use this flaw for mischievious purposes.
The problem itself is described as follows:
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.
This becomes interesting if you understand the protocol spoken within the SSL encapsulated connection. Most protocols have a need (for backwards compatibility, for example) to ignore certain input ("Be lenient about what you accept..."), and if you can inject data, you can probably prepend or append data. This then, as it turns out, may allow you to completely change the request a client made, but still use the client's credentials (for example, their cookies) -- all that without the client being any the wiser, as the protocol kindly helped you establish the connection.
The best explanation of the vulnerability I've found is on this page, where bogus pizza toppings are ordered (muahahaha!). The practical application then is best explained by making users tweet their credentials. As you can see, the initially as obscure and academic dismissed issue quickly found so-called real-world applications.
To mitigate the issue extensions to the protocol were created, but of course those still needed to be rolled out. If you've worked at a place the size of Yahoo!, you probably have an idea of how long it might take to update a library as elementary as libssl, which is part of the base operating system, and where upgrading this component may require a complete OS update on hundreds of thousands of hosts. Hence, it is not entirely surprising to find about 1.5 years after the discovery of the issue many sites still appear vulnerable to this attack based on the ssl library version in use.
And so, with a bit of sensationalist journalism and the use of bright red colors (Danger, Will Robinson!), the point is made: "major ecommerce sites are susceptible to a vulnerability discovered almost 2 years ago". However, as the site does in fact actually mention (unlike the Slashdot article), it is entirely possible to use a version of the library with the flaw and yet not be vulnerable -- the exploit depends largely on the protocol use and data flow, after all.
Well... so since the site in question did (back in June, when this entry was first written) prominently display login.yahoo.com as BAD (though there are other ways to evaluate an SSL cert, which today show login.yahoo.com as "good"), was this really a serious problem? The answer, as you'd expect, is a clear "Yes and No". "Yes", because we generally should be using safe and up-to-date versions of the libraries; because we are not arrogant enough to claim "could not possibly be a problem for us, now or ever". "No", because the attack model did not necessarily apply to our use of login.yahoo.com. Remember: the attacker cannot view the data coming from the client, nor the response. In the case of login.yahoo.com, the only valuable thing to gain is either the data the client is sending (inaccessible to the attacker) or the reply the servers is sending (ie cookies, also inaccessible to the attacker). That, together with the fact that we have other protective measures in place did in fact allow us to not run around waving our hands and predicting the end of the world.
Make no mistake: we took this problem serious (and obviously resolved it), but security is not always quite as black and white as the initial article suggested. Either way, I still think of this as a very neat and near exemplary vulnerability, and I particularly like the clever way Twitter was exploited. Let's hope we won't be next for whatever else will be discovered in the future...Posted September 8, 2011 at 1:46 pm