From the more than 100 security flaws identified, Alias Robotics has disclosed publicly 14 cybersecurity vulnerabilities affecting MiR industrial robots and other downstream manufacturers, impacting thousands of robots. More than 10 different robot types are affected and operate from industrial spaces to public environments, such as airports and hospitals. After months of failed interactions with the manufacturer while trying to help secure their robots, with this disclosure, Alias Robotics has decided to empower end-users of Mobile Industrial Robots’ with information. In addition, Alias presents their Robot Immune System (RIS) for MiR as a solution to these insecure robot deployments and to avoid disastrous consequences of cyberattacks.

INDEX

0- Breaking our 90-day disclosure deadline to oppose robot manufacturers that endanger end-users

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.

We generally abide to a 90-day disclosure policy, however in this story, we’ve broken it. Instead, we’ve decided to come public 50 days after the initial disclosure. The reasons are threefold:

  1. First, we are very concerned by the lack of cybersecurity (which lead to safety) measures the manufacturer has applied when shipping products. As roboticists we know how hard it is to build, maintain and ship robots. However, once you cross over a certain number of units sold (though again we encourage a security-first approach), including fleets, security must become a priority to ensure safety of users.
  2. Second, we are worried about the safety of end-users working side by side with these robots, many being used currently in hospitals to fight the current pandemic. We’d like to raise our voice and force the manufacturer to react for once.
  3. Third, we’ve given the manufacturer 2 deadline extensions and have still not seen appropriate security reactions: a first one with an extension of 15 days to allow them to work on the issues. The second one, with again 15 more days for a final public reaction.

1- Taking a closer look at AMRs

Over the past years several robot manufacturers have repeatedly[1][2][3][4] demonstrated that care very little about cyber security and the associated risks on both, end-users and other parties across the supply chain. We urge stakeholders in robotics to quickly start learning and caring about cyber security, and to start investing on it to mitigate their exposure to hazards:

In view of this landscape, Alias Robotics started a few months ago researching the situation with Autonomous Mobile Robots (AMRs), a new trend of machines that have the intelligence to make decisions when faced with new or unexpected situations, replacing the traditional Automated Guided Vehicles (AGVs)[5]. AMRs are rapidly growing and used across different areas of application, with some of the top ones displayed below:

At Alias we’re increasingly cooperating with some of the top leading firms in this area, ensuring we add value to our customers on each step. Our bottom line remains the same, to remove 0-days from robotics while working closely with robot manufacturers. Unfortunately, we keep observing how some manufacturers ignore our responsible disclosure reports, try to avoid investing resources on security and/or even attempt to silence us with either legal or PR means.

This entry touches into our security research experience with the Danish Mobile Industrial Robots firm and their MiR series of robots. Mobile Industrial Robots (MiR) is owned by Teradyne, a company that was previously reported to supply tenths of thousands of insecure robots to industry[6].

We are terribly concerned about the use of MiR technologies in real scenario and our research and short cooperation demonstrated that their security attitude is not ready for real applications in the presence of malicious threats. We urge MiR users to demand a prompt and serious security response on these robots, across the whole supply chain. Similarly, we encourage distributors and integrators to learn about their liabilities and similarly demand MiR to be held accountable for shipping thousands of insecure robots putting their businesses at risk.

2- Timeline

2019: MiR gets first notifications of their insecurities. No reaction.
MiR receives from third parties several reports about critical vulnerabilities that compromise safety of their systems and their users. These reports are disregarded.


2020: Alias Robotics starts researching MiR.
Alias starts researching MiR technologies and ensures their research is centered on their last version through a somewhat conflicting and unclear customer support process involving MiR and their distributors.

  • Very unclear versioning system (distributors and MiR not aligned).
  • No release notes available.

4th May 2020: Alias Robotics responsibly reports MiR of vulnerabilities and concerns.
After a few months of research, Alias Robotics responsibly submits 5 reports capturing critical vulnerability groups to MiR, giving them a short deadline (20 days) and informs about the following additional concerns identified on:

  • Customer service not attending critical safety and security requests.
  • Unclear versioning system while speaking with MiR employees.
  • Unclear legal framework between customer and distributor.

NOTE: In case you're wondering how did we landed from 5 initial vulns reported to MiR, to the final 14 disclosed: we produced them by further triaging the original reports. The disclosed flaws resulted from further triaging the original 5 records in our archive. At the time of writing we have catologued more than 100 additional security flaws that might be subject to be considered vulnerabilities. Further investment in security and triage is required to make safe used of these robots. Alias Robotics is actively investing resources to mitigate all identified flaws and serve it to end users as part of their Robot Immune System (RIS)


12th May 2020: MiR and Alias Robotics meet to discuss a cooperation.
Alias Robotics held a meeting with MiR’s directors and tech leads to discuss cooperation possibilities:

  • Alias presents their approach, aim and final goal: remove 0-days from robotics and ensure end-users remain protected. Highlights that the situation with MiR is of high criticality.
  • MiR introduces a 10-year non-mutual NDA contract for engaging into a cooperation. The contract would need to be signed prior any cooperation discussion.[7]
  • Alias introduces the Robot Immune System (RIS) as an ongoing development effort where mitigations for this robot were actively being filed for MiR products.
  • After having researched the robots, Alias questions privacy terms for the robot and the customer support received.
  • MiR presents no answer and postpones that discussion for further interactions.
  • MiR informed their ongoing efforts on patching the flaws.
  • Alias confirmed that provided MiR shows will and evidence/actions on this direction, Alias would be happy to cooperate and be flexible on the release deadlines to ensure utmost safety.
  • MiR refrained though from providing evidence without an NDA in place.

13th-14th of May 2020: Alias Robotics and MiR try clarify outstanding issues on privacy, software lifecycle, updates and customer support.

  • In a series of quick interactions, Alias insists on obtaining answers on privacy terms, update processes, versions and customer support.
  • MiR through their directors inform:
    • All communications, requests and liabilities should be directed to the distributors.
    • Software updates are only provided to solve “specific” issues, without any further clarification. Unclear scope and definitions for software updates.
    • MiR does not provide end-users or defenders with access to the release notes. Neither vulnerability advisories.
  • When inquired about further evidence or details, no answer was obtained.

15th of May 2020: Alias rejects legal terms proposed but offers on best faith two ways forward: a) additional help or b) an extension of the disclosure period if MiR can show evidence of security actions.

  • After working with legal advisors, Alias returns to MiR the 15th of May informing that the legal terms were not acceptable.
  • Alias proposes two avenues for forward cooperation instead:
    • Alias to help MiR performing a short threat modeling and an in-depth security penetration testing with mitigation recommendations together with its engineering teams. This required funding for the security activities.
    • Alias to grant MiR an extension of the disclosure period if MiR could show enough evidence of their security activity.
  • MiR promptly reacted indicating that they were willing to provide further evidence.

18th of May 2020: Alias Robotics and MiR meet to discuss an extension of the disclosure period.

  • Alias Robotics explains the rationale behind their rejection of the proposed legal terms. Essentially,
    • a) unnecessarily binding,
    • b) would block Alias from serving other MiR owners in the future and
    • c) do not guarantee that appropriate security measures will be implemented.
  • MiR presents a short presentation discussing the different flaws first reported and how they planned on tackling them.
  • Alias Robotics responsibly questions several of the mitigations proposed during the call receiving confirmation from MiR that such flaws do affect older versions shipped across their fleet vehicles (not restricted to MiR100 but also potentially scaling to MiR200, MiR500 and MiR1000).
  • Alias Robotics offers advice and corrects MiR approach to security during the call (which was presented solely from an IT angle) and highlights the importance of considering OT and robotics-specific aspects related to safety.
  • Alias Robotics volunteered to dedicate additional engineering resources to evaluate all the presented material and consider granting an extension of the deadline.

22nd of May 2020:Alias dedicates further engineering resources and decides to grant MiR an extension on best faith, regardless of the unmet security expectations.

  • After evaluation, Alias Robotics informs MiR that their measures are not appropriate.
  • Alias Robotics extends the deadline 15 more days and informs MiR that no further engineering resources will be dedicated unless MiR can support Alias’ research.

2nd of June: MiR demands further assistance from Alias.

  • After more interactions, MiR offers some minor updates on their User Manuals and demands additional help from Alias. These updates once again focus only on IT aspects and disregard the overall security landscape and impact of the reported flaws.
  • Alias informs that due to a lack of funding, we don’t have additional bandwidth to help.

4th of June: MiR once again demands further help from Alias.

  • MiR once again demands help with a disappointed tone further adding that:
    “We had hoped you would provide meaningful guidance in this effort. If that’s not the case, we’re uncertain as to why you bothered reaching out to us in the first place.”
  • Alias highlights again their constantly supportive and responsive attitude so far, 1) presenting evidence upfront, 2) facilitating additional extensions of time as requested (even without clear actions) and 3) attending different calls adding value on every single one.
  • Alias also clarifies that the lack of funding and security-alignment is a limiting factor for future further cooperation.
  • Alias provides a clear position in favour of the robot end user.

24th of June: Alias Robotics discloses their findings publicly in cooperation with CERTs.

3- Our experience attempting to cooperate with MiR


  • Much needs to be done on security to protect the existing MiR fleets and ensure these robots operate safely.
    • 14 vulnerabilities disclosed and hundreds of other security flaws identified yet not triaged due to lack of cooperation.
  • The manufacturer knew about some of these vulnerabilities many months ago.
  • Short deadlines forced into the vendor encouraged a prompt response favouring end-users. Given the severity of the flaws and the associated risks, we gave MiR a short deadline to react (20 days). We later extended it twice to accommodate communications and requests.
  • Confidentiality terms should be proportional to the work performed. Even though MiR decided to avoid funding further security research, they continuously kept asking for signing a disproportionated 10-year NDA. We systematically felt forced to sell our silence in exchange for further conversations.
  • Security research needs to be funded. We found ourselves confused when MiR, after a series on interactions and having finalized our self-funded budget, kept requesting for support.
  • IT security vs security in Robotics. We voluntarily participated in several meetings with MiR answering questions. Specially, we repeatedly clarified to MiR tech team that there was a strong difference between security in IT and its other facets, including OT among others. MiR has ignored all suggestions and focused solely on IT security. There’s much more than IT security in robotics and MiR is disregarding it.
  • “Out of security control” robots being shipped. MiR confirmed that they don’t control the robots they serve and thereby, can’t assure they are at their most secure state. It’s up to distributors and integrators to perform such updates, and to respond for any consequences. It is to day, uncertain whether these entities are liable for these issues.
  • Companies using MiR to serve end-users ignore, to date the risks and hazards.
  • The end user is the weakest link of the chain, and likely, the one suffering the adverse impacts from cybersecurity breaches.

After having served some clients using MiR technologies and having seen the use and concerns they presented, we decided in early 2020 to take a step forward and kick-off a short self-funded research action on MiR’s products. Throughout these months, we’ve had many conversations with MiR engineering, management, customer support and even with their clients.

Our research has focused on the Mobile Industrial Robots (MiR), specifically the MiR100 and MiR200 however from our findings, many of the flaws identified seem to apply to several of the vehicles of their fleet (including MiR250, MiR500 and MiR1000). This is not uncommon and our researchers have seen this in the past with other vendors.

The MiR100 is presented as a versatile Automated Mobile Robot (AMR) used across industries, including healthcare sectors. This collaborative robot is designed to work among humans, pulling and carrying loads, for which it is equipped with an array of sensors.

As mentioned before, often, robot manufacturers do not consider security in their robots development, which is the case with MiR, since its producers lack of a security team and/or expertise and are unwilling to invest in security. Furthermore, the company presents an unclear distribution of the firmware updates, for which end-users have to pay, and do not hold privacy policies at all.

MiR PROservice. Software updates require a license which must be paid. It’s unclear what exactly includes such software updates and where/how security ones are filed into the general robots. Source:MiR PROservice

The whole situation becomes even more critical when the supply chain has an unclear legal framework, as it’s the case, in which responsibility is shifted to distributors and integrators and the security responsibilities and liabilities are often use-case specific.

The following subsections summarize some of the major findings and experiences of our research period in an open tone and while attempting our best to preserve the manufacturer’s image:

| Hundreds of flaws found, many vulnerabilities

Since we could not secure funding for further security research, much of the triage remains open and to be done. Together with this report, we’re publicly disclosing 14 confirmed vulnerabilities that according to our testing apply to all MiR products of the MiR100 and MiR200 series. In addition, and as informed by MiR themselves, these flaws might also apply to MiR250, MiR500 and MiR1000.

In an attempt to protect the end-user and the manufacturer, we’ve decided not to disclose any untriaged flaws. This work will remain inside of Alias for the time being.

| Pressuring manufacturers on security is a “good” thing

Our approach and policies are strongly in line with our desire to improve the robotics industry response times to security bugs (note our motto is to “remove 0-days from robotics”), but also results in softer landings for bugs marginally over deadline. According to past research[8], most vendors are ignoring security flaws completely.

Our experience with MiR determined that the manufacturer knew about many of several of the critical flaws reported more than 6 months before we first filed our report yet it had taken no action to mitigate it. Business models solely focused on sales boosting via third parties present relevant flaws when the resulting products need to care about security. As a reaction to our proactive research, disclosures and communications, MiR has reacted. Even though not enough, and the current products (MiR100, MiR200 and possibly all others) still present several hundreds of flaws, many of which we’ve confirmed to be vulnerabilities, our pressure already shows a good progress on the manufacturer’s security attitude.

We call on all researchers to adopt disclosure deadlines in some form. Creating pressure towards more reasonably-timed fixes will result in smaller windows of opportunity for cybercriminals to abuse vulnerabilities. Given the direct physical connection with the world that robots have, in our opinion, vulnerability disclosure policies such as ours result in greater security in robotics and an overall improved safety. Again, a security-first approach is a must to ensure safe robotic operations and to minimize 0-days.

In this case, our pressure and short deadlines forced MiR to react quickly.

| Confidentiality is good to serve customers, when established appropriately

We believe that confidentiality is key to establish trust relationships when cooperating in cybersecurity. We have NDAs with most of our customers and remain open to guaranteeing confidentiality provided these terms protect the end-user.

While respecting the core of the privacy of our non-confidential conversations with the manufacturer, we must complain about the continuous attempt to enforce a non-mutual (by clauses, though funnily title indicated differently) confidentiality agreement on us. One that according to our legal advice, imposed extremely strong restrictions for us for present, past and future research on any of MiR technologies.

Alias Robotics decided not to move forward with such confidentiality terms and instead, while understanding the importance of confidentiality for MiR, re-attempted to highlight first the importance of reacting with appropriate security actions and remediations protecting the end-user. The following short text comes written by our CTO from interactions with representatives from the manufacturer:

“We just finished a deep dive into the document with our lawyers and unfortunately, I am sorry to inform you that the current legal terms are far from acceptable for us. Mainly: a) these terms are too binding, b) we have yet no understanding of the cooperation or joint activity that will happen afterwards to consider such binding terms and c) specially, this setup does not impose any responsible timing restrictions whatsoever. We hope you kindly notice that our initial deadline was imposed to ensure we all act on best faith and protect end users of these technologies.”
Víctor Mayoral Vilches, CTO at Alias Robotics (May 15th, 2020)

Alias Robotics offered MiR two options:

  • continuing with funded confidential discussions or
  • disregard legal restrictions and hold another call where MiR would disclose further details of their mitigation activities to relax the deadline

MiR chose the second option and Alias decided to take a step back and focus on other projects. Still, fulfilling our promise, we supported the manufacturer, had another call and relaxed the deadline, yet continuously kept being asked to sign an NDA which we never understood.

| IT, OT, IoT and Robotics, different areas, different security

IT, OT, IoT or robotics are all technologies. Different ones. As such, each one of these is subject to operate securely, that is, free from danger or threats. Security in robotics is different from security in IT systems.

We have repeatedly insisted on this with MiR and they've paid no attention:

Images from Mobile Industrial Robots (MiR) documentation indicating a purely `IT` security approach.

Though we take proud on having pushed MiR them to react on IT security, this is still very far from acceptable. Caring only about IT security will discard many of the threats that are specific to robotic systems.

From [9]:

Security topic IT OT (ICS) I(I)oT Robotics
Antivirus widely used, easily updated complicated and often imposible, network detection and prevention solutions mostly Similarly complicated, lots of technology fragmentation (different RTOSs, embedded frameworks and communication paradigms), network detection and prevention solutions exist complicated and complex due to the technology nature, very few existing solutions (e.g. RIS), network monitoring and prevention isn't enough due to safety implications
Life cycle 3-5 years 10-20 years 5-10 years 10+ years
Awareness Decent Poor Poor None
Patch management Often Rare, requires approval from plant manufacturers Rare, often requires permission (and/or action) from end-user Very rare, production implications, complex set ups
Change Management Regular and scheduled Rare Rare Very rare, often specialized technitians
Evaluation of log files Established practice Unusual practice Unusual practice Non-established practice
Time dependency Delays Accepted Critical Some delays accepted (depends of domain of application, e.g. IIoT might be more sensitive) Critical, both inter and intra robot communications
Availability Not always available, failures accepted 24*7 Some failures accepted (again, domain specific) 24*7 available
Integrity Failures accepted Critical Some failures accepted (again, domain specific) Critical
Confidentiality Critical Relevant Important Important
Safety Not relevant (does not apply generally) Relevant Not relevant (though depends of domain of application, but IoT systems are not known for their safety concerns) Critical, autonomous systems may easily compromise safety if not operating as expected
Security tests Widespread Rare and problematic (infrastructure restrictions, etc.) Rare Mostly not present (first services of this kind for robotics are starting to appear)
Testing environment Available Rarely available Rarely available Rare and difficult to reproduce
Determinism requirements (refer to [6:1] for definitions) Non-real-time. Responses must be consistent. High throughput is demanded. High delay and jitter may be acceptable. Less critical emergency interaction. Tightly restricted access control can be implemented to the degree necessary for security Hard real-time. Response is time-critical. Modest throughput is acceptable. High delay and/or jitter is not acceptable. Response to human and other emergency interaction is critical. Access to ICS should be strictly controlled, but should not hamper or interfere with human-machine interaction Often non-real-time, though some environment will require soft or firm real-time Hard real-time requirements for safety critical applications and firm/soft real-time for other tasks

| Robots out of security control, a compromised supply chain

As first written at Robotics and its compromised new supply chain, we reckon that companies like Universal Robots (UR) or Mobile Industrial Robots (MiR), when analyzed from a cybersecurity angle present a troubling scenario: they ship robots which they do not control. In other words, there are thousands of these robots out of security control and maintenance. It’s up to the distributors and integrators to maintain them secure and they’re bound to respond for any liabilities.

For more on the current supply chain of collaborative robots, refer to Vulnerability coordination and disclosure in robotics.

| Downstream manufacturers (lack of) concerns

With all the above, we went ahead and tried speaking with some MiR robot users. These robots don’t come pre-programmed for a particular task, so we pick companies using them while serving real applications. This group is sometimes also referred to as downstream manufacturers. Examples include companies using these machines for semi-autonomous disinfection in hospitals or airports. Particularly, we tried to speak with companies creating robots using MiR robots and inquired on their reaction when presented with non-confidential information related to the security flaws we found. The overall response was concerning at the very least and only weeks after a notification was sent, we saw some minor legal responses.

We collect in here some of the thoughts and interactions we’ve had as part of our research. For better framing, we present the input received by grouping downstream manufacturers by use cases:

MiR + Ultraviolet light for disinfection

Lots of companies are launching mobile robots for disinfection tasks. One of the growing examples is UVD Robots, a company that branches from Blue Ocean Robotics robot factory. UVD Robots (also the name of the robot) are Ultra Violet (UV) light disinfection systems built on top of a MiR100 and used across many hospitals centres for disinfection and sterilization tasks.

According to sales representatives of the firm, these robots cost 60.000 EURs each. The price isn’t negligible, even for organizations and moreover, stemming from our findings, the current use of these robots present security hazards that can cause human harm. As it involves the use of the UV light, it can affect humans causing suntan, sunburn or even a reportedly increased risk of skin cancer, among others. This technology has been increasingly widespread due to the COVID-19 and their manufacturers don't seem to be concerned about their robot’s security unless it is connected to the Internet:

“... it is my understanding that a device must be connected in some form to the internet, via Wifi or mobile data to be at risk from a cyber attack. As our robot operates completely independently from the internet, I don't see how it can be externally hacked.”
Simon Ellison, Vice President Sales & Marketing (May 11 2020)

Again, a clear sign of concern. This time coming from one of the executives of the firm. This shows evidence of how relevant it is for robotic firms to invest now in robot cybersecurity. Moreover, it also confirms why the misuse of communication to silence and exercise social peer-pressure on security researchers is likely one of the reasons why currently, the general public, does not differentiate between cyber criminals and hackers (or security researchers) leading to mistaken assumptions.

“… Some additional reassuring information is that it is impossible to start the UV-C lamps on the robot with the physical mechanical operation of a safety button.”
Simon Ellison, Vice President Sales & Marketing (May 11 2020)

Once again, we see how manufacturers mistake security and safety. We’ve touched on this deeply in the past and we encourage you to read through our research to gain a better understanding.

MiR + robotic arms for laboratories, hospitals or education

Enabled robotics implements Universal Robots’ robot arms mounted on MiR mobile platforms. They aim to combine the mobility of AGVs with the capability of solving complex manipulation tasks that UR promises. However, by selecting two vulnerable building robotic blocks, they end up with a flawed integrated system which is vulnerable to attacks over secure and insecure networks.

Their executives don’t seem to care though:

“We are aware about the potential challenges of using the products on a network with access to the internet or on insecure local networks.”
Lars-Peter Ellekilde, Founder and CEO Enabled Robotics (Apr 27 2020)

4- Week of MiR bugs

Earlier on in January, the manufacturer, Universal Robots, introduced the National Cobot awareness day in the US. Following a similar approach, in March, we launched the "week of Universal Robot bugs"[10], a community oriented effort to foster security awareness in Universal Robots' robots.
After having found all this evidence on MiR and after identifying threats and confirmed several vulnerabilities, we decided to make another week of bugs exercise. This time, the week of Mobile Industrial Robots’ bugs (or week of MiR bugs for short).

By doing this, our goal is to empower end-users, distributors and system integrators of Mobile Industrial Robots’ solutions with the security information they so much require to securely make use of this technology.

During 5 working days, Alias' team in cooperation with other researchers dedicated resources to openly file security flaws and receive the users' input. Particular credit to Bernhard Dieber and Benjamin Breiling for their support and contributions throughout the week of MiR bugs. Together, we catalogued and publicly exposed the results in the Robot Vulnerability Database (RVD)[5:1]. We encourage all robotics practitioners and security researchers, with past experiences using Universal Robots technology, to openly file a ticket at the Robot Vulnerability Database (RVD).

NOTE: The disclosed flaws resulted from further triaging the original 5 records in our archive (that were first delivered to the vendor). At the time of writing we have catologued more than 100 additional security flaws that might be subject to be considered vulnerabilities. Further investment in security, triaging and mitigation is required. Alias Robotics is actively investing resources to mitigate all identified flaws and serve it to end users as part of their Robot Immune System (RIS)

Our ultimate goal is to advise on best security practices with these robots regarding, both, security and safety.

5- Mistakes and things we learned on the way

Of course, not everything from this story is about the results we found. Before that, we’d like to acknowledge and thank all the parties, including existing clients, intermediaries and mediators, who provided support and input during the process. Special credit to Bernhard Dieber.

We credit them back for how much we learned on the way and thank them for indicating to us the (likely) many mistakes we’ve made. We hope to learn from this on future projects.

Here’s a summary of what we believe we need to improve as well as some mistakes we hope not to make again in the future. We encourage other firms operating in robot cyber security to consider them carefully:

  • Communication is extremely important, and hard in security: “Human APIs are the hardest - Morgan Quigley”. We stole this from Morgan, and sincerely share it 100%. It became terribly difficult for usto us to explain to MiR how security companies operate while doing it. From their reaction, we clearly didn’t quite manage to fully understand each other. Once again, it’s our belief this comes from a miscommunication and an attempt to silence and exercise social peer-pressure on security researchers. The general public, including many engineers and executives do not differentiate between cyber criminals and the so called ethical hackers (though we prefer security researchers).

It was very hard for us be under the constant pressure of having to sign an NDA to speak of any future possible cooperation. We definitely need to improve the communication on our end.

  • Don’t be pushy with offering help for securing a contract, recommend third parties and state clearly your limitations and bandwidth.
    Frequently ethics is a matter of personal choice, a desire to act for the betterment of security, as opposed to the private interests of oneself or your group/company. Our internal policies try to ensure our attitude remains ethical. Very important in cyber security. For that purpose we never ask for money in exchange forof our findings. Also out of our code of ethics, we don’t ask for money in exchange of confidentiality, we advocate for disclosures as a way to empower defenders.

However, when working in security, often, further security research is required which is terribly costly (in terms of engineering time and talent) and we certainly need to somehow fund it. We feel we were not very pushy with MiR on this (or maybe we were?) and neither clear enough on the internal restrictions we had to continue supporting them. We believe communication failed on our end. We made an attempt to encourage them to work with someone else but MiR continued demanding help from us as if it was our responsibility.

On future iterations, we will try our best to be very transparent and clear from the very beginning on our limitations.

  • Include mediators early in the conversation and throughout the process: We’ve got some nice experiences already with a number of mediators and CERTs. Most of them reallyreal nice and though it’s sometimes difficult to attend their requests, it helps very much set a professional tone for both parties. One that’s centered around common security practices.

6- Results

Opposed to our previous security sprint for Universal Robots[11], we decided this time to put more focus on quality and exploit complexity. In particular, our team focused on developing more elaborated exploits. Robot viruses or instances of malware that allowed demonstrating how we could vulnerate the robot’s safety subsystem, its privacy and/or even its update process in an ad hoc manner.

RVD ID CVE ID Title
RVD#2558 CVE-2020-10276 Default credentials on SICK PLC allows disabling safety features
RVD#2566 CVE-2020-10269 Hardcoded Credentials on MiRX00 wireless Access Point
RVD#2557 CVE-2020-10270 Hardcoded Credentials on MiRX00 Control Dashboard
RVD#2555 CVE-2020-10271 MiR ROS computational graph is exposed to all network interfaces, including poorly secured wireless networks and open wired ones
RVD#2554 CVE-2020-10272 MiR ROS computational graph presents no authentication mechanisms
RVD#2560 CVE-2020-10273 Unprotected intellectual property in Mobile Industrial Robots (MiR) controllers
RVD#2556 CVE-2020-10274 MiR REST API allows for data exfiltration by unauthorized attackers (e.g. indoor maps)
RVD#2565 CVE-2020-10275 Weak token generation for the REST API
RVD#2563 CVE-2017-18255 The perf_cpu_time_max_percent_handler function in the Linux kernel allows local users to cause a DoS
RVD#2564 CVE-2017-7184 The xfrm_replay_verify_len function does not validate certain size data after an XFRM_MSG_NEWAE update, which allows local users to obtain root privileges or cause a DoS
RVD#2568 CVE-2020-10280 Apache server is vulnerable to a DoS
RVD#2569 CVE-2020-10279 Insecure operating system defaults in MiR robots
RVD#2562 CVE-2020-10277 Booting from a live image leads to exfiltration of sensible information and privilege escalation
RVD#2561 CVE-2020-10278 Unprotected BIOS allows user to boot from live OS image

NOTE: The final disclosures result from further triaging the original 5 records delivered to the vendor. At the time of writing we have catologued more than 100 additional security flaws that might be subject to be considered vulnerabilities. Further investment in security, triaging and mitigation is required. Due to a lack of understanding with the manufacturer, Alias Robotics will not report vulnerabilities to MiR any further however, Alias Robotics is actively investing resources to mitigate all identified flaws and serve it to end users as part of their Robot Immune System (RIS)

During the 5 days of the robot cybersecurity sprint, Alias Robotics together with other contributors, performed testing activities and collected dozens of bugs resulting in a total of 143 different security bugs on Mobile Industrial Robots robots. From this total count, we triaged a few dozens, prototyped exploits and and ended up publicly disclosing 14 vulnerabilities with 11 new CVE IDs. Of course, much remains to be done to secure these robots:

As we did in the past, our advice to users is to ** take action immediately** and seek for existing security solutions for these robots. To ensure no bad actors can directly benefit from our work, the exploits produced during the week will not be open sourced. Instead, the exploits for robots will be available for research purposes via alurity, our robot cyber security toolbox. Requiring a license and meant for academic or industrial research purposes, alurity is a modular and composable toolbox for robot security. Featuring dozens of different robot cyber security tools, it simplifies and speeds up the cyber security research in robotics. Particularly, exploits of this week of Mobile Industrial Robots’ bugs have been embedded into robosploit, our robot exploitation framework (available as part of alurity).

The following subsections touch into some of our research highlights. For complete details about our disclosures, refer to the Robot Vulnerability Database (RVD)[12].

RVD#2558:Default credentials on SICK PLC allows disabling safety features
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.

Link: https://github.com/aliasrobotics/RVD/issues/2558

Exploit
Robosploit presents a PoC automated script making use of pymodbus and modifying safety configurations from an internal network. See CVE-2020-10269 for an entry point.
Life demonstration
70 Kg+ robot with safety disabled is commanded against an object colliding at 1,5 m/s (5,4 km/h).





RVD#2557: Hardcoded Credentials on MiRX00’s Control Dashboard
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.

Link: https://github.com/aliasrobotics/RVD/issues/2557

Exploit
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.
Life demonstration
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#2556: MiR REST API allows for data exfiltration by unauthorized attackers (e.g. indoor maps)
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.

Link: https://github.com/aliasrobotics/RVD/issues/2556

Exploit
Robosploit exfiltrates metadata and images to a desired folder via the REST API.
Life demonstration
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#2555: MiR ROS computational graph is exposed to all network interfaces, including poorly secured wireless networks and open wired ones

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).

Link: https://github.com/aliasrobotics/RVD/issues/2555

Exploit
Robosploit ships an exploit to command the exposed ROS computational graph.
Life demonstration
Robot’s actuators and sensors are commanded to play some fun tunes. Any desired behavior could be programed remotely and wirelessly.





RVD#2554: MiR ROS computational graph presents no authentication mechanisms

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.

Link: https://github.com/aliasrobotics/RVD/issues/2554

Exploit
Robosploit exploit provides a PoC that exploits the lack authentication requirements of the ROS computational graph.
Life demonstration
Robot in an ongoing mission is stopped by an unauthorized attacker with access to the computational graph.





RVD#2566: Hardcoded Credentials on MiRX00 wireless Access Point

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#2560: Unprotected intellectual property in Mobile Industrial Robots (MiR) controllers

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#2563: The perf_cpu_time_max_percent_handler function in the Linux kernel allows local users to cause a denial of service.

Before our cooperation with MiR, robots were still shipping with version 4.4 of the Linux kernel. 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#2564: The xfrm_replay_verify_len function does not validate certain size data after an XFRM_MSG_NEWAE update, which allows local users to obtain root privileges or cause a DoS

Also based on old kernel, 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#2559: net/netfilter/xt_osf.c does not require the CAP_NET_ADMIN for add_callback or remove_callback operations, allows local users to bypass intended access restrictions

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.

7- Discussion and conclusions

Bearing in mind the results, the conclusions of our research are:

  1. More than 100 security flaws identified that affect more than 10 robots. 14 flaws triaged and publicly released as vulnerabilities after months of cooperation with the upstream manufacturer leading to 11 new CVE IDs.

  2. Manufacturer advocates for a security by obscurity and have attempt to enforce us on a 10-year NDA. They don’t inform end users. No vulnerability advisory has been issued to date, even though they were aware of the insecurities since last year.

  3. The supply chain is compromised. Many of these robots are currently “out of security control”. Manufacturers don’t have direct control of the robot, and cannot ensure they are at its most secure state. Third parties are simply not well informed.

  4. These robots are not supplied with privacy policies. There is no information on how data collected is being used which presents an unclear scope of ethics and compliance with GDPR.

  5. Non-coherent business model where MiR continues shifting the legal liabilities to third parties (distributors, integrators) justifying themselves by indicating that their business model does not focus on supporting end-users, yet they charge them for additional support via MiR PROservice[13].

  6. Some of these manufacturers have a large portion of their market share, up to 75% of the UV autonomous disinfection market, according to Business Wire (link).

  7. Thousands of these insecure robots being used across industries. Some examples include:

    • Hospitals

      • UK University Hospitals of Derby and Burton NHS (link)
      • Italy Policlinico Abano (link) (link2)
      • China 2000 hospitals in China in the onset of the pandemic (link)
      • Australia IC Disinfection company in hospitals (link)
      • and many more

    • Airports

      • Germany Munich airport (link)
      • Belgium Brussels Airport (link)
      • Qatar Doha airport (link)
      • and more

    • Kindergardens

    • Logistics

      • Denmark 3 MiR1000 AMRs optimize warehouse logistics at ICM (link)
      • China MiR mobile robots enable intralogistics innovation at Bossard Smart Factory Logistics (link)
      • Finland MiR500 Robot Automates the internal transportation of different pallet sizes, improving productivity at Stera Technologies (link)
      • Mexico 7 MiR100 robots are working 3 shifts a day at Visteon, Mexico, improving productivity significantly (link)

    • Others

To this date, MiR has not facilitated any software update to us directly nor via their distributors (though we asked repeatedly). MiR claims that an upcoming firmware update will fix some of the outstanding issues however, 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.

While thousands of these robots remain insecure and likely, won’t be updated, we are proud to have forced MiR to react changing their practices for future units. Still, end-users need to seek for protection.

8- Security recommendations

We recommend Mobile Industrial Robot (MiR) to seek for professional security assistance and to consider receiving external assessment beyond ours to limit the risks they are imposing on end-users with their technology.

We encourage downstream robot manufacturers including UVD Robots (from Blue Ocean Robotics), Enabled Robotics or EasyRobotics among others, to a) exercise pressure on their OEM for security patches, b) perform a tailored security assessment and c) to immediately work with their users installing a protection technology to mitigate the outstanding security flaws. An example of such solution could be our Robot Immune System (RIS).

For distributors, system integrators and other middle-parties in the supply chain, we invite them to inquire about the liabilities they are exposed to as a result of offering a flawed robotic solution.

Alias Robotics’ Robot Immune System for MiR robots (available also for other downstream robots including UVD Robots, Enabled Robotics and others).

Finally, for end-users, we advise them to consider installing our Robot Immune System (RIS) to immediately correct the reported insecurities. RIS comes in the form of either a free R&D license or a Professional one. For more information, contact us.

  1. https://news.aliasrobotics.com/week-of-universal-robots-bugs-exposing-insecurity/ ↩︎

  2. https://cybersecurityrobotics.net/companies-use-vulnerable-collaborative-robots/ ↩︎

  3. https://cybersecurityrobotics.net/universal-robots-ip-disclosure-insecure-exfiltration/ ↩︎

  4. Mayoral-Vilches, V., Juan, L. U. S., Carbajo, U. A., Campo, R., de Cámara, X. S., Urzelai, O., ... & Gil-Uriarte, E. (2019). Industrial robot ransomware: Akerbeltz. arXiv preprint arXiv:1912.07714. ↩︎

  5. https://ottomotors.com/resources/info/agv-vs-amr ↩︎ ↩︎

  6. https://news.aliasrobotics.com/week-of-universal-robots-bugs-exposing-insecurity/ ↩︎ ↩︎

  7. Our legal advisors strongly rejected the presented contract and questioned its aim. In order to protect the manufacturer’s reputation and focus the message on mitigation and cybersecurity reaction, we’ll for now avoid disclosing the legal terms presented. ↩︎

  8. Kirschgens, L. A., Ugarte, I. Z., Uriarte, E. G., Rosas, A. M., & Vilches, V. M. (2018). Robot hazards: from safety to security. arXiv preprint arXiv:1806.06681. ↩︎

  9. Mayoral-Vilches, V. IT, OT, IoT and Robotics, a security comparison. Retrieved from https://cybersecurityrobotics.net/it-ot-iot-and-robotics-security-comparison/ ↩︎

  10. https://news.aliasrobotics.com/week-of-universal-robots-bugs-exposing-insecurity/ ↩︎

  11. https://news.aliasrobotics.com/week-of-universal-robots-bugs-exposing-insecurity/ ↩︎

  12. Vilches, V. M., Juan, L. U. S., Dieber, B., Carbajo, U. A., & Gil-Uriarte, E. (2019). Introducing the robot vulnerability database (rvd). arXiv preprint arXiv:1912.11299. ↩︎

  13. https://www.mobile-industrial-robots.com/es/solutions/mir-proservice/ ↩︎