TLS Flaws Leave Avaya, Aruba Switches Open to Complete Takeover

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

Researchers from 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 some outsider access, even with limited rights. The flaws can be exploited by a user of a captive portal or authentication server, researchers explained.

Worryingly, in looking at the details of the bugs, the three Avaya bugs are zero-click, requiring no authentication or user interaction to exploit. One of them affects an end-of-life device and won't be receiving a patch.

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

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

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

The vulnerability details are as follows:

Aruba:

Avaya:

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

Software Supply-Chain Woes Persist
The vulnerabilities underscore the risks of the software supply chain and the potential dangers that come with using third-party components. Security flaws in the libraries on which software depends — or in this case, in the way that the software and library interact — can create or propagate vulnerabilities. On average, 78% of software codebases consist of open source components and libraries.

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 the use of external libraries has many advantages, it also brings inherent uncertainty," Armis stated in its security advisory published on May 3. "Implanting a 'foreign' code means the vendor is trusting it to be implemented safely, since any security issues originating in the external library are embedded within it, and automatically become security issues which the vendor has less control over."

TLStorm, 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 issues occur because the attacker can craft network packets that cause errors in the Mocana NanoSSL library, and developers producing software for vendors do not handle the errors properly.

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

"If you start a TLS handshake and the other side sends an improper message, if you don't check the error code correctly, that scenario can be leveraged to gain remote code execution in some cases," Armis' Hadad says. "The manual clearly says that the developer should check the error, but as we know, it's not common for developers to read through the entire manual."

Armis has worked with Mocana, Aruba, and Avaya to remediate the issues where appropriate. The companies' customers have been notified, and each company has released updated software. In Mocana's case, even though the vulnerabilities are not technically caused by the software, the company has created an update anyway to avoid future flawed implementations.

"It is not a Mocana vulnerability, but nonetheless, they have published new software that makes it so you are not in a vulnerable situation just because you did not check the error code," Hadad says.

The vulnerabilities, dubbed TLStorm 2.0 by Armis, are similar to ones announced in March that affect smart-connected uninterruptible power supplies (UPS).

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

Because new firmware could be loaded into the devices remotely, attackers could change the waveform and voltage of the 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-physical target," Armis stated in its March advisory regarding the vulnerabilities, which it 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 the TLS state confusion to identify themselves as the Schneider Electric cloud and collect information about the UPS behind the corporate firewall."