With COVID-19 and the increase of automation across domains, Alias Robotics kicked off a research effort to review the status of security of these Autonomous Mobile Robots (AMRs) that are rapidly being used in hospitals, airports and industrial environments. In particular, we selected one of the most popular mobile robots: the MiR robot series, from the Danish Mobile Industrial Robots (MiR) which is widely used for healthcare disinfection tasks, manufacturing, logistics or food and beverage automation among others . MiR is owned by Teradyne, a company that was previously reported to be behind the supply of tenths of thousands of insecure robots to industry.
Through our research we found more than 100 security flaws. We originally reported the manufacturer 5 of the most relevant, and further triaging these 5 we discovered many more that inherited from our initial responsible report to the manufacturer. After months of failed interactions with MiR's representatives while trying to help secure their robots (read the story here), Alias Robotics decided to empower end-users of Mobile Industrial Robots’ with information. By putting together this case study, our goal is to empower distributors, system integrators and ultimately end-users of Mobile Industrial Robots’ solutions with the security information they so much require to securely make use of this technology.
To mitigate the impact of the disclosure of these flaws publicly and to help end-users, we are adopting the following measures: 1) Alias Robotics will actively invest resources to mitigate all identified flaws and serve it to end users as part of our Robot Immune System (RIS) and 2) we will not disclose publicly any exploits and instead will limit our disclosures to documented (non-compromising) demonstrations.
NOTE: As indicated above, the final disclosures results from further triaging the original 5 records delivered to the vendor, which were not tackled appropriately. At the time of writing we have cataloged more than 100 additional security flaws that might be subject to be considered vulnerabilities. Further investment in security, triaging and mitigation is required. We encourage you to reach out if you are using this robot for real applications.
We take pride in our duty to make the robotics landscape safer for all, because there can be no safety without security. For this particular case, Alias Robotics managed to influence the OEM of these insecure robots and forced MiR to react within a short period of time. Manufacturer, systems integrators but above all end users, we make the results of our investigation openly available to you through the Robot Vulnerability Database (RVD) to empower all with the information needed for a responsible use of this technology.
Our pentesting methodology for MiR considered the following 9 steps as depicted below:
Robotics user
Robotics operator
System integrators
Robot manufacturer upon delivery
Bad actor
RVD#2558
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.
RVD#494
Out of the wired and wireless interfaces within MiR100, MiR200 and other vehicles from the MiR fleet, it's possible to access the Control Dashboard on a hardcoded IP address. Credentials to such wireless interface default to well known and widely spread users (omitted) and passwords (omitted). This information is also available in past User Guides and manuals which the vendor distributed. This flaw allows cyber attackers to take control of the robot remotely and make use of the default user interfaces MiR has created, lowering the complexity of attacks and making them available to entry-level attackers. More elaborated attacks can also be established by clearing authentication and sending network requests directly. We have confirmed this flaw in MiR100 and MiR200 but according to the vendor, it might also apply to MiR250, MiR500 and MiR1000.
Robosploit provides a simplified PoC. The script bypasses authentication in the control dashboard sending network requests directly with the default credentials and/or a dictionary attack. Once authenticated, obtains the corresponding cookies and prepares the exploit for further HTTP method requests (GET, POST, etc.) or websocket communications.
In combination with CVE-2020-10269 or other MiR robot-entry-point vulnerabilities, attacker uses default credentials on the robot's default control dashboard to take control of the machine. The attack complexity is **very low** which further endangers users.
RVD#494
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.
Robot navigating in Alias Robotics builds a map. Such map is exfiltrated by a malicious attacker exploiting the insecurities in the robot and its REST API.
RVD#494
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).
Robot’s actuators and sensors are commanded to play some fun tunes. Any desired behavior could be programed remotely and wirelessly.
RVD#494
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.
Robosploit exploit provides a PoC that exploits the lack authentication requirements of the ROS computational graph.
Robot in an ongoing mission is stopped by an unauthorized attacker with access to the computational graph.
RVD#494
One of the wireless interfaces within MiR100, MiR200 and possibly (according to the vendor) other MiR fleet vehicles comes pre-configured in WiFi Master (Access Point) mode. Credentials to such wireless Access Point default to well known and widely spread SSID (MiR_RXXXX) and passwords (omitted). This information is also available in past User Guides and manuals which the vendor distributed. We have confirmed this flaw in MiR100 and MiR200 but it might also apply to MiR250, MiR500 and MiR1000.
RVD#494
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.
RVD#505
The perf_ cpu_ time_ max_ percent_ handler function in kernel/events/core.c in the Linux kernel before 4.11 allows local users to cause a denial of service (integer overflow) or possibly have unspecified other impact via a large value, as demonstrated by an incorrect sample-rate calculation.
RVD#522
The xfrm_replay_verify_len function in net/xfrm/xfrm_user.c in the Linux kernel through 4.10.6 does not validate certain size data after an XFRM_MSG_NEWAE update, which allows local users to obtain root privileges or cause a denial of service (heap-based out-of-bounds access) by leveraging the CAP_NET_ADMIN capability, as demonstrated during a Pwn2Own competition at CanSecWest 2017 for the Ubuntu 16.10 linux-image-* package 4.8.0.41.52.
RVD#524
net/netfilter/xt_osf.c in the Linux kernel through 4.14.4 does not require the CAP_NET_ADMIN capability for add_callback and remove_callback operations, which allows local users to bypass intended access restrictions because the xt_osf_fingers data structure is shared across all net namespaces.
More than 100 security flaws are known and 14 have been made public. To this date, MiR has not facilitated any software update to us directly, nor via their distributors (though we asked repeatedly). Provided the results above and our interaction with the upstream vendor, we highly doubt that upcoming software patches will mitigate the core security issues and highly encourage end-users to seek for alternative solutions.
From Alias Robotics, we will continue insisting on receiving latest updates and plan to react based on the manufacturer’s response to the current insecurity landscape while request to enforce European laws. We are aware that MiR seems to have updated a few of their user manuals, however, as we informed the manufacturer in past interactions, these changes do not ensure safety or security, and heavily rely on user’s actions pushing aside the responsibility.
At Alias Robotics we encourage a security-first approach to robotics. One that focuses on continuous monitoring and management of robot security risks and threats, leveraging modern tools and automation techniques to ensure that, at all times, the robots stay safe and secure. As indicated in the past, we strongly believe that vulnerability disclosure is a two-way street where both vendors and researchers, must act responsibly. We strongly believe each security researcher or group should reserve the right to bring deadlines forwards or backwards based on extreme circumstances.
Alias remains committed to treating all vendors strictly equally and we expect to be held to the same standard.
Inspired by the human immune system and developed according to latest research in robotics, data science, biology and cybersecurity, the Robot Immune System (RIS) is a modular Robot Endpoint Protection Platform (REPP). RIS is an integrated suite of endpoint protection technologies for robots including a next-gen antivirus, hardening for known robot flaws, data encryption, intrusion prevention mechanisms, data loss prevention, and more that detects, prevents, stops and informs on a variety of threats that affect the robotic system. RIS has 5 modules available, offering different Security Levels (SL) matching your security needs:
