TLS implementation flaws open Aruba and Avaya network switches to RCE attacks

Multiple series of network switches manufactured by Aruba Networks, owned by Hewlett Packard Enterprise, and Avaya, owned by Extreme Networks, are vulnerable to attacks that could allow attackers to break network segmentation, exfiltrate data from internal networks to the internet, and escape captive portals. The flaws stem from mistakes made by the vendors when implementing a popular embedded TLS library.

The vulnerabilities are rated critical and can lead to remote code execution (RCE), according to researchers from security firm Armis who found them. These flaws, collectively dubbed TLStorm 2.0, could enable attackers to take full control, often without authentication, of switches that are deployed in a wide variety of enterprise networks and are also used to isolate public-facing network segments in airports, hospitals, hotels and other organizations.

“In the last few months, we have seen an increasing number of vulnerabilities in popular libraries, with the two most notable ones being Log4Shell and Spring4Shell,” the Armis researchers said in their report. “While it’s clear that almost every software relies on external libraries, these libraries introduce new risks to the hosting software. In the case of Mocana NanoSSL, the manual clearly states the proper cleanup in case of connection error, but we have already seen multiple vendors not handling the errors properly, resulting in memory corruption or state confusion bugs.”

What are NanoSSL and TLStorm?

NanoSSL is a closed-source highly performant TLS library for embedded devices with over a decade of history. It was developed by Mocana, an IoT security company recently acquired by DigiCert. The Armis researchers first identified critical vulnerabilities, dubbed TLStorm, in APC SmartUPS devices that stemmed from the manufacturer not following some of the implementation recommendations made by the NanoSSL developers.

Implementation flaws are common when it comes to cryptographic libraries in general and can provide a path to exploit known weaknesses in those libraries that rely on correct and safe implementation to mitigate. This was the case with the APC SmartUPS vulnerabilities which were in the code that glued together the vendor logic and the NanoSSL library.

While investigating the TLStorm flaws, Armis identified dozens of devices using the NanoSSL library in its existing database of device profiles and some of them were network switches made by Aruba and Avaya. This led them to finding the same library implementation issues in these devices as well with similarly serious implications. These new bugs were dubbed TLStorm 2.0.

Bypassing network segmentation and captive portals

Network switches are commonly used to isolate virtual local area network (VLAN) segments from each other for security reasons. For example, it’s common for organizations to isolate guest networks, either Wi-Fi or wired, from the larger corporate network, or to isolate critical devices or servers within their own more restricted network segment that cannot be accessed from the broader corporate network without additional authentication.

One common feature of authenticating network access is through so-called captive portals. These are essentially web pages displayed to newly connecting users where they are asked to authenticate or to accept certain terms and conditions before they are provided with access to the internet or other network resources. Captive portals are very common with guest networks — both Wi-Fi and wired — in a variety of environments, from airports, hospitals and hotels to coffee shops, apartment buildings and business centers.

“Using the TLStorm 2.0 vulnerabilities, an attacker can abuse the captive portal and gain remote code execution over the switch with no need for authentication,” the Armis researchers said. “Once the attacker has control over the switch, he can disable the captive portal completely and connect freely to the corporate network.”

Once the attackers have control over the switch, they can also bypass the network segmentation and jump from one VLAN into another. This allows for lateral movement across the network and potential network segments that should be isolated from the internet.

The NanoSSL implementation errors in Aruba switches can be exploited through TLS connections made both to the captive portal feature but also through RADIUS protocol. RADIUS is a client-server network authentication and authorization protocol used to provide central management for users accessing network services. Network switches include a RADIUS client that connects to the central RADIUS server to request access to different resources.

“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,” the Armis researchers said.

Separately, a user of the captive portal can take control of a vulnerable switch before authentication. Since both issues stem from improper TLS connection handling via NanoSSL in Aruba switches, they are tracked together as CVE-2022-23677 (9.0 CVSS severity score). The researchers also identified two memory corruption issues in the RADIUS client of Aruba switches that can lead to execution of attacker-control data via heap overflows. These are tracked separately as CVE-2022-23676 (9.1 CVSS score).

The Aruba switch models impacted by these flaws are: the Aruba 5400R Series, 3810 Series, 2920 Series, 2930F Series, 2930M Series, 2530 Series and 2540 Series.

The vulnerabilities found in Avaya switches can be exploited through the web management portal and none of them require authentication. One flaw (CVE-2022-29860) with 9.8 severity score is a heap overflow stemming from TLS reassembly. This is caused by improper validation of the NanoSSL return values when processing POST requests to the web server.

A separate vulnerability in HTTP header parsing of Avaya switches when handling multipart form data combined with a string that is not null-terminated can also cause an attacker-controlled stack overflow and lead to remote code execution. This is tracked separately as CVE-2022-29861 (9.8 CVSS score).

A third RCE vulnerability that hasn’t received a CVE ID was also found in a discontinued Avaya product line and is caused by missing error checks related to the NanoSSL library. Since the impacted products are no longer maintained, this flaw is unlikely to receive a patch, but Armis’s data shows devices impacted by it are still being used in the wild.

The Avaya devices affected by TLStorm 2.0 are: the ERS3500 Series, ERS3600 Series, ERS4900 Series and ERS5900 Series.

Mitigating TLStorm 2.0

According to Armis, there’s no indication the TLStorm 2.0 vulnerabilities have been exploited in the wild and both Aruba (HPE) and Avaya (Extreme Networks) have contacted customers and issued patches for most of the vulnerabilities. These are available through their respective customer support portals.

In addition, Armis recommends implementing network monitoring solutions that can identify exploit attempts for these and other vulnerabilities and limiting the attack surface of devices by blocking access to their management portals from guest networks or limiting them to dedicated management ports.