| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Universal Robots controller execute URCaps (zip files containing Java-powered applications) without any permission restrictions and a wide API that presents many primitives that can compromise the overall robot operations as demonstrated in our video. In our PoC we demonstrate how a malicious actor could 'cook' a custom URCap that when deployed by the user (intendedly or unintendedly) compromises the system |
| Use of unsafe yaml load. Allows instantiation of arbitrary objects. The flaw itself is caused by an unsafe parsing of YAML values which happens whenever an action message is processed to be sent, and allows for the creation of Python objects. Through this flaw in the ROS core package of actionlib, an attacker with local or remote access can make the ROS Master, execute arbitrary code in Python form. Consider yaml.safe_load() instead. Located first in actionlib/tools/library.py:132. See links for more info on the bug. |
| IRC5 exposes an ftp server (port 21). Upon attempting to gain access you are challenged with a request of username and password, however you can input whatever you like. As long as the field isn't empty it will be accepted. |
| The IRC5 family with UAS service enabled comes by default with credentials that can be found on publicly available manuals. ABB considers this a well documented functionality that helps customer set up however, out of our research, we found multiple production systems running these exact default credentials and consider thereby this an exposure that should be mitigated. Moreover, future deployments should consider that these defaults should be forbidden (user should be forced to change them). |
| the main user account has restricted privileges but is in the sudoers group and there is not any mechanism in place to prevent sudo su or sudo -i to be run gaining unrestricted access to sensible files, encryption, or issue orders that disrupt robot operation. |
| The authentication implementation on the xArm controller has very low entropy, making it vulnerable to a brute-force attack. There is no mechanism in place to mitigate or lockout automated attempts to gain access. |
| No authentication is required to control the robot inside the network, moreso the latest available user manual shows an option that lets the user to add a password to the robot but as in xarm_studio 1.3.0 the option is missing from the menu. Assuming manual control, even by forcefully removing the current operator from an active session. |
| The Micro Air Vehicle Link (MAVLink) protocol presents authentication mechanisms on its version 2.0 however according to its documentation, in order to maintain backwards compatibility, GCS and autopilot negotiate the version via the AUTOPILOT_VERSION message. Since this negotiation depends on the answer, an attacker may craft packages in a way that hints the autopilot to adopt version 1.0 of MAVLink for the communication. Given the lack of authentication capabilities in such version of MAVLink (refer to CVE-2020-10282), attackers may use this method to bypass authentication capabilities and interact with the autopilot directly. |
| The Micro Air Vehicle Link (MAVLink) protocol presents no authentication mechanism on its version 1.0 (nor authorization) whichs leads to a variety of attacks including identity spoofing, unauthorized access, PITM attacks and more. According to literature, version 2.0 optionally allows for package signing which mitigates this flaw. Another source mentions that MAVLink 2.0 only provides a simple authentication system based on HMAC. This implies that the flying system overall should add the same symmetric key into all devices of network. If not the case, this may cause a security issue, that if one of the devices and its symmetric key are compromised, the whole authentication system is not reliable. |
| This vulnerability applies to the Micro Air Vehicle Link (MAVLink) protocol and allows a remote attacker to gain access to sensitive information provided it has access to the communication medium. MAVLink is a header-based protocol that does not perform encryption to improve transfer (and reception speed) and efficiency by design. The increasing popularity of the protocol (used accross different autopilots) has led to its use in wired and wireless mediums through insecure communication channels exposing sensitive information to a remote attacker with ability to intercept network traffic. |
| The Apache server on port 80 that host the web interface is vulnerable to a DoS by spamming incomplete HTTP headers, effectively blocking the access to the dashboard. |
| MiR robot controllers (central computation unit) makes use of Ubuntu 16.04.2 an operating system, Thought for desktop uses, this operating system presents insecure defaults for robots. These insecurities include a way for users to escalate their access beyond what they were granted via file creation, access race conditions, insecure home directory configurations and defaults that facilitate Denial of Service (DoS) attacks. |
| The BIOS onboard MiR's Computer is not protected by password, therefore, it allows a Bad Operator to modify settings such as boot order. This can be leveraged by a Malicious operator to boot from a Live Image. |
| There is no mechanism in place to prevent a bad operator to boot from a live OS image, this can lead to extraction of sensible files (such as the shadow file) or privilege escalation by manually adding a new user with sudo privileges on the machine. |
| The password for the safety PLC is the default and thus easy to find (in manuals, etc.). This allows a manipulated program to be uploaded to the safety PLC, effectively disabling the emergency stop in case an object is too close to the robot. Navigation and any other components dependent on the laser scanner are not affected (thus it is hard to detect before something happens) though the laser scanner configuration can also be affected altering further the safety of the device. |
| The access tokens for the REST API are directly derived from the publicly available default credentials for the web interface. Given a USERNAME and a PASSWORD, the token string is generated directly with base64(USERNAME:sha256(PASSWORD)). An unauthorized attacker inside the network can use the default credentials to compute the token and interact with the REST API to exfiltrate, infiltrate or delete data. |
| The access tokens for the REST API are directly derived (sha256 and base64 encoding) from the publicly available default credentials from the Control Dashboard (refer to CVE-2020-10270 for related flaws). This flaw in combination with CVE-2020-10273 allows any attacker connected to the robot networks (wired or wireless) to exfiltrate all stored data (e.g. indoor mapping images) and associated metadata from the robot's database. |
| MiR controllers across firmware versions 2.8.1.1 and before do not encrypt or protect in any way the intellectual property artifacts installed in the robots. This flaw allows attackers with access to the robot or the robot network (while in combination with other flaws) to retrieve and easily exfiltrate all installed intellectual property and data. |
| MiR100, MiR200 and other MiR robots use the Robot Operating System (ROS) default packages exposing the computational graph without any sort of authentication. This allows attackers with access to the internal wireless and wired networks to take control of the robot seamlessly. In combination with CVE-2020-10269 and CVE-2020-10271, this flaw allows malicious actors to command the robot at desire. |
| MiR100, MiR200 and other MiR robots use the Robot Operating System (ROS) default packages exposing the computational graph to all network interfaces, wireless and wired. This is the result of a bad set up and can be mitigated by appropriately configuring ROS and/or applying custom patches as appropriate. Currently, the ROS computational graph can be accessed fully from the wired exposed ports. In combination with other flaws such as CVE-2020-10269, the computation graph can also be fetched and interacted from wireless networks. This allows a malicious operator to take control of the ROS logic and correspondingly, the complete robot given that MiR's operations are centered around the framework (ROS). |
