HI Folks,

By injecting forged messages to the remote server, attacker can truncate TLS connections over malicious networks. Exploiting most logical web applications vulnerabilities, Truncation attacks were mostly executed on casting votes in Helios elections, also taking full control over Microsoft live accounts & temporarily accessing to Google accounts. Attacker doesn’t rely on installing malware on client computers. But as long as he can be in the middle of client-server connection, he can take control over user’s account where user unknowingly remains logged-in. In that case server can excuse that it doesn’t receive original user’s log out request as man-in-the-middle performs forged actions.

Introducing TLS security, there’re are different termination modes which it can execute:

• Graceful closure: all messages receive as sent
• Fatal closure: A part of the message received as sent

Browsers maintain an open pool of connections with remote server. One of the implementation challenge in TLS is that it doesn’t guarantee integrity across multiple connections. There’s a high probability that network packets may drop in transmitting over the network. Hence there will be ordering issues, server can ignore termination modes. By allowing graceful closures over wire transfers we can simply avoid truncation attacks in dropping fragments but not in dropping whole messages.

Many Microsoft Live accounts have suffered from above Truncation attacks as original user does get notification of sign out before server receives request. Attacker access remote server from another connection which keeps opened in the forged network.

Many single sign-on accounts are in danger with this kind of attacks as attacker can take full control over all your sub-accounts. When the user requests log-out from the server, Microsoft service responds with encrypted Javascript code which initialize log-out session. Then user sends parallel log-out requests to every services where he has been logged-in before.

 

But in truncation attacks, user unknowingly may drop one or more of those log-out requests by giving full control to the attacker over non-logout accounts. Centralized authentication on server side can fix this problem partially where server initializes log-out requests. But that will put more burden to the server.
Browser can request log-out in a chain manner. So the next log-out request get used to know about what was happened earlier. This keeps doing until original user makes him believe about the log-out session.

Similar attacks were performed on Google accounts in where even trusted computers can’t able to avoid. But attacker can’t rely on dropping TLS fragments as before. Because Google does hang out in the browser as it will wait to load the log-out image. But we can simply send TCP reset that destroy that connection. At this moment browser believes that it successfully logs-out from the session. The problem here that TLS ignores the fatal connection closure as attacker can access original user’s Google services on another connection. But this will last only 5 minutes. Because on Google server side, they do housekeeping service to log you out from all the services as long as only one service has been activated randomly. We can do this House-keeping as soon as user requests log-out. Though it needs more works to do in the server side, at least it will ignore future truncation attacks. We can recover from this attacks by handling fatal connection closure as well as performing similar fixes that we did to Microsoft accounts.

We can conclude that even trusted shared computers do not offer security anymore. But all above mentioned fixes on truncation attacks should perform on trusted shared computers as we can’t guarantee on malware attacks perform in client or server side computers.

Today’s industry disclose all vulnerabilities on truncation attacks, but none of them are fixed yet. But many researches guess that de-synchronization of client/server state is the attack vector. Further attacks can be performed in similar manner. But we propose that better programming practices should can adopt them. Then similar problems will be avoided in the future.