SSL Encryption Vulnerable

Wednesday, February 6, 2013 @ 11:02 AM gHale


There is a vulnerability out there that allows attackers to recover the plaintext of authentication cookies and other encrypted data as they travel over the Internet and other unsecured networks.

This makes it possible for attackers to completely subvert the protection provided by the secure sockets layer (SSL) and transport layer security (TLS) protocols. Together, SSL, TLS, and a close TLS relative known as Datagram Transport Layer Security are the sole cryptographic means for websites to prove their authenticity and to encrypt data as it travels between end users and Web servers. The “Lucky Thirteen” attacks devised by computer scientists to exploit the weaknesses work against virtually all open-source TLS implementations, and possibly implementations supported by Apple and Cisco Systems as well.

RELATED STORIES
Barracuda Networks Backdoor Accounts
Attack Vector: Faux Apache Modules
Apache CouchDB Fixes Holes
Sybase Fixes Database Holes

The attacks are extremely complex, so average end users are probably more susceptible to attacks that use phishing emails or rely on fraudulently issued digital certificates to defeat the Web encryption protection. Nonetheless, the success of the cryptographers’ exploits, which includes the full plaintext recovery of data protected by the widely used OpenSSL implementation, has clearly gotten the attention of the developers who maintain those programs. Already, the Opera browser and PolarSSL have undergone patching to plug the hole, and developers for OpenSSL, NSS, and CyaSSL should issue updates soon.

“The attacks can only be carried out by a determined attacker located close to the machine under attack and who can generate sufficient sessions for the attacks,” Nadhem J. AlFardan and Kenneth G. Paterson researchers wrote in a bog that accompanied their research. “In this sense, the attacks do not pose a significant danger to ordinary users of TLS in their current form. However, it is a truism that attacks only get better with time, and we cannot anticipate what improvements to our attacks, or entirely new attacks, may yet be discovered.”

Lucky Thirteen uses a technique known as a padding oracle that works against the main cryptographic engine in TLS that performs encryption and ensures the integrity of data. It processes data into 16-byte chunks using a routine known as MEE, which runs data through a MAC (Message Authentication Code) algorithm, then encodes and encrypts it. The routine adds “padding” data to the ciphertext so the data can align in 8- or 16-byte boundaries. The padding later removes when TLS decrypts the ciphertext.

The attacks start by capturing the ciphertext as it travels over the Internet. Using a long-discovered weakness in TLS’s CBC, or cipher block chaining, mode, attackers replace the last several blocks with chosen blocks and observe the amount of time it takes for the server to respond. TLS messages that contain the correct padding will take less time to process. A mechanism in TLS causes the transaction to fail each time the application encounters a TLS message that contains tampered data, requiring attackers to repeatedly send malformed messages in a new session following each previous failure. By sending large numbers of TLS messages and statistically sampling the server response time for each one, the scientists were able to eventually correctly guess the contents of the ciphertext.

To make the attacks more efficient, researchers can incorporate methods unveiled two years ago in a separate TLS attack called BEAST. That attack used JavaScript in the browser to open multiple sessions. By combining it with the padding oracle exploit, attackers required 2 sessions to extract each byte without needing to know one of the last two positions in a block.

The Lucky Thirteen attacks are only the latest exploits to subvert TLS, which along with SSL should safeguard bank transactions, login sessions, and other sensitive activities carried out over unsecured networks.

The attacks apply to all implementations that conform to version 1.1 or 1.2 or version 1.0 or 1.1 of TLS or DTLS respectively. They also apply to implementations that conform to version 3.0 of SSL or version 1.0 of TLS when they ended up tweaked to incorporate countermeasures designed to defeat a previous padding oracle attack discovered several years ago.



Leave a Reply

You must be logged in to post a comment.