TLS has been designed and implemented to provide end-to-end data security. This includes data integrity, meaning that data-in-transit cannot be modified, replayed or reordered by an attacker without being detected at the receiving endpoint. TLS, however, does not provide data delivery integrity, it does not guarantee that all the sent data will actually arrive at the receiving side. This can leave the door open for TLS truncation attacks, which can block logout requests so that the user unknowingly remains logged into a web service. More on how this works later.
Why do we care about TLS termination modes?
Before we talk about TLS truncation attacks, we need to understand termination modes. TLS security guarantees are defined with respect to the following termination modes: graceful connection closure, which occurs at the end of a successful connection, and fatal closure, which happens at the end of an unsuccessful connection, for example, after receiving a corrupt message. In the event of graceful closure, TLS ensures that all messages are received as sent. By comparison, in the event of fatal closure, TLS ensures that a prefix of all messages are received as sent. At a lower level of abstraction, TLS is permitted to split messages into fragments, and TLS guarantees ordered delivery of all fragments on graceful closure and a prefix of all fragments on fatal closure.
The TLS termination mode is managed by specialized close notify alert messages to be sent when closing the TLS connection. The close notify message is used to notify the other party that it will not send any more messages on the current SSL/TLS connection. TLS specification states that “...unless some other fatal alert has been transmitted, each party is required to send a close notify alert before closing the write side of the connection…”. Thus, the close notify messages are considered obligatory.
How TLS truncation attacks work
The truncation attack is a security attack that can be applied when tearing down an SSL/TLS connection (phase 4). TLS truncation attack was discovered by researchers Ben Smyth and Alfredo Pironti of the French National Institute for Research in Computer Science and Control (INRIA). They identified logical web application flaws which can be exploited “to desynchronize the user- and server-perspective of an application's state.”
As a proof of concept, the researchers exploited the vulnerability to launch attacks in order to “take full control of Microsoft Live accounts, and gain temporary access to Google accounts.”
In web applications, the user is typically notified of the server’s state using some feedback mechanism. Feedback can be positive, when the user is notified of successful state changes, or negative, when the user is notified on errors. The absence of feedback can cause confusion—for instance, if a user attempts to save a file and no feedback is provided, then the user does not know if the file was saved or not—and violates basic design principles. TLS truncation attack focuses on incorrect feedback: web applications that generate (positive) user feedback before the server has committed to a state change.
A TLS truncation attack is possible thanks to a de-synchronization between the user’s and server’s perspective of the application state: the user receives feedback that the sign-out request has been successfully executed, whereas the server is unaware of the user’s request. The attacker blocks a victim's account logout requests so that the user remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted TCP FIN message (no more data from sender) to close the connection. The server therefore doesn't receive the logout request and is unaware of the abnormal termination.
The attack does not rely on installing malware on the victim's computer. Instead the attack works like a man-in-the-middle (MiTM) attack, where the attackers need only place themselves on the same network with the victim, for instance by setting up a rogue wireless hotspot.
A history of TLS truncation exploits
Microsoft Live Services
Researchers demonstrated a flaw in Microsoft Live’s authentication logic which can be exploited by an adversary to gain access to a user’s account. The attack was launched on the assumption that the user has at least two open sessions with Microsoft and the adversary controls the network and can access a computer shared with the user.
According to the attack vector, the adversary can selectively prevent the termination of active sessions, while giving the user feedback that his/her sign-out request succeeded. When the user leaves the shared computer, the adversary can use the computer to access the user’s account information and can reset the user’s password, taking full control of the user’s account.
The attack does not rely on tampering with the shared computer, and the adversary only needs access after the user believes she signed out, when the user is likely to leave the computer unattended.
The researchers demonstrated a flaw in Gmail’s authentication logic, preventing Gmail from terminating the user’s session, which can be exploited to gain access to a user’s email account. The assumptions of the attack are that the user has at least two open sessions with Google and the adversary controls the network and can access a computer shared with the user.
The attack works as follows. First, a user visits Gmail and authenticates a session on a shared computer. Secondly, once the user has finished reading her mail, she visits Search and a session is seamlessly authenticated by Google’s single sign-on service. Thirdly, the user makes a sign-out request and the server responds by guiding the user’s browser through a series of further requests which are intended to terminate each active session. In particular, this procedure should ensure that the session with Gmail is terminated. However, an adversary can selectively prevent the termination of active sessions, whilst giving the user feedback that her sign-out request succeeded. Finally, when the user leaves the shared computer, the adversary can use the computer to access the user’s Gmail account. It must be noted that access is limited to approximately five minutes, due to Google server-side housekeeping.
How likely are TLS truncation attacks?
Although above mentioned vulnerabilities have been addressed by involved parties, the research shows how advanced attacks may become by exploiting existing vulnerabilities.
For instance, researchers from INRIA and Microsoft Research demonstrated in 2014 that web browsers and servers often ignore TLS disconnections and tolerate ill-formed messages, thereby enabling message truncation. Although this vulnerability was already known from the work of Smyth and Pironti, the new research proved how to apply truncation to HTTP headers and HTML forms, opening new exploits, which enable full HTTPS session hijacking (by stealing session cookies) between mainstream web browsers and popular websites, compromising the confidentiality and authenticity of user communications, and exposing sensitive and personal data and credentials.