Should the RC4 cipher still be used in enterprises?

A recently published paper described an attack that can break the RC4 cipher and decrypt user cookies. How does the attack work, and how can enterprises avoid being vulnerable to an attack? Is RC4 even still relevant?

The RC4 cipher became the most widely used stream cypher due to its speed and simplicity and is used in common protocols such as Wired Equivalent Privacy and Secure Sockets Layer and Transport Layer Security (TLS). While RC4 has long been known to be flawed, attacks against it have not been practical in real-world scenarios. Back in 2013, it seemed that RC4 was coming to the end of its useful life due to the increasing number of cryptographic weaknesses being discovered. Now cryptanalysis results are on the verge of becoming practical and feasible exploits, so the RC4 cipher should no longer be seen as providing a sufficient level of security for enterprise data.

Two Belgian researchers, Mathy Vanhoef and Frank Piessens, decrypted a Web cookie used during an HTTPS session secured by TLS and, using RC4 for encryption, within 52 hours, a huge reduction from the 2000 hours required by previous attacks leveraging RC4 weaknesses. Using a fixed-plaintext recovery technique they've called RC4 NOMORE (Numerous Occurrence Monitoring & RecoveryExploit) an attacker could trick a user into accessing code that generates enough data to successfully determine the user's encrypted cookie values. Hijacked cookies can be used to gain unauthorized access to information or services.

The attack uses biases in the RC4 keystream to recover plaintext. A keystream needs be uniformly random otherwise a bias can occur. The keystream generated by RC4 is biased in varying degrees towards certain sequences, for example some bytes are more likely to take specific values than they should. This makes RC4 vulnerable to distinguishing attacks whereby an attacker can distinguish the encrypted data from random data. RC4 NOMORE uses the Fluhrer-McGrew and Mantin's ABSAB biases to return a list of potential plaintext cookie values which are brute-forced until the right one is found. This type of attack will no doubt become even more efficient in the future.

The attack is not limited to decrypting cookies. Any data or information that is repeatedly encrypted can be recovered. For example, against a wireless network using the Wi-Fi Protected Access Temporal Key Integrity protocol (WPA-TKIP), the attack only takes an hour to execute. While the Wi-Fi Alliance is phasing out the use of WPA-TKIP, its usage is still widespread. Networks should instead use WPA2 configured to only use the encryption algorithm AES-Counter Mode CBC-MAC Protocol.

In February 2015, the Internet Engineering Task Force published RFC 7465 which prohibits the use of RC4 cipher suites when clients and servers establish TLS connections. Microsoft and Mozilla have issued similar recommendations to retire and deprecate the RC4 cipher as well as other weak algorithms such as SHA-1. Microsoft recommends TLS 1.2 with AES-GCM as a more secure alternative while providing similar performance.

Perversely, the RC4 cipher was the only common cypher that was immune to the 2011 BEAST attack on TLS 1.0 since this attack exploits a weakness in block ciphers. This led to an increase in the number of websites using RC4 (approximately 50%) but it has now dropped back and, according to the Computer Science Institute at University of California at Berkeley, approximately 13% of sites worldwide still use RC4. Website administrators using RC4 encryption need to switch to AES, a more secure symmetric block cipher. Web developers should ensure that session cookie values used to access sensitive information are a salted hash that changes with each server response. This will provide protection against brute-force attacks on cookies. As always, make sure users' Web browsers are fully up to date. All current versions of the major browsers avoid using RC4 and, like IE 11, will soon stop using it altogether.

Ask the Expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)