For now, the Lucky Thirteen attacks described in a paper last week by researchers at Royal Holloway, University of London, are largely theoretical. But the potential exists to adapt techniques used in the BEAST attacks against TLS/SSL to improve the feasibility of Lucky Thirteen, a researcher said.
BEAST, which stands for Browser Exploit Against SSL/TLS, is custom javascript exploit code developed by researchers Juliano Rizzo and Thai Duong that is injected into a browser session via a malicious iframe or a direct remote injection into a victim’s browser. Attackers can use BEAST to steal cookie data or hijack browser sessions. Researcher Matthew D. Green of Johns Hopkins University said a similar attack could be used to reduce the number of calculations currently required in the Lucky Thirteen attacks to decrypt a session and steal sensitive information.
“The guys who did the BEAST attack have written javascript like this already; someone would just need to tweak it,” Green said. “They’re most of the way there already.”
Lucky Thirteen was described last week in a paper written by Nadhem AlFardan, a PhD student at the Information Security Group at Royal Holloway, and Kenny Patterson, a Royal Holloway professor and noted SSL security expert and researcher. Lucky Thirteen works pretty seamlessly against Datagram TLS, a variant of TLS/SSL protecting most ecommerce websites. DTLS encryption is used with Datagram-based applications; there are limited DTLS deployments compared to TLS/SSL. The Lucky Thirteen attack is much more difficult against TLS, AlFardan and Patterson said.
“It takes days to run this attack against TLS, not because the attack doesn’t work but because the way TLS works makes it so slow,” Green said. “You would have to get javascript onto a computer and have it connect to a site for days in order to recover a cookie.
“That doesn’t mean it can’t be optimized in the future,” Green said, adding that experts such as Rizzo are already looking into this attack and if they were able to reduce execution time down to hours, the attacks against TLS would be much more feasible.
Lucky Thirteen is essentially a padding oracle attack where attackers would measure the time it takes to encrypt records when using the standard CBC ciphersuite used in TLS sessions. An attacker would have to be close to the target machine, on the same LAN and/or datacenter preferably, and inject himself into a session. The attacker would then have to modify an encryption record and measure how the changes are affecting the padding used to build a record up in order for the CBC ciphersuite to encrypt it. Green said an attacker can use this information to decrypt the whole record.
“You would be timing tiny differences, up to a microsecond,” Green said. “You can’t just time it once and get accurate results because of network noise. You would have to run this anywhere from 10,000 to 1 million times in the same experiment to get accurate results. That’s the real problem, it takes many connections, and each connection takes time. This is why it can add up to days right now.”
AlFardan and Patterson tested their attack against OpenSSL and GnuTLS implementations of TLS, and said they are working with developers on patches and advisories. With OpenSSL, they said a full plaintext recovery is possible; in GnuTLS, partial recovery is possible depending on certain conditions. They added that NSS, PolarSSL, yaSSL, BouncyCastle and OpenJDK are potentially vulnerable. They did not test their attacks against closed-source TLS implementations. During their tests, they were able to reliably recover a complete block of TLS encrypted plaintext using 2 to the 23rd power TLS sessions on the same LAN if SHA1 is the MAC algorithm in use. With certain other known variables, they said they were able to reduce it further to 2 to the 13th power.
In contrast, with DTLS implementations, they needed only a single session and were able to use known amplification techniques to lessen network noise and boost timing signals.
CBC is a significant weakness at play here, they said, because of the Message Authentication Code, or MAC algorithm, being used to protect the authenticity of a data record. The TLS protocol, written in the 1990s, applies the MAC algorithm to the plaintext portion of a data block, then adds up to 255 bytes of padding to get the message up to a multiple of the cipher block size in order for it to be encrypted, Green said. TLS, he added, should instead encrypt the message first and then apply MAC to the resulting cipher. The padding that is added is not protected by the MAC encryption and enables an attacker to tamper with it.
Green said an attacker would need a victim to keep a browser open for hours for the attack to potentially be carried out; with tabbed browsing he said, it wouldn’t be far-fetched for an attacker to get their javascript onto a tab that’s left open for hours.
“When you code something up, people always find tricks to make it better,” Green said. “As people start to think about Lucky Thirteen, they’re going to come up with ideas. If they can figure out how to cut it down so you don’t need to run 1 million tests to get a result, you’re cutting attacks down by a factor of 100. Then you’re not looking at days, but hours.
“Right now, it’s too much trouble and not the scariest thing,” Green said. “But if you can get it down to an hour or two, then it would be feasible.”
