Security Advisory 977377: Vulnerability in TLS Could Allow Spoofing
In August of 2009, researchers at PhoneFactor discovered a vulnerability in the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. As the issue is present in the actual TLS/SSL-standard, not only our implementation, Microsoft is working together with ICASI, the Industry Consortium for Advancement of Security on the Internet to address this vulnerability. Today, Microsoft released an advisory and an associated workaround package that experienced administrators can use to protect their web services.
Explaining the risk of the security vulnerability
The issue, CVE-2009-3555, allows an attacker who successfully became a man-in-the-middle to prepend information to a TLS/SSL protected connection. It does not allow an attacker to read, change or edit the encrypted data. This vulnerability exists because certain SSL-protected protocols, such as HTTP, assume that information received after a TLS-renegotiation is sent by the same client as the information sent before that renegotiation. Renegotiation is a feature of the TLS protocol, described in RFC 2246 which allows either peer to renegotiate the parameters of a protected connection at any point in time. An attacker could exploit this vulnerability by intercepting a legitimate connection from a client, then initiating a renegotiation to the vulnerable server, or by piggybacking on a TLS renegotiation initiated by the web server.
This vulnerability can affect different protocols that use TLS/SSL, but most clearly affected is the HTTPS protocol which protects web transactions.
IIS 6, IIS 7, IIS 7.5 not affected in default configuration
Customers using Internet Information Services (IIS) 6, 7 or 7.5 are not affected in their default configuration. These versions of IIS do not support client-initiated renegotiation, and will also not perform a server-initiated renegotiation. If there is no renegotiation, the vulnerability does not exist. The only situation in which these versions of the IIS web server are affected is when the server is configured for certificate-based mutual authentication, which is not a common setting.
Scope of the vulnerability in IIS 5
IIS 5 does allow clients to initiate a TLS renegotiation and is vulnerable in its default configuration. Our investigation has shown it is unlikely that these attacks will be exploited successfully. An attacker would already need to successfully leverage a man-in-the-middle attack to intercept a connection between a client and vulnerable server in order to exploit this vulnerability.
Likelihood of the vulnerability being exploited in general case
Eric Lawrence, a Program Manager in the Internet Explorer security team also evaluated the exploitability of the vulnerability and found the following:
The below is an example of an exploitation of this vulnerability. The text in red is prepended to an SSL connection by an attacker, the text in blue is sent by the unwitting victim client, and the text in green is the web server’s response:
GET /app/transaction.asp?action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000 HTTP/1.1
X-Ignore-This-Line: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)
Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk
Host: www.victim.com
HTTP/1.1 200 OK
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close
<html><body>Successfully sent $2000USD from account #12345 to account #6666.</body></html>
The lines highlighted in yellow represent client state or identification information; by being in the same header block as the attacker’s request, they effectively authorize that spliced request.
There are two reasons why this attack is unlikely to be exploited:
· If a site is vulnerable to this attack, they are almost certainly vulnerable to classic Cross Site Request Forgery style of attack. The attacker need only send the client some HTML containing an IMG SRC to the victim URL and the client will dereference that URL, automatically providing the credentials to the server. This is a simpler mechanism of accomplishing the same thing than the more complicated TLS/SSL and request-splicing attack hopes to achieve.
· If an attacker were able to overcome the previous issue, this technique will not work for a site that only accepts parameters via HTTP POST requests. The reason is that the attacker must convey the malicious request within the POST’s body. By definition, the HTTP POST body occurs _after _the request header block has completed. So, the malicious attack would look something like this:
POST /app/transaction.asp HTTP/1.1
Host: www.victim.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)
Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk
Host: www.victim.com
HTTP/1.1 400 Bad Request
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close
<html><body>Credentials required.</body></html>
Because the victim’s spliced request is sent _after _the header block, the credentials will not be used to authenticate the submitted transaction. The only way an attacker could make this work is if the server accepted what are called “Trailer” headers from the HTTP request, like so:
POST /app/transaction.asp HTTP/1.1
Host: www.victim.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Trailer: Authorization, Cookie, X-Ignore
3E
action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000
0
X-Ignore: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)
Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk
Host: www.victim.com
However, it is unlikely that real-life web applications actually would accept this type of Trailer header, as it is a very little-used part of HTTP, not supported by mainstream browsers such as Internet Explorer.
Workaround package available to disable TLS renegotiation
While a comprehensive, multi-vendor fix is in the works, today we released a workaround package which allows system administrators to disable TLS renegotiation on their server. This package is described in KB article 977377 and disables TLS/SSL renegotiation for all TLS/SSL-protected protocols. We need to stress that TLS/SSL renegotiation is a feature of the protocol that is used by several applications. One common example is Microsoft Exchange and ActiveSync. These applications may operate inappropriately upon installation of this workaround package. We recommend that administrators carefully test the workaround prior to deploying it on production systems. The package will protect all clients making SSL connections to the server on which it is installed. Installing it on clients will not provide any security benefit.
We recommend that customers only install this workaround if they have very specific concerns regarding this vulnerability and require an ad-interim solution while Microsoft and other vendors work on a revision of the protocol.
Despite the low risk of active exploitation, this vulnerability breaches a security promise made by the TLS protocol and we intend to address it comprehensively. We are working with the relevant standards body and our partners in ICASI to ensure that our fix for this issue is compatible with third party SSL/TLS-enabled solutions.
Thanks to Nasko Oskov from Windows Security, Eric Lawrence from Internet Explorer and Jonathan Ness from the MSRC Engineering team for their significant contributions to this blog post.
-Maarten Van Horenbeeck, MSRC Program Manager
*Posting is provided “AS IS” with no warranties, and confers no rights.*