WPA2 encryption bypass: Using Defensics to uncover behavioral vulnerabilities

As part of Defensics SafeGuard development, we uncovered a vulnerability in D-Link DIR-850L Wireless AC routers with hardware revision A. The vulnerability gives an attacker full access to a wireless network without needing credentials. Our method skips a critical step during access point connection, bypassing encryption altogether.

After identifying this vulnerability, Synopsys pursued coordinated disclosure with National Cyber Security Centre Finland (NCSC-FI) with the assigned identifier of CVE-2018-18907. We worked with D-Link to reproduce the issue, and on Nov. 6, 2018, D-Link made a fix available for the affected devices.

WPA2 is encryption technology used in WLAN network communication between a client and an access point (AP). To connect to each other, both the AP and client need to know a pre-shared key (PSK), which they exchange in a WPA handshake before opening an encrypted channel between them.

Normally, breaking WPA2 encryption requires performing an air capture on an AP and client (also known as a supplicant) where the full handshake is visible, or just fetching the pairwise primary key identifier (PMKID) from the AP. Once this is accomplished, you have all the information needed for brute-forcing the WPA2 PSK. The time needed to obtain the PSK depends on your hardware and the PSK length. But sometimes getting past WPA2 encryption takes a bit of luck, and it happens in less than a second.

Normal day at the office

In early August of 2018, I was finishing up new versions of the test suites for Defensics fuzz testing, which provides fuzzing for a wide variety of protocols. Fuzzing is a testing method where the tool sends malformed inputs to discover potential security vulnerabilities in software. This malformed input, comprising unexpected or invalid data, is called an anomalous test case.

Some of my last additions to the test suite were a couple of new anomalous test cases and SafeGuard results. SafeGuard is a patented feature that allows Defensics to recognize situations that go against the specification or best practices—for example, when the system under test (SUT) selects a weak encryption scheme, or when authentication credentials are sent in plaintext.

RELATED: How does SafeGuard differ from fuzz testing?

The new versions of the Defensics 802.11 test suites contained two critical improvements. The first was WPA2 encryption for data frames after a WPA2 handshake. The previous version only calculated a temporal key for a session, and this information could be written to a file. This allowed the tester to verify that both Defensics and the SUT had the same temporal key. But sending encrypted data frames automatically tests correct keys, since encryption and decryption on both ends requires knowing the key. The second improvement was a simple DHCP discovery sequence on top of IPv4. This DHCP sequence verifies that the SUT receives data frames and checks for responses. Since DHCP itself is quite complex, I first implemented it without encryption, and after the DHCP sequence worked, I added the WPA2 AES CCMP encryption to the test.

The discovery

I was adding a weak encryption SafeGuard for WPA1, since WPA1 is known to have weaknesses and should not be used. The same goes for WEP encryption: It should not be used anymore. The Defensics 802.11 test suites now had weak encryption detection, and I ran a couple of cases to test it against the AP that just happened to be on my desk, a D-Link DIR-850L. I assumed that weak encryption would be detected, since I had configured my SUT AP to have WPA1 and nothing else.

As I thought, Defensics detected weak encryption correctly. But then the AP accepted the DHCP discovery sequence without WPA encryption. This particular test case was negotiated to use WPA1 encryption, but it did not contain actual encryption: The DHCP discovery sequence was sent as plaintext to the AP. I was surprised by this test result, since the router should have required WPA1 encryption. I then used Wireshark, a tool for capturing frames from the air, to rerun the test case and check the result. In the results I saw the IP address the AP was offering to Defensics, the router IP address, lease times, and so on. The discovery sequence was again sent in plaintext. Then I changed encryption from WPA1 to WPA2 to see whether that made a difference in SUT behavior. Again, the discovery sequence was still sent in plaintext, so something was wrong. The AP also supported WPA Enterprise, and testing in that mode did not change the behavior—the sequence was still sent in plaintext.

The analysis

The next question was, of course, what was happening and why was it possible? Connecting to an AP is done in two phases. First, the client and AP agree on the connection parameters and what encryption to use. Second, they perform a so-called WPA handshake or four-way handshake, where they exchange the encryption parameters and make sure they both have the PSK. After this, they open an encrypted data connection. But the test case I was running skipped the WPA handshake, so something had to be happening before the handshake, where the AP and client agreed on the connection parameters and what encryption to use.

The first phase consists of a probe request and response, an authentication request and response, and finally an association request and response. The main purpose of the probe request is just to discover the AP. The probe response then contains all the information about the AP, including which encryptions are supported. The next request-response pair is authentication, the purpose of which is to ensure backward compatibility. The next thing is the association request and response. In the association request, the client tells the AP which encryption and what parameters it wants to use. The association request also opens the data connection between the AP and client.

The test case I was running had a normal probe request and authentication request. Then the association request claimed that the client supported WPA1 encryption. At this point, the WPA handshake is supposed to happen, but since my test case skipped the handshake, the AP and client started to send data frames without any encryption.

The exploit

Getting an IP address from a protected network without credentials is already a bad thing, but was it possible to do something else? I decided to create an exploit for this vulnerability. My idea was to create a custom version of wpa_supplicant (the default WLAN client in the Linux operating system). First, I tried to modify wpa_supplicant so it would just ignore the WPA handshake, but that turned out to be really difficult. There were too many checks that made sure that the WPA state machine was in the correct state. This confirmed that what I was trying to do is not common. The next thing I tried was making a connection without encryption but modifying the association message that contains the encryption parameter. This was the same thing the Defensics test suite was doing in the test case. I just needed to remove a couple of the checks for encryption parameters not being negotiated, and I was able to make the connection.

Now I had a modified version of wpa_supplicant that gave me the full Linux IP stack on the network interface. First, I tried to connect to the AP admin panel. I connected, but also I noticed that there was window of three to six seconds when plain data frames were accepted by the router before it kicked out the rogue client. Nevertheless, wpa_supplicant automatically reconnected, and my exploitation continued. In fact, the reconnection was so fast that even the TCP connection stayed open.

Additionally, I connected two more devices to the AP, one wired and one through WLAN. From the rogue client, I could connect both devices without any problem. From the router admin panel, I saw that the rogue client was recognized as any other client connected to the router. So with this exploit, I had full access to the network without knowing the pre-shared key. I did not need to do any time-consuming brute-forcing—I just connected to the network.