A wireless LAN (WLAN), also commonly called Wi-Fi, is a wireless local area network defined in the various IEEE 802.11 standards and certified by Wi-Fi Alliance. WLAN capability used to be listed using the name of the IEEE standard amendment that it supports. Now the Wi-Fi Alliance uses generational numbering for corresponding technology support: Wi-Fi 4 (for devices implementing IEEE 802.11n), Wi-Fi 5 (IEEE 802.11ac), and Wi-Fi 6 (IEEE 802.11ax). All generations are backward-compatible with the previous versions, which allows a WLAN to consist of devices supporting a mixture of varying 802.11 standards. The access point is the limiting factor in the top speed achievable and security standards available, based on its generation.
Fuzz testing, or fuzzing, is a type of software testing in which deliberately malformed or unexpected inputs are delivered to target software to see if failure occurs. Fuzzing is well-established as an excellent technique for locating vulnerabilities in software. In addition to the security aspect, fuzzing also improves code robustness and performance while it exposes potential design flaws. Synopsys Defensics® is an advanced generational fuzzer. Read more about fuzzing from here.
WLAN protocol fuzzing is critical for security since you can’t protect WLAN networks from malformed or unexpected inputs made by a hacker or a misbehaving device in a heterogeneous network environment. The Wi-Fi Alliance developed three successive technologies aimed at securing wireless networks: Wi-Fi Protected Access (WPA), Wi-Fi Protected Access 2 (WPA2), and Wi-Fi Protected Access 3 (WPA3). The focus of these is to protect the transferred data, not the network protocol itself.
Protocol layers
The IEEE 802.11 standards focus on the data link and physical layers of the OSI reference model. The 802.11 data link layer is divided into two sublayers. The upper portion is the IEEE 802.2 logical link control (LLC) sublayer, which is identical for all 802-based networks. The bottom portion of the data link layer is the media access control (MAC) sublayer. On the 802.11 data link layer, data is handled as bytes. A byte of information consists of 8 bits, also known as an octet.
Figure 1: 802.11 layers
Byte data received from MAC is transmitted as individual bits at the 802.11 physical layer (PHY) by using modulation and coding techniques defined in the standard. The new 802.11ax standard starts a new era on the PHY side by moving from orthogonal frequency division multiple access (OFDM) technology. Wi-Fi 6 devices can understand both modulations for backward compatibility. Simply put, OFDMA is a multiuser version of OFDM. Each user is assigned their own subcarrier frequency, which allows simultaneous data transfer.
In Defensics, fuzzing capabilities for different protocols and layers are packed into user-installable units called test suites. In the Defensics catalog, there are over 250 different test suites, six of which are for WLAN fuzzing. WLAN test suites are divided into access point and client packages, according to the role of the test target. Two suites specialize in testing the MAC layer, and the rest are made for Wi-Fi protection access security testing.
MAC frames
Upper-layer data (for example, an IP packet) received by the data link layer is handed off to the LLC and becomes known as the MAC service data unit (MSDU). When the LLC sublayer sends the MSDU to the MAC sublayer, the MAC header information is added to the MSDU. The MSDU is then encapsulated in a MAC protocol data unit (MPDU). A simple definition of an 802.11 MPDU is that it’s an 802.11 MAC frame.
Each MAC frame consists of the following basic components:
- A header, which comprises frame control, duration, address, and some optional fields
- A variable-length frame body, which contains information specific to the frame type and subtype
- A frame check sequence (FCS), which contains a 32-bit CRC
The MAC frame with MSDU is called a data frame. Data frames are one of the three major types of MAC frames. The others are management frames and control frames. Each major type of frame has many subtypes, and all of them have their own specification about the frame content and purpose.
On the PHY layer, the MAC frame is prepared for transmission by taking the frame from the MAC sublayer and creating the PLCP protocol data unit (PPDU), also known as a PHY frame. The PHY frame contains all bits sent over the air by using radio characteristics according to the 802.11 extension indicated in the PLCP header.
Fuzzing on the PHY layer leads to radio jamming—blocking or interfering all radio signals on the range—which is outside the scope of Defensics testing. Fuzzing on the MAC layer can cause crashes, slowness, or other unwanted behavior on the system, exposing vulnerabilities like CVE-2018-18907 and CVE-2019-18989, CVE-2019-18990, CVE-2019-18991.
Fuzzing on the MAC layer
According to the standard, 802.11 stations shall decode properly constructed MAC frames on reception. That means if PHY characteristics (for example, channel and modulation) are the same, all WLAN devices on the radio range will receive the MAC frame sent and start decoding them.
On decoding, the first receiver ensures that the frame is not corrupted using transmission. That is done by comparing the CRC to the FCS field on the frame. If the FCS matches, the fixed-length frame control field is read. The frame control field contains information about how to decode the rest of the frame. The type of frame is the most significant information since the bit fields on the frame control field will get different meanings depending on the frame type.
After frame type identification, the decoding process checks the frame address. The address, which can be a unicast or broadcast destination, determines if the frame should be handled on this station, or on another station so this station can stop processing the frame. If the address matches, the sequence number, which should be increasing for each new frame, is checked to ensure that the frame is not already handled by the station. If the frame is for the station and it was not already handled, the decoding process continues to the remaining fields in the frame. Depending on the frame type, those can be fixed-length fields or a set of information elements implementing the type-length-value (TLV) pattern.
Figure 2: PHY and MAC frames
When fuzzing MAC frames, it’s extremely important to ensure specification compliance of the frame format during anomaly (test case) creation. If the fuzzer is changing frame content randomly, it could easily lead to a situation where the frame structure doesn’t correspond to its type. This will cause the decoding to stop at the frame level before entering subroutines. But this isn’t a problem with Defensics’ anomalization engine—it applies an intelligent generation-based fuzzing method, with the IEEE 802.11 specification as model. Test suites can create all frame types, and built-in rules ensure that the frame itself is properly constructed, including checksum and length calculations, even when the data inside the frame is purposefully malformed.
Comparing frame types
- Data frames. Of the three frame types, data frames are the most straightforward to handle on the MAC layer, although aggregation adds complexity. The purpose of the frames is to pass encapsulated data to the upper layer. If Wi-Fi protected access is enabled, data is decrypted before passing it forward.
- Management frames. These frames are handled on the MAC layer and contain information to join and leave the network. This procedure is equivalent to disconnecting and connecting a network cable on a wired network. There are 14 different types of management frames, and each one contains a number of fixed and variable-length information elements. For example, a beacon frame, typically sent every 100 milliseconds by each access point, can contain 87 unique variable-length information elements. As an example, the very high throughput (VHT) capability element is used to indicate that the access point supports the very high throughput capabilities defined in the 802.11ac standard. The VHT capability element has 4 octets for VHT capabilities information, and 8 octets for supported VHT-MCS and NSS set. The 4 octets on VHT capabilities information are divided into 20-variable-wide bit fields, and each field has its own meaning for MAC layer functionality.
- Control frames. This type of frame assists the delivery of data and management frames. Control frames perform multiple operations including clearing the channel, acquiring the channel, and doing unicast frame acknowledgments. Unlike management and data frames, control frames don’t have a frame body.
Different frame formats, information elements, and some fixed fields make a complex set of parsing instructions. The long history and backward-compatibility of the standards often leads to a complex 802.11 software stack, typically written with the C language. Stack implementations can be divided into radio and host hardware. In such an environment, fuzzing is an excellent testing method to find issues in buffer handling and input validation.
State machine
A properly constructed MAC frame is not enough when aiming to reach high code coverage on the test target. The 802.11 station has different states, and allowed frame types are highly state-dependent. The station is either authenticated or unauthenticated and can be associated or unassociated.
These two variables can be combined into three states:
- Not authenticated and not associated (initial state)
- Authenticated but not yet associated
- Authenticated and associated
In the third state, all frame types are accepted. If Wi-Fi protected access is enabled, a four-way handshake begins, which can be considered as a fourth state transition. A four-way handshake creates encryption keys to secure the actual data transferred over the network.
Figure 3: MAC state machine
The MAC sublayer management entity (MLME) is the management entity in which the MAC state machines reside. Defensics test suites have built-in MLME for sending and receiving valid MAC frames until the test target is in a proper state to receive malformed frames. From an access point (AP) testing perspective, if the test case target is an association request frame, the test suite first sends a valid probe request frame and waits for the answer from the AP. After a proper answer, a valid authentication frame is sent, and a response is handled. Then the system under test (SUT) is in the correct state to receive malformed or unexpected input, which can be a one-bit manipulation on the association request frame or a huge buffer overflow on the frame. After the anomaly frame is sent, the state is reset by sending a valid deauthentication frame. After each test case, valid case instrumentation and optional feedback from the test target can be used to determine if the malformed data cause problems on the target. Anomalous (out of spec) behavior may be very apparent (for example, a hardware crash), or it can be detected with special tools (for example, memory leaks).
Figure 4: Example message sequence for association request fuzzing
Ensure security
The most commonly used version of the Wi-Fi protected access is now WPA2, but today's high-end devices are shipping with WPA3 support. We have written about these in our earlier post.
The Wi-Fi protected access doesn’t protect the network from fuzzing. All the MAC frames are still handled by stations, but the data from data frames isn’t sent on the upper layer if the correct cryptographic keys aren’t known by the data sender. The only exception is the protected management frames (PMF) feature, which is specified in IEEE 802.11w and becoming mandatory with WPA3. Protected management frames provide protection for some management frames like disassociate and deauthenticate, but the frames required for a four-way handshake cannot be protected.
When correctly implemented, this standard protects against eavesdropping and some known forgery attacks. This prevents an attacker from dropping existing client connections with the access point by sending a deauthentication frame to the client.
The Defensics WPA3 test suite is focused on Dragonfly-like and four-way handshake fuzzing, and the built-in MLME handles state transition for both PMF and non-PMF test targets.
WLAN testing with Defensics test suites
Defensics fuzz testing is a comprehensive, powerful, and automated black box solution that enables organizations to effectively and efficiently discover and remediate security weaknesses in software. Defensics has an intelligent fuzzing engine that can produce many different types of anomalies including absolute maximum and minimum values, underflows, overflows, and repeating data. The protocol model ensures that despite the anomaly, all the checksums, lengths, and identifiers are correctly calculated. The Defensics platform can collect healthy information from test targets in several ways, explained in detail here. You can use Defensics at any phase of the development life cycle with the standalone GUI, on the command line, or via APIs.
There are over 250 different prebuilt fuzzing test suites available. The test suites for WLAN fuzzing are:
- FuzzBox 802.11 WLAN AP or client: For WLAN connection testing
- FuzzBox 802.11 WPA2 AP or client: For WPA and WPA2 four-way handshake testing
- FuzzBox 802.11 WPA3 AP or client: For WPA3 Dragonfly and four-way handshake testing
All Defensics platform features are also available for WLAN testing.
WLAN testing requires additional hardware support to enable modified MAC frames to be sent over the air. The Defensics WLAN offering includes 802.11ac USB WLAN adapters and FuzzBox OS ISO images to provide a complete test setup. FuzzBox OS is installed on a standard x86-64 PC with a WLAN adapter connected. The Defensics GUI and test suites run on the user PC using FuzzBox to send test data over the air. The user PC and the FuzzBox PC are connected using a direct network cable or a routed network. This setup ensures the FuzzBox PC and the tested target are located away from the user PC. For example, the FuzzBox PC and the test device could be inside a Faraday cage, or the FuzzBox PC could be in a test lab while the user PC is at the user’s home office.
Figure 5: FuzzBox OS provides an easy and extendable test setup for WLAN testing
A FuzzBox test setup with multiple WLAN adapters supports parallel test runs. All FuzzBox WLAN test suites support both 2.4 GHz and 5 GHz radio bandwidths, and control and management frames on 802.11a/b/g/n/ac/ax standard level.
Conclusion
It’s important to remember that there is no way to prevent attackers from sending invalid or malicious MAC frames to any WLAN device. Wi-Fi protected access protection is for the data itself and not for the protocol. Therefore, it’s critical to fuzz test lower levels of the WLAN protocol, although it’s also vitally important to test parts where encryption is being negotiated.
A MAC frame is a basic data unit for WLAN traffic. There are multiple types of frames, each with its own purpose and complex internal structure. Some frames control the connection state, and some are used to establish a secure connection. Random fuzzers are not sufficient with such a protocol—you need a model-based and state-aware fuzzing tool. Defensics FuzzBox 802.11 test suites will get the job done.
Continue Reading
Accelerate application code fixes with AI-powered Polaris Assist
