Background
RC4 (Rivest Cipher 4) is a stream cipher. It was designed by Ronald Rivest (from RSA) in 1987. RC4 was (and still is) a commonly used cipher in many software packages. It was also used in the wireless standards such as WEP (wireless encryption protocol) and WPA/TKIP.
What is wrong with RC4?
RC4 was a good protocol but it is time to move on. In 2015 RC4 is weak.
In 2001 Itsik Mantin and Adi Shamir have shown
"a major statistical weakness in RC4, which makes it trivial to distinguish between short outputs of RC4 and random strings by analyzing their second bytes. This weakness can be used to mount a practical ciphertext-only attack on RC4 in some broadcast applications, in which the same plaintext is sent to multiple recipients under different keys".
This meant that practical plaintext recovery attacks on RC4 were possible (at least in theory). But until 2013 SSL and TLS ciphers based on RC4 were considered more or less secure and were widely used. Research data from Microsoft suggests that in 2013 almost 43% of web sites either required or preferred the use of RC4.
Several groups focused their research on WEP with more weaknesses (attributed to RC4) revealed in 2004 (The KoreK and Chopchop attacks) and 2007 (The PTW attack).
In 2011 a group of researchers presented 9 new exploitable correlations in RC4. They have demonstrated a practical attack against WEP - a key could be recovered by capturing only 9800 encrypted packets (requiring less than 20 seconds).
In March 2013 another group of researchers found a new attack "that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used".
This particular attack made WPA/TKIP weak too. WPA2 has essentially become the only recommended option.
From this moment many software vendors were recommending to reduce our reliance on RC4. On the clients it was recommended to disable it. On the servers some companies deprioritised RC4 ciphers or (the brave ones) disabled them altogether.
At the end of 2013 Microsoft has published a KB article with the patch and recommendation how to disable RC4 via the registry settings. This patch did not apply to Windows 8.1 and Windows Server 2012 R2 as they already included the functionality to restrict the use of RC4 - i.e. RC4 won't be available in the first handshake.
In March 2015 we saw a new attack against RC4 in TLS that focussed on recovering user passwords. And although it was more efficient than the previous versions it was still not very practical in real terms.
The latest announcement (hence the :RC4 No More" in the title) comes from Mathy Vanhoef and Frank Piessens. Their RC4 NOMORE attack "exposes weaknesses in this RC4 encryption algorithm".
We require only 9⋅227 requests, and can make a victim generate 4450 requests per second. This means our attack takes merely 75 hours to execute
An attack that only needs 75 hours? That's VERY practical!
And another quote specifically in relation to WPA-TKIP
We can break a WPA-TKIP network within an hour. More precisely, after successfully executing the attack, an attacker can decrypt and inject arbitrary packets sent towards a client. In general, any protocol using RC4 should be considered vulnerable
Hmmm, a scary paragraph, right? If you want to feel safe using your WiFi connection to not use the TKIP variants - use only the AES ones. WPA2-AES is the best option so far.
It is also worth noting that early attacks (2001) were passive - an attacker was just listening, collecting data/packets, and performing analysis. The latest attacks require an active interaction (sending packets) between the attacker and the victim. This makes this type of attacks quite noisy.
Where to from now?
In short - RC4 must be disabled everywhere.
I would like to provide some practical recommendations
Clients/Browsers
Some vendors (e.g. Microsoft, Mozilla) have been advocating to disable RC4 support since 2013. If you are still using Windows 8 or below - install the patch (KB2868725) and apply the corresponding registry settings.
Internet Explorer 11: Does not offer RC4 ciphers in the initial SSL handshake (meaning that most likely another non-RC4 cipher will be negotiated with the server). Note: IE11 CAN perform a fallback to RC4 if the initial handshake was unsuccessful (a relatively rare (3.9%) scenario involving systems that can ONLY support RC4). So I would say if you are on Windows 8.1/IE11 you don't need to do anything special.
Mozilla Firefox:
- Navigate to about:config
- Search for RC4 (i.e. for entries like this one - security.ssl3.ecdh_ecdsa_rc4_128_sha)
- Disable all those RC4 entries (double-click the line to set value to false)
Chrome:
Chrome allows you to selectively disable specific ciphers via a command line parameter. You will need to launch Chrome with this parameter (the easiest and most convenient way to achieve this is to update the shortcut you use to launch Chrome):
--cipher-suite-blacklist=0x0004,0x0005,0xc007,0xc011,0x0066,0xc00c,0xc002
I took a full list of supported cipher IDs from this article and selected those with RC4 in their names.
You can check which ciphers are supported by your browser using these 2 links:
You should not see any RC4 ciphers on the results page.
Servers/Network equipment/Load balancers/Firewalls etc
Review your currently enabled cipher suite and ideally remove any of the RC4 ciphers. If, for any reason, you cannot do this then deprioritise (i.e. move them down the list) any of the RC4 ciphers to increase the chance of clients negotiating a non-RC4 cipher with your server.
If your system is accessible from the Internet, you can use the brilliant Qualys SSL Labs SSL Server Test to check which ciphers are enabled and in which order they will be negotiated with the clients.
If RC4 ciphers are detected you will see this message
Make Internet a safer place - disable the RC4 ciphers today!
No comments:
Post a Comment