Intro
The wireless security landscape has remained largely unchanged since the development of Wi-Fi Protected Access (WPA/WPA2) in the early 2000s. However, in recent years the Wi-Fi alliance has made significant efforts to address long standing issues within these standards. In this entry I will shed some light on common infrastructure configurations, their associated weaknesses, and practical attacks against wireless networks. In part 2, I will take a more in depth look at new wireless standards and the implications for securing networks using them.
WPA2
First ratified by the WiFi Alliance in 2004, the WPA2 standard was developed to address weakness in the WEP protocol. WPA2 can be configured in two modes WPA2-Personal and WPA2-Enterprise. Lets discuss the common WPA2 configurations which can be found almost universally on both personal and enterprise grade infrastructure. We will also discuss practical attacks against these common configurations and how to defend against them.
WPA2-Personal
The most common configuration which can be employed across wireless devices of all types is WPA2 Preshared Key authentication (WPA2-PSK). In this configuration, both station and access point are provided a hard copy of the key. In order to authenticate and prove to each other that they both have the same key, thus providing mutual authentication. This handshake in intended to provide authentication without disclosing key material. However, weaknesses in in this handshake protocol can allow enough information can be obtained by passively listening to the radio traffic to conduct offline attacks against captured WPA2-PSK handshakes. In 2018, this type of attack became even more effective with the discovery of the PKMID attack[1]. The PKMID method is only effective against networks which support roaming, but can allow an attacker to quickly obtain crackable material without sniffing clients actively authenticating to the network. These methods are the traditional attacks deployed against WPA2-PSK networks and can be effective against networks configured with weak passwords. Luckily, computing WPA2-PSK is relatively slow and brute force attempts remain inefficient even with modern hardware.
There remain other security implications with the WPA2 protocol outside of this glaring deficiency. Firstly, pre-shared keys are inherently insecure since each host uses the same authentication token. The network is always one compromised host away from a breach in the network’s encryption and authentication.
Compromising WPA2 Keys on Remote Windows HostAdditionally, preshared key authentication provides no means for individual revocation, if a host is compromised or a user’s access needs to be revoked then keys must be rotated across all stations. Another weakness with WPA2-PSK configuration is that the encryption uses does not provide forward secrecy[2]. This means that an attacker can passively record network communications, then compromise a key later on and still decrypt the traffic.
WPA2-Enterprise
The WPA2-Enterprise mode provides more robust security configuration options. There are nearly an infinite number of ways to configure the authentication mechanism for enterprise networks due to the support for many different EAP methods. The most common configurations utilize a RADIUS server that handles authentication requests. Taking a look under the hood, a client station will attempt to associate to an access point which then facilitates an EAP negotiation with the backend RADIUS server. During this negotiation, one of many EAP methods is agreed upon by the Authentication Server (AS) and the client station. Due to the shear number of possible EAP methods, let us consider the most common configurations which can be encountered in a typical enterprise environment.
PEAP/MsCHAPv2
When integrating with Active Directory, a typical configuration will rely on the PEAP/MsCHAPv2 method. This particular method has several structural weaknesses. Firstly, it must be configured to enforce server certificate validation which will allow some clients to communicate with Rogue access points. Secondly, the underlying MsCHAPv2 handshake utilizes DES encryption to protect Active Directory NT hashes. DES encryption is known to be compromised since as early as 1999.[3] A quick glance at the MsCHAP handshake flow below and you may spot the issue, despite the protocols requirement for mutual authentication, the Challenge Hash, Challenge Response, and username are all sent before any verification of who the server is.
MsCHAPv2 Handshake Flow
Services such as crack.sh will even brute force MsCHAPv2 handshakes in approximately 26 hours. Additionally, tooling exists to check handshakes against known weak NT hashes, which can then be cracked on their own or be used in pass-the-hash authentication[4]
If the user’s password is weak enough, an attacker may even be able to utilize cracking to conduct a true man-in-the-middle attack by offloading the MsCHAP handshake to a cracking rig, then quickly completing the CHAP handshake to establish authentication with the client. For example, this can be accomplished using EAPHammer’s AutoCrack n’ Add feature[5].
EAP Downgrade
Another practical attack that can be deployed against WPA2-Enterprise networks is known as an EAP-Downgrade attack. This again targets clients which are not properly enforcing server certificate validation. By offering a weaker alternative EAP method, such as EAP-GTC. A client may prompt a user for a username and password which could then be sent without any protections in cleartext to the Rogue AP. Below is an example of the what the EAP-GTC prompt looks like on iOS devices. Client devices which are configured to ignore server certificate validation and not to require a specific EAP method could be prompted for their credentials with no warnings.
Defending WPA2-Enterprise
Configuring secure WPA2-Enterprise environments relies on enforcing a few core concepts. Firstly, configuring clients to ensure mutual authentication prevents the above attacks. Requiring client stations to verify the access point with which they are communicating will prevent the disclosure of MsCHAP handshakes along with preventing the negotiation of a weak EAP method. Administrators should also consider moving away from these problematic EAP methods altogether, configuring EAP-TLS or certificate based authentication enforces server validation by default. Another option is to consider deploying a Wireless Intrusion Prevention System (WISP) which can automatically detect, alert on, and counteract Rogue AP deployments.
In conclusion, WPA2 networks have inherent weaknesses which can be mitigated through secure configurations. Careful consideration of the security implications of the different WPA2 modes can help avoid common pitfalls. When choosing pre-shared key authentication, avoid its use on sensitive enterprise assets and enforce the use of a strong key which is rotated regularly. If enterprise authentication is right for your needs, consider implementing a secure EAP method like EAP-TLS.
In our next entry, we’ll discuss the improvements implemented in the new WPA3 standard and how proper configurations can help to secure wireless infrastructure.