CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
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. |
A format string vulnerability exists in Motorola MTM5000 series firmware AT command handler for the AT+CTGL command. An attacker-controllable string is improperly handled, allowing for a write-anything-anywhere scenario. This can be leveraged to obtain arbitrary code execution inside the teds_app binary, which runs with root privileges. |
Versions of Motorola Ready For and Motorola Device Help Android applications prior to 2021-04-08 do not properly verify the server certificate which could lead to the communication channel being accessible by an attacker. |
The Motorola MH702x devices, prior to version 2.0.0.301, do not properly verify the server certificate during communication with the support server which could lead to the communication channel being accessible by an attacker. |
A privilege escalation vulnerability was reported in the MM1000 device configuration web server, which could allow privileged shell access and/or arbitrary privileged commands to be executed on the adapter. |
The Motorola MM1000 device configuration portal can be accessed without authentication, which could allow adapter settings to be modified. |
Certain Motorola Solutions Avigilon devices allow XSS in the administrative UI. This affects T200/201 before 4.10.0.68; T290 before 4.4.0.80; T008 before 2.2.0.86; T205 before 4.12.0.62; T204 before 3.28.0.166; and T100, T101, T102, and T103 before 2.6.0.180. |
An command injection vulnerability in HNAP1/SetWLanApcliSettings of Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n allows attackers to execute arbitrary system commands. |
An issue in HNAP1/GetMultipleHNAPs of Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n allows attackers to access the components GetStationSettings, GetWebsiteFilterSettings and GetNetworkSettings without authentication. |
A command injection vulnerability in HNAP1/GetNetworkTomographySettings of Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n allows attackers to execute arbitrary code. |
An issue was discovered in Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n where authentication to download the Syslog could be bypassed. |
An issue was discovered in Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n where the admin password and private key could be found in the log tar package. |
A vulnerability in /Login.html of Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n allows attackers to bypass login and obtain a partially authorized token and uid. |
Motorola FX9500 devices allow remote attackers to read database files. |
An issue was discovered on Motorola C1 and M2 devices with firmware 1.01 and 1.07 respectively. This issue is a Command Injection allowing a remote attacker to execute arbitrary code, and get a root shell. A command Injection vulnerability allows attackers to execute arbitrary OS commands via a crafted /HNAP1 POST request. This occurs when any HNAP API function triggers a call to the system function with untrusted input from the request body for the SetSmartQoSSettings API function, as demonstrated by shell metacharacters in the smartqos_priority_devices field. |