Where does SWEET32 rank against other SSL vulnerabilities?
Cryptographic attacks with cute names seem to come around every few months; so far in 2016 we have seen BICYCLE, DROWN, and now SWEET32.
A pair of researchers, Karthikeyan Bhargavan and Gaëtan Leurent with the French national research institute for computer science, published a cryptographic attack against older, 64-bit block ciphers such as triple-DES (3DES) and Blowfish. They called their attack SWEET32 (CVE-2016-2183) as the attack starts to become practical after 2^32 cipher blocks.
The attack’s website explains that the basis for the SWEET32 attack involves the birthday paradox from probability theory. You may have learned about the birthday paradox in school when you found out that you only need about 23 random people before you find two that have same birthday. It’s a much smaller number than you’d think, right, given that there are 365.25 days in a year. You’d think you’d need half that to get a “birthday collision,” but you don’t.
The issue I’d like to look at here is how an enterprise security analyst should realistically view SWEET32. Is it an attack to be feared, or just a proof of concept?
Japanese Monster Alert Level
Recall that yours truly set out a quantification method for SSL and TLS cryptographic attacks right here in SecurityWeek in 2014 (and recently updated for DROWN). The original goal of the stack ranking system was to provide a relative measure for each cryptographic attack. To make the result more accessible, we can categorize the attacks into three categories. I chose increasingly fierce Japanese monsters to represent each.
Let’s see where SWEET32 would land in my ranking system, which is similar to the CVSS methodology in that it focuses on impact and exploitability.
The SWEET32 attack looks for collisions (duplicate ciphertext blocks) from the 64-bit block ciphers in order to tease out sensitive plaintext. For HTTPS, the most obvious target plaintext is a session cookie. By my table, session cookies are among the lowest impact because they don’t divulge cryptographic keys, and it’s hard today to escalate them to other credentials.
The exploitability value of SWEET32 is on par with POODLE, BEAST, and any other attack that requires identical plaintext to reside at exactly the same offset for millions of TLS records. SWEET32 falls into this category, since it requires the 32-bit counter to roll around. The typical way to do this for a proof of concept is to have a “man-in-the-browser” (MitB) force millions of client requests over a long-lived HTTPS session and an active or passive man-in-the-middle (MitM) network agent.
My ranking system gives SWEET32 a very low exploitability score (1 out of 10). For web traffic, SWEET32 would require an MitB and an MitM—and it’s only applicable to those servers that would be preferring 3DES in the first place. Without another vector (like LOGJAM), an attacker cannot force the client and server to downgrade from AES to 3DES due to the handshake signatures that have been in place since SSL v3. According to the researchers this is around 0.5% of high-traffic sites, and this correlates exactly with my own data.
The attack is even more difficult to launch against a real browser and server, as most browsers open multiple TCP connections to the servers for performance. The researchers had to force a single TCP connection by effectively terminating the additional connections that the browser was trying to open.
Thus, the exploitability of SWEET32 is extremely low. Only servers preferring 3DES. MitB required. Active MitM required (to enforce single TCP connection). Millions of SSL records and hundreds of gigabytes required. Definitely non-trivial exploitation.
SWEET32 is probably not something that an enterprise administrator needs to lose sleep over. Very likely, we will never see a SWEET32 attack in the wild, just as we never have for POODLE or BEAST.
Sweet Dreams
Because SWEET32 is an exploit of a well-understood issue in security (birthday paradox and the perils of short blocks), if a nation state had wanted to use this technique they would have already known about it. But there are so many other, easier ways to compromise or infiltrate a target that it’s hard to see them having to resort to this type of attack.
The OpenSSL group’s response to SWEET32 is to remove 3DES from the DEFAULT cipher for versions 1.0.1. Previous versions will downgrade 3DES from HIGH to MEDIUM for those that use either of those cipher strings.
Of course, attacks like SWEET32 have research value, and I do not mean to denigrate or lessen the attack or it
s authors. Research like SWEET32 is worthy work, if only to remind the InfoSec community that attack that seem infeasible during design (as the birthday attack did in 1998 when 3DES was standardized) may become feasible sooner than you’d think.