Motorola : Security Vulnerabilities, CVEs,

A hidden interface in Motorola CX2L Router firmware v1.0.1 leaks information regarding the SystemWizardStatus component via sending a crafted request to device_web_ip.

An arbitrary firmware upload vulnerability exists in the Motorola MR2600. An attacker can exploit this vulnerability to achieve code execution on the device. Authentication is required, however can be bypassed.

An authentication bypass vulnerability exists in the web component of the Motorola MR2600. An attacker can exploit this vulnerability to access protected URLs and retrieve sensitive information.

A command injection vulnerability exists in the 'SaveStaticRouteIPv6Params' parameter of the Motorola MR2600. A remote attacker can exploit this vulnerability to achieve command execution. Authentication is required, however can be bypassed.

A command injection vulnerability exists in the 'SaveStaticRouteIPv4Params' parameter of the Motorola MR2600. A remote attacker can exploit this vulnerability to achieve command execution. Authentication is required, however can be bypassed.

A command injection vulnerability exists in the ‘SaveSysLogParams’ parameter of the Motorola MR2600. A remote attacker can exploit this vulnerability to achieve command execution. Authentication is required, however can be bypassed.

Motorola CX2L Router 1.0.1 was discovered to contain a command injection vulnerability via the tomography_ping_number parameter.

Motorola CX2L Router 1.0.1 was discovered to contain a command injection vulnerability via the smartqos_priority_devices parameter.

Motorola CX2L Router 1.0.1 was discovered to contain a command injection vulnerability via the system_time_timezone parameter.

Motorola CX2L Router 1.0.1 was discovered to contain a command injection vulnerability via the staticroute_list parameter.

Motorola EBTS/MBTS Site Controller drops to debug prompt on unhandled exception. The Motorola MBTS Site Controller exposes a debug prompt on the device's serial port in case of an unhandled exception. This allows an attacker with physical access that is able to trigger such an exception to extract secret key material and/or gain arbitrary code execution on the device.

Motorola EBTS/MBTS Base Radio fails to check firmware authenticity. The Motorola MBTS Base Radio lacks cryptographic signature validation for firmware update packages, allowing an authenticated attacker to gain arbitrary code execution, extract secret key material, and/or leave a persistent implant on the device.

Motorola MBTS Site Controller fails to check firmware update authenticity. The Motorola MBTS Site Controller lacks cryptographic signature validation for firmware update packages, allowing an authenticated attacker to gain arbitrary code execution, extract secret key material, and/or leave a persistent implant on the device.

Motorola MBTS Base Radio accepts hard-coded backdoor password. The Motorola MBTS Base Radio Man Machine Interface (MMI), allowing for service technicians to diagnose and configure the device, accepts a hard-coded backdoor password that cannot be changed or disabled.

Motorola MBTS Site Controller accepts hard-coded backdoor password. The Motorola MBTS Site Controller Man Machine Interface (MMI), allowing for service technicians to diagnose and configure the device, accepts a hard-coded backdoor password that cannot be changed or disabled.

An improper input sanitization vulnerability in the Motorola MR2600 router could allow a local user with elevated permissions to execute arbitrary code.

The Motorola MOSCAD and ACE line of RTUs through 2022-05-02 omit an authentication requirement. They feature IP Gateway modules which allow for interfacing between Motorola Data Link Communication (MDLC) networks (potentially over a variety of serial, RF and/or Ethernet links) and TCP/IP networks. Communication with RTUs behind the gateway is done by means of the proprietary IPGW protocol (5001/TCP). This protocol does not have any authentication features, allowing any attacker capable of communicating with the port in question to invoke (a subset of) desired functionality.

The Motorola ACE1000 RTU through 2022-05-02 uses ECB encryption unsafely. It can communicate with an XRT LAN-to-radio gateway by means of an embedded client. Credentials for accessing this gateway are stored after being encrypted with the Tiny Encryption Algorithm (TEA) in ECB mode using a hardcoded key. Similarly, the ACE1000 RTU can route MDLC traffic over Extended Command and Management Protocol (XCMP) and Network Layer (XNL) networks via the MDLC driver. Authentication to the XNL port is protected by TEA in ECB mode using a hardcoded key.

The Motorola ACE1000 RTU through 2022-05-02 mishandles firmware integrity. It utilizes either the STS software suite or ACE1000 Easy Configurator for performing firmware updates. In case of the Easy Configurator, firmware updates are performed through access to the Web UI where file system, kernel, package, bundle, or application images can be installed. Firmware updates for the Front End Processor (FEP) module are performed via access to the SSH interface (22/TCP), where a .hex file image is transferred and a bootloader script invoked. File system, kernel, package, and bundle updates are supplied as RPM (RPM Package Manager) files while FEP updates are supplied as S-rec files. In all cases, firmware images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks.

The Motorola ACE1000 RTU through 2022-05-02 ships with a hardcoded SSH private key and initialization scripts (such as /etc/init.d/sshd_service) only generate a new key if no private-key file exists. Thus, this hardcoded key is likely to be used by default.

The Motorola ACE1000 RTU through 2022-05-02 has default credentials. It exposes an SSH interface on port 22/TCP. This interface is used for remote maintenance and for SFTP file-transfer operations that are part of engineering software functionality. Access to this interface is controlled by 5 preconfigured accounts (root, abuilder, acelogin, cappl, ace), all of which come with default credentials. Although the ACE1000 documentation mentions the root, abuilder and acelogin accounts and instructs users to change the default credentials, the cappl and ace accounts remain undocumented and thus are unlikely to have their credentials changed.

Motorola ACE1000 RTUs through 2022-05-02 mishandle application integrity. They allow for custom application installation via either STS software, the C toolkit, or the ACE1000 Easy Configurator. In the case of the Easy Configurator, application images (as PLX/DAT/APP/CRC files) are uploaded via the Web UI. In case of the C toolkit, they are transferred and installed using SFTP/SSH. In each case, application images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks.

Motorola MTM5000 series firmwares lack properly configured memory protection of pages shared between the OMAP-L138 ARM and DSP cores. The SoC provides two memory protection units, MPU1 and MPU2, to enforce the trust boundary between the two cores. Since both units are left unconfigured by the firmwares, an adversary with control over either core can trivially gain code execution on the other, by overwriting code located in shared RAM or DDR2 memory regions.

The Motorola MTM5000 series firmwares generate TETRA authentication challenges using a PRNG using a tick count register as its sole entropy source. Low boottime entropy and limited re-seeding of the pool renders the authentication challenge vulnerable to two attacks. First, due to the limited boottime pool entropy, an adversary can derive the contents of the entropy pool by an exhaustive search of possible values, based on an observed authentication challenge. Second, an adversary can use knowledge of the entropy pool to predict authentication challenges. As such, the unit is vulnerable to CVE-2022-24400.

The Motorola MTM5000 series firmwares lack pointer validation on arguments passed to trusted execution environment (TEE) modules. Two modules are used, one responsible for KVL key management and the other for TETRA cryptographic functionality. In both modules, an adversary with non-secure supervisor level code execution can exploit the issue in order to gain secure supervisor code execution within the TEE. This constitutes a full break of the TEE module, exposing the device key as well as any TETRA cryptographic keys and the confidential TETRA cryptographic primitives.