Encrypted Web and Wi-Fi at risk as RC4 attacks become more practical

Researchers Mathy Vanhoef and Frank Piessens from the University of Leuven in Belgium devised a new attack method that can recover authentication cookies and other sensitive information from Web connections encrypted with RC4.

The RC4 (Rivest Cipher 4) algorithm was designed in 1987 by renowned cryptographer Ron Rivest and remained a trade secret until 1994, when it was leaked on the Internet. Since then it has been implemented in a number of popular protocols, including SSL (Secure Socket Layer) and its successor, TLS (Transport Layer Security); the WEP (Wired Equivalent Privacy) and WPA (Wi-Fi Protected Access) wireless security standards; Microsoft's RDP (Remote Desktop Protocol) and MPPE (Microsoft Point-to-Point Encryption), BitTorrent and others.

Researchers have found and reported multiple weaknesses in RC4 over the years, but for the most part those attacks have remained theoretical or have not applied to RC4 as used in SSL/TLS.

In 2013, researchers from Royal Holloway, University of London, devised an attack against the TLS implementation of RC4 that required the observation of around 13x(2^30) -- or, 13 times two to the 30th power -- encrypted versions of a plaintext string in order to decrypt it. The string could be an authentication cookie that's included in every Web request sent by a client to a TLS server or some other similarly repeated piece of sensitive information.

The Royal Holloway attack was considered non-practical for the vast majority of real-world attackers, but did lead to speculation that intelligence agencies like the U.S. NSA might have the capability to pull it off.

Vanhoef and Piessens estimate that decrypting cookies using the Royal Holloway attack would take over 2,000 hours. By comparison, their new method, which they named RC4 NOMORE, would take only 75 hours.

That's because their attack requires a lower number of observations and because it can force a victim's browser to generate more requests per second than the Royal Halloway attack, 4,450 compared to 1,700.

"In contrast to previous attacks, this short execution time allows us to perform the attack in practice," the researchers wrote on a website that details their technique. "When we tested the attack against real devices, it took merely 52 hours to successfully perform the attack."

Fifty to seventy hours is still a long time, but the RC4 NOMORE attack has the benefit that it doesn't have to be continuous. The encrypted requests don't need to be captured all at once, so the collection can be resumed at a later time if the victim closes his browser or computer.

Forcing a victim's browser to make the necessary requests to a targeted HTTPS (HTTP + SSL/TLS) website can be done through JavaScript code that's loaded from a different Web page or is injected into the victim's Web traffic by a man-in-the-middle attacker.

The attack's impact for WPA-TKIP, a wireless security standard still used by old Wi-Fi equipment, is even worse. Breaking into wireless networks that use this encryption method takes an hour or less with the RC4 NOMORE attack.

"In general, any protocol using RC4 should be considered vulnerable," the researchers said.

Even with this significant time reduction, not everyone is convinced that this new attack is practical enough to become widely used.

"I think even 48 hours is an unreasonable amount of time to expect that a browser will be continuously open and sending over 4,000 requests per second the whole time," said Ivan Ristic, director of engineering at security vendor Qualys, via email. "If the attack takes longer, it's even less likely."

Also, the researchers chose to present the success of their attack against a 16-character cookie, which is too small, Ristic said. "That's usually only 64 bits of security (hex-encoded) whereas you should have at least 128."

And while there are some cookies that can persist for long periods of time, like those used to automatically log users back into Web sites, the typical session cookies should be reset much more often, Ristic said. "I usually go for 12 hours -- effectively one working day."

Despite all that, Ristic, who is also the creator of the popular SSL Labs test for HTTPS servers, believes that there should not be too much focus on how practical the attack is.

"RC4 is broken and is going away," he said. "This attack should be used as an excuse to speed up the deprecation."

Data gathered by Qualys' SSL Pulse project, which analyzes the TLS configurations of the world's top 150,000 HTTPS websites, shows that around 16 percent of them still use RC4 with modern browsers so are directly vulnerable. Another 44 percent support RC4-based ciphersuites, but likely only use them with a small number of legacy clients.

TLS supports multiple ciphersuites -- combinations of encryption, hashing and key exchange algorithms. These ciphersuites are listed in a TLS server's configuration in the order of preference.

If a server is configured to prefer RC4, clients connecting to it will use RC4, even if they also support more modern ciphers. If the server prefers a modern cipher, but the client doesn't support it, the connection will be encrypted using a cipher they both support, and that common cipher could be RC4.

HTTPS server administrators should disable support for RC4, Ristic said. "I believe that to be viable, except possibly in some special circumstances when dealing with very old legacy clients. It's certainly something that every organisation can check by enabling appropriate logging in their existing installations."