On November 4, 2009, Marsh Ray published detailed information about a vulnerability that affects the TLS/SSL protocols and allows for limited man-in-the-middle (MITM) attacks. We say “limited” because the attack exploiting this issue would be different from traditionally viewed MITM attacks, which would involve an attacker placing themselves in the middle of the SSL session between a client and a server and being able to intercept, view, and modify any requests or responses exchanged by the two communicating parties. In an attack using this recent TLS vulnerability, due to the way SSL-enabled applications handle the session-renegotiation process, an attacker may inject arbitrary plaintext into the beginning of the application protocol stream. This can affect multiple protocols that can communicate over an SSL session, such as HTTPS, IMAP, POPS, SIP, etc. Note that in this attack, the attacker would have no ability (at least without additionally exploiting other vulnerabilities) to see or manipulate any responses from the server or consecutive client’s requests. They may only inject plaintext data into the session.
While the analysis of the impact of this issue in connection with various application protocols is still in progress, the current research presents implications of the issue for the HTTP protocol that runs over SSL. In case of the HTTP protocol used with the vulnerable TLS implementation, this attack is carried out against applications by intercepting 'Client Hello' requests and then forcing session renegotiation. An unauthorized attacker can then cause the Web server to process an arbitrary request that would otherwise require some means of authorization; e.g. a valid client-side certificate. Additionally, using more advanced techniques the attacker can trick a Web server into combining parts of the malicious request with the legitimate client’s request and processing it in the application-level authentication context of the legitimate client.
Here is some practical information that should facilitate a better understanding and assessment of the risks associated with this issue:
1. To exploit this issue an attacker needs to be able to intercept network traffic between two parties. This can be achieved using multiple techniques such as DNS spoofing or ARP poisoning. Networks that utilize techniques and solutions for detecting and preventing such attacks should be better protected. The attack can also be carried out through a malicious proxy server.
2. The originally discussed attack vectors were against communications that use client-side SSL certificates. Cases not involving client certificates were also said to be demonstrated, but they were difficult to exploit. This has since changed, as some interesting developments present attacks against deployments not using client-side certificates, radically increasing the potential attack surface.
3. Most applications that use client-side certificate authentication implement some sort of application-level authorization as well. This forces potential attackers to use request-splitting techniques. While in case of the HTTP GET request this is not very difficult, the same technique presents significant challenges in case of HTTP POST requests, making the exploitation more difficult and obviously application specific.
4. Web applications that utilize cross-site request-forgery (CSRF) protections are effectively better protected against this issue—as already mentioned by many researchers. However, it should be noted that these protections do not eliminate the possibility of successful exploits. These measures usually rely on HTTP POST parameter values and can be rendered ineffective by attackers carrying out the aforementioned request-splitting attacks involving POST requests.
5. The newest developments present a practical attack on the API of the Twitter social network to disclose the authentication credentials of the victim. The attack uses the content publishing functionality of the targeted website to disclose the entire contents of the legitimate request, including authorization details. This new attack potentially affects a large number of deployments and users because many websites offer similar functionality and verify user credentials or sessions in a similar way. This approach aims to disclose information and steal authentication credentials and is most likely to be exploited in the wild.
A draft of the proposed solution for changing the implementation of the TLS protocol has been brought to the table. Before it is accepted and widely implemented, several other fixes are anticipated, including disabling the core of the problem—protocol renegotiation—such as in case of OpenSSL. Up to the publication of this blog post, multiple vendors have responded to this issue. Multiple Linux distributors released updates incorporating Apache and OpenSSL fixes. Others such as Cisco and Citrix initially responded to the issue stating that they are in the process of assessing the impact on potentially affected products.
We recommend assessing deployments that are potentially vulnerable to this issue and applying the fixes. In case this is not possible, users running clients should consider mitigation involving securing the communication channels with additional encryption, such as using a VPN tunnel.
Currently there is much theoretical speculation on the potential impact and severity of this issue, while little is known about the practicality of the attack scenarios. So far we have seen one instance proof-of-concept code, which was released publicly, and the discussion of an attack on the now patched Twitter API. Upcoming developments should highlight the practicality of exploitation and shed more light on this particular vulnerability and the threat it poses. In the meantime, please follow the mitigation and defence strategies highlighted above and refer to the referenced documents.