TLStorm 2.0: Critical bugs in widely-used Aruba, Avaya network switches
Armis researchers have discovered five critical vulnerabilities in the implementation of TLS communications in multiple models of network switches. Collectively dubbed TLStorm 2.0, the vulnerabilities stem from a similar design flaw identified in the TLStorm vulnerabilities expanding the reach of TLStorm to millions of additional enterprise-grade network infrastructure devices.
The good news, though, is that there is no indication they’ve been exploited by attackers in the wild.
In March 2022, Armis first disclosed TLStorm, three critical vulnerabilities in APC Smart-UPS devices that allow an attacker to gain control of them from the internet with no user interaction, resulting in the UPS overloading and eventually destroying itself in a cloud of smoke.
The root cause for these vulnerabilities was a misuse of NanoSSL, a popular TLS library by Mocana. Using the Armis knowledgebase, their researchers identified dozens of devices using the Mocana NanoSSL library. The findings include not only the APC Smart-UPS devices but also two popular network switch vendors that are affected by a similar implementation flaw of the library. While UPS devices and network switches differ in function and levels of trust within the network, the underlying TLS implementation issues allow for devastating consequences.
The new TLStorm 2.0 research exposes vulnerabilities that could allow an attacker to take full control over network switches used in airports, hospitals, hotels, and other organizations worldwide. The affected vendors are Aruba (acquired by HPE) and Avaya Networking (acquired by ExtremeNetworks).
The researchers have found that both vendors have switches vulnerable to remote code execution (RCE) vulnerabilities that can be exploited over the network, leading to:
- Breaking of network segmentation, allowing lateral movement to additional devices by changing the behavior of the switch
- Data exfiltration of corporate network traffic or sensitive information from the internal network to the Internet
- Captive portal escape. Once the attacker has control over the switch, they can disable the captive portal altogether and move laterally to the corporate network.
Vulnerability details and affected devices
CVE-2022-23677 (9.0 CVSS score) – NanoSSL misuse on multiple interfaces (RCE)
The NanoSSL library mentioned above is used throughout the firmware of Aruba switches for multiple purposes. The two main use cases for which the TLS connection made using the NanoSSL library is not secure and can lead to RCE:
- Captive portal – A user of the captive portal can take control of the switch prior to authentication.
- RADIUS authentication client – A vulnerability in the RADIUS connection handling could allow an attacker that is able to intercept the RADIUS connection via a man in the middle attack to gain RCE over the switch with no user interaction.
CVE-2022-23676 (9.1 CVSS score) – RADIUS client memory corruption vulnerabilities
RADIUS is an authentication, authorization, accounting (AAA) client/server protocol that allows central authentication for users who attempt to access a network service. The RADIUS server responds to access requests from network services that act as clients.
The RADIUS server checks the information in the access request and responds with authorization of the access attempt, a rejection, or a challenge for more information.
There are two memory corruption vulnerabilities in the RADIUS client implementation of the switch; they lead to heap overflows of attacker-controlled data. This can allow a malicious RADIUS server, or an attacker with access to the RADIUS shared secret, to remotely execute code on the switch.
Aruba devices affected by TLStorm 2.0:
- Aruba 5400R Series
- Aruba 3810 Series
- Aruba 2920 Series
- Aruba 2930F Series
- Aruba 2930M Series
- Aruba 2530 Series
- Aruba 2540 Series
The attack surface for all three vulnerabilities of the Avaya switches is the web management portal and none of the vulnerabilities require any type of authentication, making it a zero-click vulnerability group.
CVE-2022-29860 (CVSS 9.8) – TLS reassembly heap overflow
This is a similar vulnerability to CVE-2022-22805 that Armis found in APC Smart-UPS devices. The process handling POST requests on the webserver does not properly validate the NanoSSL return values, resulting in a heap overflow that can lead to remote code execution.
CVE-2022-29861 (CVSS 9.8) – HTTP header parsing stack overflow
An improper boundary check in the handling of multipart form data combined with a string that is not null-terminated leads to attacker-controlled stack overflow that may lead to RCE.
HTTP POST request handling heap overflow
A vulnerability in the handling of HTTP POST requests due to missing error checks of the Mocana NanoSSL library leads to a heap overflow of attacker-controlled length, which may lead to RCE. This vulnerability has no CVE because it was found in a discontinued product line of Avaya meaning no patch will be issued to fix this vulnerability, though Armis data shows these devices can still be found in the wild.
Avaya devices affected by TLStorm 2.0:
- ERS3500 Series
- ERS3600 Series
- ERS4900 Series
- ERS5900 Series
Updates and mitigations
Aruba and Avaya collaborated with Armis on this matter, and customers were notified and issued patches to address most of the vulnerabilities. To the best of our knowledge, there is no indication the TLStorm 2.0 vulnerabilities have been exploited.
Organizations deploying impacted Aruba devices should patch impacted devices immediately with patches in the Aruba Support Portal.
Organizations deploying impacted Avaya devices should check security advisories immediately in the Avaya Support Portal.
Armis customers can immediately identify devices that are vulnerable in their environments and begin remediation.
“The TLStorm set of vulnerabilities are a prime example of threats to assets that were previously not visible to most security solutions, showing that network segmentation is no longer a sufficient mitigation and proactive network monitoring is essential,” said Barak Hadad, Head of Research, Armis.
“Armis researchers will continue to explore assets across all environments to make sure our knowledgebase of more than two billion assets is sharing the latest threat mitigations to all of our partners and customers.”