Vulnerability - Aruba Networks

DeAgg vulnerability - Advisory CVE-2020-24588
AA Technical Bulletin 210519-01

Download AATB-210519-01-DeAgg vulnerability Version 1 (pdf) >>


** This Technical Bulletin shall not replace any information or handling instructions provided from the manufacturer. Please see this paper as additional resource to help you to solve the issue. Also consider the newest Release Notes published by manufacturer to be sure that your environment is eligible for the update.
**Please note that upgrading the infrastructure is only one part of the solution. All 802.11 client
devices should be upgraded. Only the complete upgrade of all device will ensure security regarding
802.11 Security Advisory.

A. Introduction
A.01 About DeAgg vulnerability
A.02 Reason
A.03 General Approach
A.04 Prerequisites
A.05 Aeroaccess Risk Assessment
A.06 Detailed description
B. Aruba Deployment
B.01 Aruba Affected Devices
B.02 Aruba Solution
B.03 Aruba Workaround
B.04 Aruba Implementation
B.05 Upgrade Aruba Firmware
C. Aeroaccess Recommendation
C.01 Background Information
C.02 Pre-Test
C.03 Contract Status
C.04 Recommendation for Service Units
C.05 Deployment Phase 1
C.06 Deployment Phase 2


A. Introduction
A.01 About DeAgg Vulnerability
On May 11, 2021, the Industry Consortium for Advancement of Security on the Internet (ICASI) announced the coordinated disclosure of a series of vulnerabilities related to the functionality of Wi-Fi devices. Exploitation of these vulnerabilities may result in data exfiltration.


Regarding these issues listed above, only CVE-2020-24588 affects Mist Networks Access Points (APs). However, be aware that all devices using 802.11 chipsets, also client devices, are affected and shall be upgraded. Successful exploitation of CVE-2020-24588 may allow an attacker to inject arbitrary network packets which could be used to spoof servers and conduct man-in-the-middle (MITM) attacks, in protected Wi-Fi networks, including WEP, WPA, WPA2, and WPA3.

A.02 Reason
The DeAgg vulnerability, is a vulnerability discovered in the 802.11 protocol, specifically in the implementation of aggregated frames. The vulnerability could allow an attacker to flip the "is aggregated" flag in the 802.11 header, which would cause the frame payload to be parsed differently and potentially allow for packet injection.

A.03 General Approach
In general, the scope of these attacks is that they may allow an attacker to inject L2 frames that they can more or less control (depending on the vulnerability and attack method) into an otherwise protected network.

Exfiltrate (some) network data under certain conditions; this is specific to the fragmentation issues. A subset of these issues is known to apply to the Linux IEEE 802.11 implementation (mac80211). Where it is affected, the attached patches fix the issues, even if not all of them reference the exact CVE IDs. 


In addition, driver and/or firmware updates may be necessary, as well as potentially more fixes to mac80211, depending on how drivers are using it.

A.04 Prerequisites
• All devices which are using 802.11 protocol with Firmware not using the related Security Patches.
• Attacker is located close to the attacked devices (man-in-the-middle).


A.05 Aeroaccess Risk Assessment
The risk of a successful attack is MEDIUM, as the vulnerability requires an attacker to take a man-in-themiddle position, and also a webserver under the control of the attacker. The client would need to connect to the man-in-the-middle AP, and in some way visit the attacker's webserver. Subsequently a specially crafted packet with injected data is sent to carry out additional attacks.

A.06 Detailed Description
The vulnerabilities are not dependent on one another. Exploitation of one of the vulnerabilities is not required to exploit another vulnerability. In addition, a software release that is affected by one of the vulnerabilities may not be affected by the other vulnerabilities. 

Vulnerabilities in the implementation of the IEEE 802.11 standard have been uncovered. These vulnerabilities allow an attacker to inject malicious frames in a legitimate Wi-Fi connection, regardless of the type of wireless encryption used. 

Successful exploitation of these vulnerabilities results in exfiltration of sensitive data or, in conjunction
with other known attacks, allows for traffic manipulation.
Note that these vulnerabilities might also affect wireless client devices. Non-Juniper/Mist devices may
also have fixes for these vulnerabilities.
The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired
Equivalent Privacy (WEP) doesn't require that the A-MSDU flag in the plaintext QoS header field is
The 802.11 standard allows for fragmentation of data frames that are larger than a particular value (known as the fragmentation threshold) into more than one MPDU for transmission over the air. On the receiving device, these fragments are then reassembled into the original data frame and passed to the higher layers of the stack. The MAC header includes a Sequence Number (SN) subfield for ordering of the MPDUs irrespective of whether they contain fragmented or unfragmented data. To facilitate fragmentation, the MAC header also includes a Fragment Number (FN) subfield in addition SN – fragments of one data frame have the same SN but different FN. Once encrypted, the MPDUs also have a Packet Number (PN) which is again a consecutively increasing number used for checking against replays. Together, PN are expected to increase linearly with FN and SN. The Juniper/Mist Access Point does not check whether all fragments of a frame have consecutive PN, that is, whether the fragments indeed belong to the same frame or not. Consequently, the attacker using a MitM (Machine-in-the-Middle) technique can abuse this vulnerability by mixing fragments of different packets in order to extract user data.

Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets, by accepting non-SPP A-MSDU frames. Attackers can exploit this and get devices to aggregate frames that appear to come from the same source, but don't, allowing for manipulation of the payload. A complete description for the DEAGG
VULNERABILITY you can find here:

See the accompanying FAQ document published by Aruba for more detailed information:



 B. Aruba Deployment
B.01 Aruba Affected Devices
All Aruba Instant Access Points:
- Aruba Instant 6.4.x: prior to
- Aruba Instant 6.5.x: prior to prior to if using IAP-1xx series
- Aruba Instant 8.3.x: prior to prior to if using RAP-155 series
- Aruba Instant 8.5.x: prior to prior to if using RAP-155 series
- Aruba Instant 8.6.x: prior to prior to if using RAP-155 series
- Aruba Instant 8.7.x: prior to

All ArubaOS Access Points when managed by hardware or virtual implementations of Aruba Mobility
Controllers (standard or FIPS):
- ArubaOS 6.4.x: prior to
- ArubaOS 6.5.x: prior to
prior to if using AP-1xx series
- ArubaOS 8.3.x: prior to
prior to if using AP-1xx series
- ArubaOS 8.5.x: prior to
prior to if using AP-1xx series
- ArubaOS 8.6.x: prior to
prior to if using AP-1xx series
- ArubaOS 8.7.x: prior to

Aruba Instant On:
- prior to 2.3.0

B.02 Aruba Solution:
The following firmware versions for the Aruba Access Points have been updated to resolve this specific issue (CVE-2020-24588).

B.03 Aruba Workaround
There are no known workarounds for this issue. Only upgrades to released versions will fix the issues.

B.04 Aruba Implementation
Complete information on reporting security vulnerabilities in Aruba Networks products, obtaining
assistance with security incidents is available at:


B.05 Upgrade Aruba Firmware
On the following link you can find related Information which Firmware Version you should deploy to solve the issue:


C. Aeroaccess recommendation
C01. Background Information
These Security Vulnerabilities cause special activities on the manufacturer side outside their planned Software releases. Also, when in this case, the manufacturers have been informed some months before, it also causes urgent activities, which may not always fit with the quality control of standard releases. In order to reduce the risk level for our customers, especially in production or business critical environments, Aeroaccess has made additional efforts deploying and testing the new Firmware releases.

C.02 Pre-Test
Aeroaccess has made different Pre-Tests in our Lab environment to find interoperability issues or other problems:
• we did not find any problems during the update procedure.
• downgrade to recommended version was possible
• downgrade to previous release was also possible
• we did not find any problems connecting the APs after rebooting (max two reboots)
• we did not find any problems connecting the clients to the APs (limited number of lab clients)
• we did not find any problems with the client roaming
• we did not find any problems connecting to the (private) cloud
• we did not find any problems with resolving DHCP and DNS (also ARP)
• we did not find any problems with client association, uplink and downlink
• we did not find any problems with throughput and capacity of the APs

C.03 Contract status
For the customers without a valid Service Contract for the affected products, Aruba says: "In this circumstance, Aruba will provide software updates to anyone who requests it, regardless of support contract status. Contact Aruba Support through one of the phone numbers listed at"

For the customers with any valid Service Contract (PBS, FC) for the affected products, Aeroaccess is allowed to deliver the recommended Firmware version per your request.

For the customers with valid Premium Service Contract (APS) for the affected products, Aeroaccess will offer proactive update procedures and support on the individual customer status.


C.04 Recommendation for Service units
In the case that the upgrade may fail and cause Hardware failure, you should have spare units available to cover your business-critical services. If your existing Contract with Aeroaccess does not cover Advanced Hardware Replacement (AHR) you can contact our sales ( to receive the quote for AHR service.

C.05 Deployment Phase 1
You should plan to deploy the new firmware update first in the Lab environment or in non-production critical environment. However, these vulnerabilities might also affect wireless client devices, and those non-Aruba devices should also have fixes for these vulnerabilities. Make sure that you test all your wireless client devices in this lab environment, to guarantee the internal operability.

For the customers with valid Premium Service Contract (APS) for the affected products, Aeroaccess will offer individual testing with their configuration in Aeroaccess Lab.

C.06 Deployment Phase 2
Before you start final global deployment, you should prepare you environment for the update and be ready for a short network outage (global reboot of all Controller, VCs, MCs, APs).
If you need our direct phone support, please make sure before you start upgrade, that your contract covers this option. In other cases, you can request a quote for TSE support per hour (

For the customers with valid Premium Service Contract (APS) for the affected products, Aeroaccess will offer individual support windows to schedule deployment and to make sure that one of our TSE support you on this procedure. We will get in contact with you within next few days to discuss the complete approach and to define the time frame for the update.

For detailed descriptions and instructions of the different available upgrade procedures please contact our Support Team via

Aeroaccess would be happy to provide support and give according guidance.
*In case you get an offer for direct manufacturer support, it's your responsibility and decision how to