TLS flaws leave Avaya, Aruba switches open to complete takeover

TLS flaws leave Avaya, Aruba switches open to complete takeover

Aruba and Avaya network switches are vulnerable to multiple flaws that could allow attackers to remotely execute code and completely take over devices.

Researchers at device intelligence firm Armis found five vulnerabilities (two flaws in Aruba switches and three flaws in Avaya switches) that could be used to compromise networks that allow access by outsiders, even with limited rights. The flaws can be exploited by a captive portal user or authentication server, the researchers explained.

Worryingly, looking at the bug details, all three of Avaya’s bugs are zero-click, requiring no authentication or user interaction to exploit. One of them affects an end-of-life device and will not receive a patch.

Three of the vulnerabilities originate from improper error handling produced by a third-party library for implementing TLS produced by Internet of Things (IoT) cybersecurity firm Mocana.

Because the switches are generally not Internet-facing, the vulnerabilities face less danger from outside hackers, but the risk is still significant, says Barak Hadad, head of research at Armis.

“These are major issues, because the switches act as gatekeepers when we talk about segmentation,” he says. “When you get control of the switches, any network segmentation becomes invalid.”

The details of the vulnerability are as follows:


  • CVE-2022-23677 (CVSS score of 9.0) – NanoSSL Misuse in Multiple Interfaces (RCE)*
  • CVE-2022-23676 (CVSS score of 9.1): RADIUS Client Memory Corruption Vulnerabilities

To go:

  • CVE-2022-29860 (CVSS 9.8): TLS reassembly heap overflow*
  • CVE-2022-29861 (CVSS 9.8): HTTP header parsing stack overflow
  • HTTP POST request handling heap overflow (no CVE because it’s on an older version) *

* These are caused by the interaction between Mocana NanoSSL and the products.

Software supply chain problems persist
The vulnerabilities highlight the risks of the software supply chain and the potential dangers that come with the use of third-party components. Security flaws in the libraries that the software depends on, or in this case, in the way the software and the library interact, can create or propagate vulnerabilities. On average, 78% of software code bases consist of open source libraries and components.

In March, researchers discovered a similar set of flaws that caused security vulnerabilities in more than 150 IoT products, also caused by another third-party component.

“While there are many benefits to using external libraries, there is also inherent uncertainty,” Armis said in his security advisory published on May 3. issues that originate from the external library are embedded in it and automatically become security issues over which the vendor has less control.”

TLS Storm, Part 2
At the heart of the Mocana-related vulnerabilities are unstable error states in the Mocana NanoSSL library that handles Transport Layer Security (TLS) for the products’ management interface.

The problems occur because the attacker can create network packets that cause errors in the Mocana NanoSSL library, and the developers who produce software for providers do not handle the errors correctly.

The result is two classes of vulnerabilities: memory corruption and state confusion.

“If you initiate a TLS handshake and the other side sends the wrong message, if you don’t check the error code correctly, that scenario can be exploited to get remote code execution in some cases,” says Hadad de Armis. “The manual clearly says that the developer should check the bug, but as we know, it’s not common for developers to read the entire manual.”

Armis has worked with Mocana, Aruba, and Avaya to remediate issues where appropriate. The companies’ customers have been notified and each company has released updated software. In the case of Mocana, although technically the vulnerabilities are not caused by software, the company has created an update anyway to prevent future buggy implementations.

“It’s not a Mocana vulnerability, but yet they’ve released new software that makes you not in a vulnerable situation just because you didn’t check the error code,” says Hadad.

vulnerabilities, dubbed TLStorm 2.0 by Armis, are similar to those announced in March that affect intelligently connected uninterruptible power supplies (UPS).

Not the first buggy implementation
Previously, Armis researchers showed the same vulnerabilities used against various UPS models from APC, now owned by Schneider Electric. The attacks, which targeted UPSs that connected to the Schneider Electric Cloud to enable management, could allow attackers to remotely compromise devices without user interaction or leaving any trace of the attack.

Because new firmware could be uploaded to devices remotely, attackers could change the waveform and voltage of AC power provided to connected devices and even cause the UPS to overheat.

“The fact that UPS devices regulate high-voltage power, combined with their Internet connectivity, makes them a high-value cyber target,” Armis stated in his March advisory about the vulnerabilities, which called TLStorm. “Since the TLS attack vector can originate from the Internet, these vulnerabilities can act as a gateway to the internal corporate network. Bad actors can use confusion of the TLS state to identify themselves as the Schneider Electric cloud and gather information about the UPS behind the corporate network. firewall”.

Leave a Comment