Aruba and Avaya network switches are vulnerable to RCE attacks

Aruba and Avaya network switches are vulnerable to RCE attacks

Security researchers have identified five vulnerabilities in network hardware from Aruba (owned by HP) and Avaya (owned by ExtremeNetworks) that could allow attackers to remotely execute code on devices.

The damage caused by a successful attack ranges from data breaches and complete capture of the device to lateral movement and overcoming protection against network segmentation.

Security researchers from the cybersecurity company Armis, which specializes in connected devices, called the TLStorm 2.0 vulnerability set because the discovery falls into the same class of problems as the misuse of the NanoSSL TLS library they reported. popular models of UPS APC.

Analysts found that third-party devices have identical security risks, and provided a list of products affected by:

  • Avaya ERS3500
  • Avaya ERS3600
  • Avaya ERS4900
  • Avaya ERS5900
  • Aruba 5400R series
  • Aruba 3810 series
  • Aruba 2920 series
  • Aruba 2930F series
  • Aruba 2930M series
  • Aruba 2530 series
  • Aruba 2540 series

External libraries on switches

Network switches are common elements in corporate networks, helping to ensure segmentation, a security practice that is fundamental today in large environments.

Their role is to act as a network bridge, connecting devices to the network and using packet switching and MAC addresses to receive and send data to the destination device.

Using external libraries is often a convenient and cost-effective solution, but it is sometimes accompanied by implementation errors and security issues.

This practice encourages hackers to study these tiny building blocks to find potentially used shortcomings.

In the case of TLStorm 2.0, the reason for the problem is that the “glue logic” code used by the vendors does not comply with NanoSSL recommendations, leading to a potential RCE (remote code execution).

In Aruba, NanoSSL is used for the Radius authentication server, as well as for the captured portal system. The method of its implementation can lead to overflow of the heap of data of the malefactor.

On Avaya, the library implementation has three drawbacks: overflow of the TLS recompile heap, overflow of the HTTP header analysis stack overflow, and overflow of the HTTP POST request for processing.

Problems arise due to lack of error checks, missing verification steps and incorrect border checks.

These problems are not in the library itself, but in how the vendor has implemented it.

Attack scenarios

Armis presents two main operating scenarios that allow you to avoid a hijacked portal or break network segmentation, paving the way for high-impact cyberattacks.

In an attached portal scenario, an attacker gains access to a limited network resource web page that requires authentication, payment, or any other form of access token. These private portals are commonly found in hotel chains, airports and business centers.

Using TLStorm 2.0, an attacker can remotely execute code on the switch, bypassing the limitations of the captured portal or even disabling it altogether.

Bypass network segmentation restrictions
Bypass network segmentation restrictions (Armis)

In the second scenario, an attacker could use vulnerabilities to hack network segmentation and gain access to any part of the IT network, freely moving from the “guest” space to the “corporate” segment.


Armis informed Aruba and Avaya about the TLStorm 2.0 vulnerabilities three months ago and worked with them on a technical level.

Threat analysts told BleepingComputer that affected customers have been notified, as well as released patches that address most of the vulnerabilities.

In addition, Armis told us that they are unaware of the use of TLStorm 2.0 vulnerabilities.

Leave a Reply

Your email address will not be published.