Scary Candy Week: KRACK and ROCA
What You Need to Know and What You Need to Do
It’s not a coincidence that Halloween falls in October. We humans have a heightened fear perception this time of year; it’s some kind of vestigial response to the shortening of days. What month has seen the most unexplained market crashes on Wall Street? October. If Halloween hadn’t originally been in October, we would have moved it there where it felt more natural. October also happens to be Cybersecurity Awareness month.
So, it’s doubly-perfect that this week we got not one horrible “OMG the Internet is broken!” protocol vulnerability, but two “OMG the Internet is broken!” vulnerabilities. Released on the same day no less—Monday, October 16.
What’s even worse is that the vulnerabilities could conceivably compound on each other in a horrible way, as you’ll see.
KRACK: Key Reinsertion Attack against WPA2 WiFi
Belgian security researcher Mathy Vanhoef published an attack against WiFi clients using the WPA2 authentication protocol. The target client can be tricked into joining a duplicate WiFi network and then coerced into installing a null (blank) encryption key, allowing the attacking to assume a man-in-the-middle position.
Vanhoef explains the KRACK attack succinctly in the branded, logoed vulnerability site krackattacks.com. We highly encourage you to watch the short video Vanhoef made demonstrating the attack.
Once the attacker has achieved the man-in-the-middle position between the client and access point, he can use the good old sslstrip tool to trick the client browser into sending passwords in the clear. The example uses match.com credentials (for fun), so Vanhoef just gave you everything you need to spy on your ex’s dating habits. Just in time for Halloween! [We’re kidding, do not do this.]
The astute reader will be thinking, “Hey, insecure networks is why we have SSL protection! So we’re still safe, right?”
Well, the other scary vulnerability released, coincidentally, on the same day as KRACK, has to do with weak keys generated from highly secure crypto devices. Wot!
ROCA – Return of Coopersmith’s Attack (CVE-2017-15361)
The latest SSL/TLS vulnerability is ROCA – the Return of Coppersmith’s Attack. Ars Technica has the best write-up we’ve seen to date on the scope and impact of ROCA. ROCA affects public/private RSA key generation done in time-limited conditions where the Infineon software attempts to take a shortcut called “fast prime” to approximate two large primes.
ROCA affects the software associated to Infineon chipsets that are often used in smart cards and embedded, high-security (trusted computing) environments. This being October, of course these chipsets are found in FIPS 140-2 and CC EAL 5+ certified hardware, both of which are solutions you pay tens of thousands of dollars for to keep your private keys, well, private. The Infineon bug results in the private key being practically factorable once an attacker knows the public key (which is almost always, because its public, and embedded in certificates, etc.).
It would cost an attacker $20,000 to $40,000 in CPU time to factor your 2048-bit private key. However, if the attacker is a nation-state, that’s not much of a deterrent for them. The cost to factor a 1024-bit key is only about $50—the cost of two beers at a Yankees game. According to F5 Labs’ own research, only 7% of the Internet still uses keys that small. Attacks like ROCA are exactly why we all upgraded to 2048-bit, right? Good for us. ECC keys are not vulnerable.
So far, the vast majority of the vulnerable keys are associated with smartcards, but researchers have found a handful of vulnerable TLS and Github keys. There is no word yet on vulnerable 1024-bit DNSSEC keys; that would be awful, since attackers could then sign their own malicious zone data.
Interestingly, it is basically free and instant to check to see if a key is vulnerable to ROCA. If the public key moduli conform to 38 small primes in a certain way, then it is likely vulnerable. The ROCA researchers have provided both online and offline tools for you to check your SSL/TLS, IPSec and SSH keys.
Given how easy it is to check for the vulnerability, we predict that browsers will soon warn you if you are visiting a site using a key vulnerable to ROCA. You heard that from us first.
KRACK + ROCA Attack: What’s the Worst-Case Scenario?
This is like writing a Halloween movie script. Imagine you’re a high-security environment (spy management office). Your enemies are the worst enemies in the world; think S.P.E.C.T.R.E. or similar.
One of your operatives connects his Windows 10 laptop to the wireless network in your Istanbul office. Little does he know that a S.P.E.C.T.R.E. counteragent is spoofing the Wi-Fi and sending CSA channel beacons to his laptop. Within seconds, your operative’s laptop is being routed through the counteragents access point. Your operative activates up his SSL/VPN (not F5’s unfortunately) to access some top-secret corporate data back at HQ.
The counteragent has already used his nation-state capabilities to factor the SSL/VPN’s private key from the ROCA vulnerability. He can decrypt everything your agent is downloading from the top-secret server. Also, the counter agent gets your agent’s match.com password!
Think this worst-case scenario couldn’t happen? Weirder things have happened. [cough, <stuxnet>, cough, <eternal blue>].
KRACK and ROCA: Are you Vulnerable?
F5 Networks hardware and software: Not vulnerable. F5 isn’t in the wireless business. While it’s theoretically possible to use our TMOS platform as an access point, no one does this thank goodness. For KRACK, see the official KRACK statement from F5 Networks SIRT.
F5 Networks is definitely in the business of SSL/TLS keys. Here again, F5 equipment and software are not vulnerable. We do use the Infineon chipsets in a few appliances, but we do not use its key generation. See the official ROCA statement from F5 Networks SIRT.
Your equipment (KRACK): Vulnerable, but… KRACK attacks the client side of a WiFi connection. So in one sense it doesn’t really matter if your access points are patched or not. Let’s agree that you should patch your access points anyway (good security practice) but that won’t protect your users from KRACK. There’s no need to change your WPA2 WiFi passwords; they were never part of the problem and changing them won’t affect anything.
Your equipment (ROCA): Ideally you would know every SSL/TLS certificate associated with your enterprise. We say “ideally” because this is rarely the case; business units are bringing their own certificates all the time now. If you have a robust, comprehensive certificate management solution in place, you’re probably all over this already. If not, F5’s partner Venafi can scan your network for SSL/TLS keys. If you need to scan for certificates quickly, go to the Certificate Transparency project’s database (crt.sh) and search for your organization certificates. Then use the ROCA test tools to see if those public keys are vulnerable.
Your employees. Apple fixed iOS and MacOS in a stealth patch a few versions ago (they’re not saying which one yet). Android and Linux clients seem to be the most vulnerable. Microsoft clients are vulnerable as well. Your highest priority for KRACK should be your employees.
Relevant F5 Solutions
For F5 customers there are two relevant security solutions against KRACK and ROCA. The first is via F5's BIG-IP Local Traffic Manager (LTM), the primary module that does SSL/TLS decryption and load-balancing. LTM keys typically are not vulnerable to ROCA (unless they were generated elsewhere and imported to LTM; see below for test information).
LTM can enforce HTTP Strict Transport Security (HSTS), which will instruct all browsers to always use SSL/TLS when connecting to your applications. It’s a checkbox. Check it. HSTS alone will mitigate the worst aspects of KRACK.
The second, more layered defense, is BIG-IP Access Policy Manager (APM) and its associated end-point product, the BIG-IP Edge Client. Together, they create a secure SSL/TLS VPN that has end-point protection and a sophisticated policy engine to ensure that your employees are connecting to corporate resources securely. It supports all the popular platforms - Android, Windows, iOS and MacOS. APM also has federation so you get SSO for free.
Users in certain high-security environments may have the F5 products WebSafe and MobileSafe. WebSafe secures transactions in front of a server. The latter is a mobile toolkit API to create safer applications that connect to the former. The most relevant protection that these two can provide is Application Layer Encryption (ALE). ALE uses temporary RSA keys to asymmetrically encrypt user passwords prior before they are sent across the network. MobileSafe also provides a DNS spoofing protection feature which should help thwart the Man-in-the-Middle attack provided by KRACK.
- WebSafe Datasheet
- MobileSafe Datasheet
Your Halloween TODO List
Aside from picking out your Halloween outfit (suggestion: the Kraken might be apropos this year), you have some items to add to your TODO list for KRACK and ROCA.
- Double down on your SSL/VPN solution. If your current one doesn’t have multi-factor authentication (MFA), replace it with one that does. MFA will prevent attackers from using credentials compromised via KRACK to access corporate services.
- Enable HTTP Strict Transport Security on your F5 Local Traffic Manager to combat the sslstrip tool. Open a ticket with your network team if they’re the ones that support it (very likely).
- For WebSafe customers, enable Application Layer Encryption for sensitive fields in your critical Web Apps.
- For MobileSafe customers, implement DNS spoofing detection and certificate validation.
- Audit your organization’s certificates for the ROCA vulnerability. Bring in Venafi or another SSL certificate scanner if necessary.
- Check the Certificate Transparency project’s database (crt.sh) for certificates issued for your organization.
- Push OS patches out to employee laptops and mobiles.
- Expire user passwords. Assume that their passwords could have been compromised, especially for Android users or any user invoking the “ActiveSync” protocol.
Our threat intelligence site, F5 Labs, and our developer community, DevCentral, are continuing to look at these topics, and will make additional materials available as applicable. If you have further questions about the two vulnerabilities, or any of the solutions that we’ve talked about above, don’t hesitate to contact an F5 representative.
On a related note, F5's DevCentral team has posted a video further explaining the KRACK vulnerability, and additional commentary is available in the following F5 Labs post: New Threat May Slip through the KRACK in BYOD Policies