TLStorm 2.0 flaws expose Aruba and Avaya switches

Switch vulnerabilities are considered critical and could allow attackers to break network segmentation, extract data and use captive portals. Devices manufactured by Aruba Networks (HPE) and Avaya are affected.

Several series of network switches manufactured by Aruba Networks, owned by Hewlett Packard Enterprise (HPE) and Avaya, are vulnerable to remote malicious code execution (RCE) attacks. This can allow hackers to break network segmentation, extract data from internal networks to the Internet, or even use captive portals to steal user credentials. The flaws stem from mistakes made by vendors when implementing a popular embedded TLS library. The vulnerabilities are classified as critical according to researchers at security firm Armis who discovered them.

These flaws, grouped together as TLStorm 2.0, can extend to full control, often without authentication, of switches deployed in a wide variety of corporate networks and also used to isolate public network segments in airports, hospitals, hotels, and others. organizations. “Over the past few months, we’ve seen an increasing number of vulnerabilities in popular libraries, the two most notable being Log4Shell and Spring4Shell,” the Armis researchers say in their report. “While it is clear that almost all software relies on external libraries, these libraries present new risks to host software. In the case of Mocana NanoSSL, the manual clearly states proper cleaning in the event of a connection error, but we’ve seen several vendors fail to handle errors correctly, leading to memory corruption errors or confusing configuration. ‘state’.

Popular TLS Libraries

NanoSSL is a high-performance, closed-source TLS library for embedded devices that are over ten years old. It was developed by Mocana, an IoT security company recently acquired by DigiCert. Armis researchers first identified critical vulnerabilities, dubbed TLStorm, in APC SmartUPS devices that originated 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 way to exploit known weaknesses in those libraries that depend on a correct and secure implementation to be mitigated. This was the case for the APC SmartUPS vulnerabilities that were in the code that linked vendor logic and the NanoSSL library.

Investigating the TLStorm flaws, Armis identified dozens of devices using the NanoSSL library in their existing device profile database and some of them were network switches manufactured by Aruba and Avaya. This led them to encounter the same library implementation issues on these devices, with equally serious implications. These new bugs were dubbed TLStorm 2.0.

Ignore network segmentation

Network switches are typically used to isolate virtual local area network (VLAN) segments from each other for security reasons. For example, it is common for companies to isolate guest networks, whether Wi-Fi or wired, from the larger corporate network, or to isolate critical devices or servers within their own larger network segment. Restricted that cannot be accessed from the wider corporate network without authentication.

A common network access authentication feature is called captive portals. Essentially, these are web pages displayed to users who have just logged in, where they are asked to authenticate or agree to certain conditions before accessing the Internet or other network resources. Captive portals are very common in guest networks, whether Wi-Fi or wired, in various 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 on the switch without the need for authentication,” the Armis researchers said. “Once the attacker has control of the switch, he can completely disable the captive portal and freely connect to the corporate network.” Once attackers have control of the switch, they can also bypass network segmentation and switch between VLANs. This allows lateral movement through the network and potential network segments that must be isolated from the Internet.

Radius protocol impacted

NanoSSL implementation errors on Aruba switches can be exploited through TLS connections established with Captive Portal and the Radius protocol. It is a client-server network authentication and authorization protocol used to provide centralized management of 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 management of the Radius connection could allow an attacker capable of intercepting this connection through a man in the middle attack to take control of the switch without any user interaction.

Additionally, a captive portal user can take control of a vulnerable switch prior to authentication. Because both of these issues stem from improper handling of TLS connections over NanoSSL on Aruba switches, they are collectively referred to as CVE-2022-23677 (CVSS severity score of 9.0). The researchers also identified two memory corruption issues in the RADIUS client of Aruba switches that can lead to the execution of attacker control data through heap overflows. These issues are tracked separately as CVE-2022-23676 (CVSS score of 9.1). The Aruba switch models affected by these vulnerabilities are: Aruba 5400R Series, 3810 Series, 2920 Series, 2930F Series, 2930M Series, 2530 Series, and 2540 Series.

Various 9.8 level vulnerabilities

Vulnerabilities found in Avaya switches can be exploited through the web management portal and none of them require authentication. A failure (CVE-2022-29860) with a severity score of 9.8 is a TLS reassembly heap overflow. It is caused by improper validation of NanoSSL return values ​​when processing POST requests to the web server. A separate vulnerability in Avaya switches HTTP header parsing when processing multipart form data combined with a non-null-terminated string could also cause an attacker-controlled stack overflow and lead to remote code execution. This vulnerability is tracked separately as CVE-2022-29861 (CVSS score of 9.8).

A third RCE vulnerability that has not been given a CVE ID was also discovered in a discontinued Avaya product line and is caused by a lack of bug checks related to the NanoSSL library. As the affected products are no longer supported, this flaw is unlikely to receive a fix, but data from Armis shows that the affected devices are still in use. Avaya devices affected by TLStorm 2.0 are: ERS3500 Series, ERS3600 Series, ERS4900 Series, and ERS5900 Series.

TLStorm 2.0 Mitigation

According to Armis, there is no indication that the vulnerabilities in TLStorm 2.0 have been exploited in the wild. Aruba (HPE) and Avaya contacted their customers and released fixes for most vulnerabilities. They are available on their respective customer support portals. In addition, the company recommends implementing network monitoring solutions that can identify attempts to exploit these and other vulnerabilities and limit the attack surface of devices by blocking access to their portals, managing guest networks, or limiting them to dedicated management.

Leave a Comment