TLStorm 2.0 vulnerabilities detected in NanoSSL TLS library leads to flaws in Aruba, Avaya switches

Armis researchers have discovered five new vulnerabilities with a common source dubbed TLStorm 2.0, which were found in implementing TLS communications across multiple Aruba and Avaya switch models. The discovery comes close to the heels of last month’s reveal of three critical vulnerabilities in APC Smart-UPS devices dubbed TLStorm that allow an attacker to take control of Smart-UPS devices.

“The vulnerabilities stem from a similar design flaw identified in the TLStorm vulnerabilities (discovered earlier this year by Armis) and expand the reach of TLStorm to potentially millions of additional enterprise-grade network infrastructure devices,” Barak Hadad, head of research in engineering, wrote in a company blog post. 

The root cause for both sets of vulnerabilities has been identified as a misuse of NanoSSL, a TLS library by Mocana. “By exploring similar faulty implementations of the Mocana NanoSSL library in network switches, Armis has discovered these new vulnerabilities in the implementation of TLS communications in multiple models of Aruba (acquired by HP) and Avaya (acquired by ExtremeNetworks) network switches,” Hadad explained in another company blog post.

In the case of the TLStorm 2.0 vulnerabilities, the flaws in NanoSSL, alongside the misuse of the vulnerable library, were found to affect additional vendors and devices, including network switches by Aruba and Avaya. NanoSSL is a comprehensive closed-source SSL suite by Mocana, a subsidiary of DigiCert.

“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,” Hadad said. “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,” Hadad added.

The TLStorm 2.0 vulnerabilities expose loopholes that could allow an attacker to take full control over these switches, according to Armis. The exploitation of the RCE (remote code execution) vulnerabilities can lead to the breaking of network segmentation, thereby 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, and captive portal escape. 

The Armis research findings are significant. They highlight that the network infrastructure itself is at risk and exploitable by attackers, meaning that network segmentation can no longer be considered a sufficient security measure.

According to Hadad, the immediate effect of the TLStorm 2.0 vulnerabilities is the full takeover of the connected switch, but the implications can vary based on network segmentation configurations. “In many cases, when connecting to a network, users must first pass through a captive portal. Once users pass through the captive portal, they gain access to the Internet or to the internal corporate network,” he added.

Hadad also said that using the TLStorm 2.0 vulnerabilities, an attacker can abuse the captive portal and gain remote code execution over the switch without the need for authentication. “Once the attacker has control over the switch, he can disable the captive portal completely and connect freely to the corporate network.”

An attacker could also use the TLStorm 2.0 vulnerabilities to break network segmentation. “Network segmentation is often used as a security layer for corporate networks. An attacker that gains a foothold in the guest VLAN is limited and can’t access the corporate VLAN. Using the TLStorm 2.0 vulnerabilities, an attacker is able to take control of the core switch and move from the guest VLAN to the corporate VLAN,” Hadad said.

Armis said that the TLStorm 2.0 vulnerabilities affected Avaya’s ERS3500 Series, ERS3600 Series, ERS4900 Series, ERS5900 Series, and Aruba’s 5400R 3810 Series, 2920 Series, 2930F Series, 2930M Series, 2530 Series, and 2540 Series. 

In Avaya’s case, 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. 

“This is a similar vulnerability to CVE-2022-22805 that we found in APC Smart-UPS devices. The process handling POST requests on the web server does not properly validate the NanoSSL return values, resulting in a heap overflow that can lead to remote code execution,” Hadad said. Additionally, 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, he added.

Hadad also said that a vulnerability in handling 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 is going to fix this vulnerability, though Armis data shows these devices can still be found in the wild,” he added.

For Aruba, the NanoSSL library 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, including captive portal, where a user of the captive portal can take control of the switch before authentication, and RADIUS authentication client. Thereby involving a vulnerability in the RADIUS connection handling that 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.

Armis said that the mitigations depend on the specific model and vendor. Organizations deploying impacted Aruba devices should patch affected devices immediately with patches in the Aruba Support Portal, while those enterprises using the affected Avaya devices should check security advisories immediately in the Avaya Support Portal.

On top of specific vendor mitigations, multiple network protection layers can be applied to mitigate the risk of the TLStorm vulnerabilities, Armis said. These would typically include network monitoring that involves looking for active exploit attempts or network anomalies that imply an attacker’s presence and limiting the attack surface, which can be done by blocking the exposure of the management portal to guest network ports or limiting it just to a dedicated management port.

Anna Ribeiro

Industrial Cyber News Editor. Anna Ribeiro is a freelance journalist with over 14 years of experience in the areas of security, data storage, virtualization and IoT.