BLACK HAT USA -- Las Vegas – Tuesday, Aug. 8 — After vulnerabilities were found in the TETRA communications protocol that powers industrial control systems globally, researchers have revealed new research showing multiple additional zero-day vulnerabilities in a Motorola base station and system chip. Both are required to run and decrypt the TETRA communications algorithm, potentially exposing sensitive information.
TETRA, or Terrestrial Trunked Radio, is a global standard for encrypted two-way communications developed by public safety experts under the auspices of the European Telecommunications Standards Institute (ETSI). TETRA systems are used in both public safety and industrial-commercial sectors such as utility companies, rail and metro lines, power stations, oil refineries, and chemical plants.
Midnight Blue founding partner Wouter Bokslag, who is disclosing full details in a talk at the Black Hat USA conference taking place this week, says the base station has a trusted execution environment (TEE), which is intended to protect both the cryptographic primitives and keys from exfiltration. However, he explains that by doing a side channel attack on the TEE, his team was able to decrypt the module and gain an AES key that could be used to further decrypt communications flowing through the equipment.
"That allows us to extract a Motorola key from the radio that can then be used to decrypt the module that implements all that traffic security features," he says. "So we broke this layer in order to get our hands on the TETRA crypto."
Bokslag clarifies that the TETRA encryption algorithm was not broken by the researchers at any point — they were just able to get the decryption key and their efforts demonstrated how keys are able to be extracted. He says, "There is a sort of a blind confidence in the industry that that TETRA keys are secure inside the radio, but that's not necessarily the case."
The research overall led to them discovering four zero-day bugs, two of which are critical or high severity and are specific to a Motorola MTM5400:
- CVE-2022-26941: A format string vulnerability in the AT+CTGL command handler that allows for arbitrary code execution with root privileges.
- CVE-2022-26943: A weak random number generator (RNG) that allows attackers to exploit the DCK pinning vulnerability (CVE-2022-24400) against these radios.
- CVE-2022-26942: Missing pointer validation in the custom Motorola TEE module code that allows attackers to achieve arbitrary secure supervisor mode code execution in the TEE, the highest possible privileges in the most sensitive part of the radio.
- CVE-2022-27813: Unconfigured memory protection modules allow for arbitrary lateral movement from the application processor (AP) to the digital signal processor (DSP).
Bokslag says these vulnerabilities could also be used by attackers with physical access to a Motorola radio to extract sensitive key material, after which they can listen in to the TETRA network undetected until the next key change.
"This kind of attack would work regardless of the TEA (TETRA Encryption Algorithm) cipher used and is possibly less involved to pull off than the decryption oracle attack on the protocol (CVE-2022-24401), although it does require brief physical access," he says.
Bugs in the Chip
There were also three other zero-days, all of which were rated as critical, which resided in the OMAP-L138 system-on-chip used in the Motorola radio. Bokslag explains that this chip is popular among TETRA basebands from multiple vendors and also used in other products. The following issues were discovered:
- CVE-2022-25332: Timing side-channel in the TEE SK_LOAD routine that allows attackers to recover the Customer Encryption Key (CEK) and decrypt sensitive modules (such as the ones protecting the TETRA cryptographic algorithms). Since this routine is implemented in mask ROM, this vulnerability is unpatchable.
- CVE-2022-25334: Stack overflow in the TEE SK_LOAD signature length field that allows attackers to obtain arbitrary code execution in secure supervisor mode within the TEE. This constitutes a full break of the TEE security architecture and is unpatchable since the routine is implemented in mask ROM.
- CVE-2022-25333: A flawed RSA authenticity check in the TEE SK_LOAD routine allows attackers to forge malicious modules and, combined with CVE-2022-25332, can be used to obtain arbitrary code execution in secure supervisor mode within the TEE. This constitutes a full break of the TEE security architecture and is unpatchable since the routine is implemented in mask ROM.
Base Station Bugs
As part of developing a proof of concept (PoC) exploit, Midnight Blue said it instrumented a TETRA base station to turn it into an attack platform. In doing this, it discovered five additional zero-days in the Motorola MBTS TETRA base station, three of which are rated as high severity.
Bokslag says, "These vulnerabilities could also be used by an attacker with (temporary) physical access to a base station to extract key material or even leave persistent implants in the radio infrastructure allowing for persistence interception capabilities across key rollovers."
These vulnerabilities were detailed as:
- CVE-2023-23770: Hardcoded backdoor password in MBTS site controller, allowing for device configuration manipulation
- CVE-2023-23771: Hardcoded backdoor password in MBTS base radio, allowing for device configuration manipulation
- CVE-2023-23772: The MBTS site controller fails to check firmware authenticity, allowing for arbitrary code execution
- CVE-2023-23773: The MBTS base radio fails to check firmware authenticity, allowing for arbitrary code execution
- CVE-2023-23774: MBTS site controller debug prompt can be unlocked by triggering unhandled exceptions, granting arbitrary code execution on the device
Bokslag says that even though the Motorola MBTS is a legacy base station, and therefore easiest to subvert, these issues combined with investigations of state-of-the-art TETRA equipment from other vendors — which it has undertaken but not yet made public — showcase an ecosystem of equipment that lags years, if not decades, behind what one ought to expect of infrastructure handling highly sensitive communications.
He says, "This paints a picture of a security product that was not being designed as if it was a security product."
He was keen not to pin the blame purely on Motorola, since it's an industrywide problem. "It's a classical embedded systems environment, and while it's dealing with security-critical stuff, the engineering is not as if security is a top priority," he says.