We live in interesting times

There is a Chinese proverb/curse saying: May you live in interesting times?

Why is this intended as a curse? Maybe living in interesting times means living in challenging times.

The security environment is so dynamic these days, it is certainly interesting to see how things change all the time, vulnerabilities are found almost every day, exploits are being developed at a whopping pace and even for professionals, just keeping up with it all is very challenging.

In the last two weeks there have been quite a few major security events/discoveries

Starting with KRACK ATTACK (announced 18th of Oct), which our blog already covered https://4cornernetworks.com/krackattack-kraken-wi-fi-wpa2/ but there are new things around the corner.

New VPN/crypto attack – DUNK (Don’t Use Hard-coded Keys) attack

With KRACK attack still going on strong there is a new one that involves breaking cryptography. This one however does not take advantage of the control messages in WPA-2 to allow sniffing of user data but exploits weak software implementation for the ANSI X9.31 RNG. Until quite recently the  ANSI X9.31 RNG was used to generate cryptographic keys that secure VPN connections and web browsing sessions.

A team of security researchers from the University of Pennsylvania and John Hopkins University found a vulnerability that affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key. The DUHK attack allows “attackers to recover secret encryption keys from vulnerable implementations to decrypt and read communications passing over VPN connections or encrypted web sessions”.

The attack has been confirmed to work on Fortinet devices running FortiOS 4.3.0 to FortiOS 4.3.18. The necessary requirement (all of them need to be met) for a device to be vulnerable to the DUHK are:

Also, the attacker needs to be able to observe passively the encrypted handshake traffic.

The X9.31 was widely deployed in the past and was even part of the FIPS approved random number generation algorithms set until January 2016. There is a big chance a lot of VPN implementations are still using it.

There is a CVE for this vulnerability: CVE-2016-8492:

Here are the general recommendations:

  1. If you are a Fortinet client, please make sure your FortiOS is not running versions 4.3.0 to 4.3.18, or else upgrade asap.
  2. If you are running any cryptographic software still using the X9.31 generator, reconfigure it to use other random number generator or replace/upgrade software.
  3. Always stick to the latest security approved cryptographic algorithms when creating VPNs. Legacy VPN should be reconfigured to follow the latest practices

Related articles:

https://4cornernetworks.com/krackattack-kraken-wi-fi-wpa2/

https://duhkattack.com/

Wi-Fi is everywhere, everything is on Wi-Fi now, phones, tablets, laptops, even home PCs, game consoles, smart devices (IoT), sensors etc. The security of WiFI is imperative, and has been entrusted to the WPA2 protocol. For that protocol, thus far all exploits have been connected to guessing the security key (hence reliant on customers having a weak key) or surrounding technologies (WPS for example) or older implementation such as the TKIP.

None of them were successful against a strong security-minded implementation.

Until today.

The attack – high-level breakdown of how the attack works and which devices are affected

An extremely interesting paper was released (16th October 2017) by its author, Mathy Vanhoef, this paper would rock the world of Wi-Fi as shines light on how to exploit the WPA2 protocol in such a way as to be able to decrypt the user data.

How does the attack work?

The attack does not allow the attacker to join the protected WiFi, nor does it break the encryption key. The attack is focused on the management plane in the WPA2, more precisely on 4-way handshake exchange during the client join.  It is achieved by manipulating and replaying handshake messages. By replaying message 3 of the handshake the attacker has the ability reinstall an already used nonce instead of a fresh key (a replay is allowed by the protocol because messages can be lost due to low signal etc). To guarantee security, an encryption key combination (key+nonce) should be used only once, then different versions of it (different nonce) should be used. Reusing the same key and nonce allows the attacker to derive the keystream, which combined with knowing a portion of the data that is encrypted and the already encrypted data, is enough to decrypt the rest of the data.

The attacker is positioning himself/herself in the middle of the handshake between the AP and the client by using a spoofed WiFI SSID with same name and making the client join his SSID by advising him to switch channels (hence the attack works best if the client has stronger signal to the attacker than to the legit AP). Only when this man-in-the-middle is completed can the attacker manipulate this handshake (as described above) and starting decrypting what the user sends.

Who is affected? – Practically every Wi-Fi enabled client, as again this is an attack towards the WPA2 protocol itself which all vendors needed to follow in their implementations, so this is not a scenario when the exploit is possible due to bugs in the code.

Android and Linux are the ones that are easier to compromise to the fact they mostly (41% of the devices out there) use wpa supplicant version 2.4. With them the code developers have followed a WPA2 standard advice to delete the nonce after its use so when the replay of message 3 happens the nonce that is used is comprised only from zeros making it trivial to decrypt. Further finding from the same author describe the possibility for that attack to work (with few changes) also towards wpa_supplicant 2.6 and iOS and freeBSD clients. This latest update brings the percentage of vulnerable supplicant to a very high number (as the author states, if you have a phone it is most likely vulnerable).

Impact:

We are sending out massive amount of sensitive data using Wi-Fi these days. Username and passwords are just the start, but credit card information, personal IDs, emails, private pictures etc. I guess nobody wants that data to be shared and read by others. Furthermore, the top choice device for many of these, is your smart phone, which in fact is the most vulnerable type of client device (see Conclusions chapter below).

So, what is next?

Do we go back to WPA or WEP or wait for WPA3?

Answer is no, WPA is also vulnerable and WEP is even less secure, WPA2 can be amended (both as a protocol and as implementation in software) and will continue to be used. It is recommended that WPA2 with CCMP is used, as TKIP and GCMP are even easier to break and attackers can not only listen to data but also manipulate data so malware can be injected into the traffic.

How to protect ourselves

Only the software update can mitigate this attack. Keep a close eye to the vendor announcement and patch as soon as they release the security patch for this exploit. Some of the patches may be silently releases and installed on your devices but please make sure you have them.

Actions like changing your PSK password and such do not make any difference (remember, the attack does not reveal this password nor lets the attacker join your network).

Deploy additional levels of encryption that is independent of the WPA2, such as SSL/TLS or IPSec. In the example on the krackattack page, they were only able to read the data from the web site after striping the SSL from it which in fact is a misconfiguration on the website itself.

Conclusion

The current threat is obviously for the end devices, not the infrastructure devices (APs etc). I expect that Microsoft, Apple and other commercial major OS vendors will react very fast and will silently patch (if they have not done so already). That would be sufficient for laptops and PCs with enabled Wi-Fi. A bigger problem will be for smart phone users, every Android vendor (Samsung, HTC etc) dictates its patching schedules, so I am not expecting a fast reaction from them. Apple runs its own devices so I expect faster reaction.

Having put the spotlight on client devices and not infrastructure, it is mandatory to mention that this new type of attack and the sure-to-come spin-offs from it will lead to new attacks towards infrastructure devices.

Cisco has numerous products that are found vulnerable and still investigating many more for that possibility.

Related materials:

https://www.krackattacks.com/

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa

Cisco currently has multiple endpoint security solutions in place – CWS (Cloud Web Security / Scansafe), Umbrella (OpenDNS) and AMP for endpoints are prime examples. AMP is a different breed of endpoint protection, it relies heavily on detection based on heuristics and cloud sandboxing, where as CWS and OpenDNS both concentrate very strongly on making sure your Internet browsing is secure and save.

A bit of history behind the story: when Cisco acquired Scansafe and then sometime later OpenDNS, a lot of people were wondering why Cisco needs two products that have such a large overlap in functionality. At first CWS looked like it was going to last, it had a large customer base, was heavily pushed by Cisco Sales and managed to get a big boost from existing Cisco customers that needed protections for this security gap which was opened by remote/roaming employees.

OpenDNS with most of its customers using the free version seemed like an outsider. It could only detect things based on DNS and was not tunneling any traffic back to the cloud, so it seems like it is not going to be a valid corporate level endpoint protections tool. People underestimated the power of DNS. OpenDNS has something very valuable, via its free version, it had the ability to see a large percentage of worldwide DNS request and using its strong security team it provided a more universal and complete protections that focuses on more than just web browsing. Almost all internet communication is based on DNS, the use of static IPs has been greatly reduced for couple of reasons – for non-malicious users the DNS provides first ease of use and flexibility that static IPs could not, for malicious users – the use of static IPs proved to be unwise as IPs were very quickly blocked (blacklisted) by ISPs and security tools. The result of massive DNS use was that your DNS provider could actively see where your traffic is going and block it (monitoring and enforcement) for all applications (not only Web based).

It was clear Cisco would have to make a choice and I believe they have made the correct one – Cisco is moving forward with the Umbrella and retiring the CWS.

What is Umbrella?

In short, the paid version of OpenDNS, which can support and integrate with other Cisco Products.

How does it work?

It works by forwarding DNS request to OpenDNS servers, either by registering your public IP with Umbrella and forwarding your internal DNS to OpenDNS servers, or by setting your network equipment (DHCP) to directly give out OpenDNS servers for DNS usage, in case the company does not have own internal DNS servers. That secures devices within the offices of the company. For Roaming devices, Umbrella has a Roaming Client (a small agent installed on endpoints, supports Windows and MACs, with vision to support Linux in the future) that makes sure all DNS requests are forwarded to the OpenDNS cloud.

It is very important to note that Umbrella does not work like a traditional Web Proxy, it does not send the all user traffic to the cloud for inspection, it only works and makes decisions based on the information from the DNS requests from the client. User traffic is send for inspection to the cloud only for gray/risky domains (traffic to malicious ones is blocked straight away). Furthermore, this redirection of traffic works for both Agent and Agentless deployments by using the DNS reply to forward the traffic to the Umbrella Cloud proxy service called Umbrella Intelligent Proxy.

The result is a better user experience (instantaneous decision to allow and block traffic to majority of traffic based on good and bad domains), lower deployment complexity and lower operational costs.

How is it configured?

Umbrella is one of the easiest deployments we have seen. It has excellent documentation and simple steps to help you redirect your office traffic to the cloud and deploy Roaming clients to your endpoints. All the management is done via portal in the web (https://dashboard.umbrella.com/). It has a very simple and effective portal layout with intuitive access to both management entities (managed identities and policies) but also monitoring and reporting. A typical simple implementation of Umbrella can be done in a matter of hours, without the need of any on-premise hardware installations (except when AD integration is needed, a lightweight virtual server needs to be installed)

Does it support AD integration for enhanced user visibility?

Yes, it does, it needs a VA (Virtual Appliance, a lightweight virtual server running on either ESX or Hyper-V). The VA servers allows Umbrella to see internal information such as private IP addresses of users and further performs an AD integration with MS AD (servers as a connector) so Umbrella Dashboard can see AD names and be able to define policies based on groups and create reports that include clients AD username (very handy if you want to know who exactly is making all of these malicious outbound requests (such as Command and Control traffic et).

Can it block based on connections that do not use DNS?

Yes, it can, there is a functionality called IP Layer Enforcement that builds IPSEC tunnels to the Umbrella cloud and forward requests to it in case the connection has a suspicious (flagged as malicious) IP address. This is possible only if the client is using Roaming Agent (either the Umbrella one or Anyconnect one).

Does it have integration with other Cisco products?

Umbrella has a module for Anyconnect (Cisco Umbrella Roaming Security module is available for Anyconnect version 4.3 MR1 and newer), which means if the customer has Anyconnect already deployed, there is no need to install Umbrella Roaming Agent. Also, OpenDNS security team is now part of Cisco Talos so OpenDNS both feeds Talos with DNS information but also benefits from Talos to device either certain domain or IP address are deemed risky.

Does it support SSL decryption?

Yes, Umbrella supports SSL decryption so it can do deep inspection for traffic destined for risky/suspicious domains. The configuration of the SSL decryption is very straight-forward, administrators are prompted to download Umbrella (OpenDNS) certificated from the Dashboard and then these certificates need to be installed as trusted on endpoint machines. Next step is just to enable the SSL decryption.

Conclusion:

Umbrella provides enterprise level endpoint security with lower latency than traditional proxies, low capex and deployment costs.

References:

http://www.cisco.com/c/en/us/products/collateral/security/cloud-web-security/eos-eol-notice-c51-738244.html

https://support.umbrella.com/hc/en-us/articles/231246528-Umbrella-Intelligent-Proxy-FAQs

https://umbrella.cisco.com/products/features/intelligent-proxy

https://deployment-umbrella.readme.io/docs/1-introduction

https://deployment-umbrella.readme.io/docs/1-ad-integration-setup-overview

https://deployment-umbrella.readme.io/docs/anyconnect-umbrella-roaming-security-client-administrator-guide

© 4CornerNetworks - Website by Roslin Design
4CornerNetworks is the trading name of 4CornerNetworks Ltd
Registered Address: 27 The Mount, Rickmansworth, Hertfordshire WD3 4DW
Company Registration Number: 07920761
Registered in England
chevron-down