The xArm family of collaborative robots is rapidly growing due its low cost characteristic. Strictly speaking, this robot (while sometimes advertised as collaborative) does not include the sensing or logic to be considered collaborative on its simplest version (xArm 5 Lite) but xArm 6 and xArm 7 do so and may very likely join the group of "safe to be used close to humans", aka cobots. This nicely looking, cheap and well resourced (they certainly didn't reinvent the wheel) robot picked our interest due to a growing amount of clients in our surroundings considering it for a variety of automation applications. The aim of this report is to share the results on a first security assessment of the xArm family of robots. Particularly, we looked at the vulnerabilities and bugs that are affecting it, disclosed the most relevant to the original manufacturer and finally as usual, a short recap is landing here to avoid security by obscurity attitudes. For this particular recap, we decided to focus on the xArm 5 lite. Our research suggest that xArm 5 lite is the most widely used of the xArm family, being also the least expensive of the lineup means that safety measures, like collision detection via a torque force sensor, are not available on this model.
For this study we are coupling xArm5 lite Manipulator and the AC control Box. The main focus of this pentesting exercise is the controller itself since all the xArm family share the same. Making all the disclosed vulnerabilities relevant across xArm 5 lite, 6 and 7.
We found that these robots are vulnerable to multitude of security flaws. Any attacker on the network can easily identify them, target them and commend them at desire. We notified the vendor of the corresponding findings yet we heard nothing back, something we're observing lately from certain manufacturers. Beyond acknowledgement, we also find worrisome that the robot manufacturer does not seem to care about security not has a security advisory page to give its user base the tools and knowledge they need to asses properly the problems that might be affecting their robotic setups.
Given its low footprint, cost and availability xArm can be used in a multitude of scenarios from education to industry, however as exposed by our study, unless proper security measures are in place (and note air-gapping the robot is often not an option), these robots should not be used with humans around or in scenarios sensitive to environmental damages. Malicious actors targetting these robots can easily cause damages. We urge users of xArm to reach out for security measures and encourage UFactory to show interest on their insecurity.
We take pride in our duty to make the robotics landscape safer for all, because there can be no safety without security.
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.
Also we invite the community as a whole to review our work, submit improvements and contribute filing tickets with new bugs.
Our pentesting methodology for robots consists of 9 steps as depicted below:
RVD#656
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.
RVD#3322
RVD#3323
Alias Robotics believes in a responsible and coherent disclosure policy that is materialized usually on a disclosure deadline for new vulnerabilities, meaning that, based on the severity or actions of the manufacturer the deadline is subject to change. During this time we expect the manufacturer to develop a solution, and we will ALWAYS offer our technical expertise to their service in order to help.
According to our research, vendors, system integrators and final users are not aware of the security issues on their robots. So, for the sake of improving the safety of robots and the humans working alongside them, we believe reasonable time-fixed deadlines directly impact the window of opportunity a malicious operator have to exploit and abuse these vulnerabilities. To reflect this Alias Robotics, by policy, does not release publically the exploits we find.
Prior to the release of this case study and in compliance with our disclosure policy we shared with uFactory several vulnerabilities affecting the xArm family including the ones presented here.
UFactory raised almost 900K USD in their crowdfunding campaign for xArm reaching more than 200 users. On top of this, many more customers have approached this low cost industrial robotic arm. The interest in robotics is higher than ever, and uFactory has made an outstanding contribution making a robot that is both attractive and affordable. What it lacks is security. The wide range of adoption of this robot implies that it can be expected to be used by both seasoned robotics operator at an industrial environment or by a 10 year old that is discovering how this technology works. During this exercise we managed to disrupt operations, steal information and take over the robot. “Bad Operator” can do it too. Don’t let time be the only defense between you and an attack.Take proactive steps towards prevention.
Assess your robot insecurities❯
