TLStorm 2 – NanoSSL TLS Library Misuse Leads to Vulnerabilities in Common Switches

General Overview

Armis has discovered five vulnerabilities in the implementation of TLS communications in multiple models of Aruba and Avaya switches. 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.

In March 2022, Armis disclosed TLStorm – a set of critical vulnerabilities in APC Smart-UPS devices. The vulnerabilities allow an attacker to take control over Smart-UPS devices from the internet with no user interaction and make the UPS literally go up in smoke. The root cause for these vulnerabilities was a misuse of NanoSSL, a popular TLS library by Mocana.

Using the Armis knowledgebase—a database of over 2 billion devices and over 6 million device profiles—our researchers were able to identify dozens of devices using Mocana NanoSSL, including two popular switch vendors that are affected by the same misuse of the NanoSSL library.

These vendors are Aruba (acquired by HP) and Avaya Networking (acquired by Extreme Networks). We have found that both vendors have switches vulnerable to remote code execution (RCE) vulnerabilities that can be exploited over the network.

This new set of vulnerabilities, dubbed TLStorm 2.0, exposes vulnerabilities that could allow an attacker to take full control over these switches. The exploitation of these RCE vulnerabilities can lead 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

These research findings are significant as they highlight that the network infrastructure itself is at risk and exploitable by attackers, meaning that network segmentation alone is no longer sufficient as a security measure.

Before we dive into the network security considerations, however, it’s important to understand the root cause of these vulnerabilities.

The TLS Library Rabbit Hole

While the use of external libraries has many advantages, it also brings inherent uncertainty. Implanting a “foreign” code means the vendor trusts it to be implemented safely, since any security issues originating in the external library are embedded within it, and automatically become security issues that the vendor has less control over. These external libraries are shared between various product lines, making them an ideal target for attackers – a flaw in one library can affect many targets.

Previous URGENT/11 research can provide a sense of the potential scale of finding such a set of software supply chain vulnerabilities. In that case, the vulnerable TCP/IP stack (IPnet) was part of the supply chain of many IoT operating systems like VxWorks, INTEGRITY, and more, seeding a monstrous tree of inherited vulnerabilities, eventually putting billions of devices at risk.

When assessing the most common pieces of code shared across billions of devices, the core networking stack (the TCP/IP stack) might be the most sensitive attack surface of them all. However, just above the link layer and the transport layer sits the underlying security layer of all modern application layers – the TLS layer. When this layer is found to contain critical vulnerabilities, all applications that utilize it may become vulnerable as well. So was the case in 2012, when the Heartbleed vulnerability was discovered – a critical vulnerability in OpenSSL, that affected at the time 17% of all secure web servers on the Internet. This is a result of the prominence of OpenSSL – powering the TLS layer of an endless number of applications – from web servers, to email servers, to SSH connections, and so forth.

While Heartbleed was a unique and transforming moment in the security industry, it did not lead to a wide-scale analysis of major TLS/SSL implementations, and the majority of vulnerabilities that have been discovered in TLS since have mainly focused on various cryptographic edge-cases of the TLS protocol itself, that can undermine privacy or authentication aspects and not necessarily lead to critical remote-code-execution vulnerabilities. Moreover, the challenges in analyzing and assessing embedded closed-source TLS libraries have kept them unexamined by researchers, so almost no significant vulnerabilities in embedded TLS libraries have been discovered to date.

The TLStorm vulnerabilities included two critical vulnerabilities in the TLS implementation used in APC’s SmartUPS, and the root cause for these vulnerabilities was flaws in NanoSSL library, that were applicable when certain guidelines were not properly followed by the vendor using the library. The vulnerabilities themselves lay within the glue-logic – the code that glues together the vendor logic and the NanoSSL library. When this code fails to adhere to certain guidelines specified in the NanoSSL manual, an edge case that leads to remote code execution can arise.

For TLStorm 2.0, the flaws in NanoSSL alongside the misuse of the vulnerable library were found to affect additional vendors and devices – the aforementioned 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. 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.

The Security Role of the Common Switch

The backbone of every corporate network consists of routers and switches. These devices are often overlooked when examining the security posture of organizations, even though they are the enforcers of network segmentation (VLANs).

VLAN-based segmentation is a common technique for containing attackers.

When this segmentation technique is employed, an attacker is “stuck” in the first VLAN they access, which is usually some kind of guest VLAN, and the corporate network remains safe.

In 2020, Armis disclosed CDPwn, which consisted of five vulnerabilities in Cisco switches and routers that can allow attackers to break network segmentation. Two years later, we can see that many organizations haven’t updated their network gear and are still vulnerable to CDPwn:

Two years later – vulnerable devices to CDPwn by industry.

Captive Portal

A captive portal is the web page that is displayed to newly connected users of a Wi-Fi or wired network before they are granted broader access to network resources. Captive portals are commonly used to present a EULA, or a login page that may require authentication, payment, or other valid credentials that both the host and user agree to adhere to.

Figure 3: Captive portal.

Captive portals are used for a broad range of mobile and pedestrian broadband services, including cable and commercially provided Wi-Fi and home hotspots. A captive portal can also be used to provide access to enterprise or residential wired networks, such as apartment houses, hotel rooms, and business centers.

What are the Risks Associated with TLStorm 2.0

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.

Scenario 1: Captive Portal Escape

Figure 4: Attackers can gain RCE over the switch and connect freely to the corporate network.

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.

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. Once the attacker has control over the switch, he can disable the captive portal completely and connect freely to the corporate network.

Scenario 2: Breaking of Network Segmentation

Figure 5: Attackers can use a foothold in a guest VLAN to take control of the core switch and gain access to the corporate VLAN.

In the second scenario, an attacker can 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.

Affected Devices

Avaya

• ERS3500 Series
• ERS3600 Series
• ERS4900 Series
• ERS5900 Series

Aruba

• Aruba 5400R Series
• Aruba 3810 Series
• Aruba 2920 Series
• Aruba 2930F Series
• Aruba 2930M Series
• Aruba 2530 Series
• Aruba 2540 Series

Technical Overview

Aruba

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 an 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.

Avaya management interface pre-auth vulnerabilities

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 (9.8 CVSS score) – TLS reassembly heap overflow

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.

CVE-2022-29861 (9.8 CVSS score) – 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 is going to fix this vulnerability, though Armis data shows these devices can still be found in the wild.

DOWNLOAD THE WHITE PAPER

Mitigations

The mitigations depend on the specific model and vendor.

• Organizations deploying impacted Aruba devices should patch impacted devices immediately with patches in the Aruba Support Portal here.
• Organizations deploying impacted Avaya devices should check security advisories immediately in the Avaya Support Portal here.

On top of specific vendor mitigations, multiple network protection layers can be applied to mitigate the risk for the TLStorm vulnerabilities:

• Network monitoring – Looking for active exploit attempts or network anomalies that imply the presence of an attacker.
• Limit the attack surface – block the exposure of the management portal to guest network ports or limit it just to a dedicated management port.

How Can Armis Help?

Armis customers can leverage the Armis platform to:

1. Quickly discover all assets that need to be patched or protected from exploit attempts to plan and prioritize mitigation efforts. Armis not only detects the existence of these devices on the network but can also provide valuable data about the device owner and physical location to expedite mitigation efforts.
2. Detect exploit attempts in real-time and orchestrate the response through integrations with your IT and security tech stack.
3. Continue to track the long tail of ‘still-to-be-patched’ assets, and new assets that might be vulnerable. Ensure these assets aren’t targeted by exploit attempts at any time and do not pose a threat to your network.

The Armis platform provides the required visibility to ensure all your assets, including cyber-physical assets that are not covered by traditional security solutions, are continuously protected against the latest threats.

Want to discuss this with one of our experts and/or schedule a demo? – Contact us here.