Alias Robotics had the chance to assess the security of KUKA's robots in both lab and real industrial scenarios. This short case study summarizes some of the conclusions obtained while penetration testing these robots. Particularly, we briefly describe and provide a partial disclosure of two of the flaws found with robots operated by the KUKA KR C4 robot controller. For full transparency, we'd like to convey the message that work remains to be done on these robots from a cybersecurity standpoint. Due budget limitations, we left untriaged more than a dozen identified security bugs that seemingly affect this controller, across different robot end-points. We highly encourage users concerned about cybersecurity to further inquire and reach out.
This case study is the result of a cooperation involving different parties and mediators. Throughout the process, Alias Robotics interacted and cooperated with different groups including KUKA's Industrial Security Research & Development branch, the german Federal Cyber Security Authority (Bundesamt für Sicherheit in der Informationstechnik, BSI) or the Spanish National Cybersecurity Institute (INCIBE), among others. For the last two months, Alias Robotics responsibly cooperated with these parties which delivered KUKA the flaws for their consideration. At the time of writing KUKA has confirmed one of the flaws and is still working on the second one however more than 45 days have passed since our first notification so we've decided to come public and release this information for the defensive cybersecurity community.
We strongly believe that the mantra of security by obscurity is never a good idea and encourage both manufacturers and end-users to both, adopt deadlines and apply a security first-approach in robotics. With the Industry 4.0 even air gapped systems are becoming less secure by the day. With this in mind, in an attempt to raise awareness without risking end-users, the disclosures for the KR C4 controller do not include details on their exploitation. We openly invite defenders to reach out and proactively show their interest. We'd consider further disclosures on a use case basis.
NOTE 1: We urge users, integrators and distributors of these systems to take security measures against these flaws. In addition, we encourage them to take responsibility and perform security assessments like this one periodically to detect security flaws and prevent these robots from being easily targeted.
NOTE 2: Due to confidentiality restrictions, we're only able to share details applicable to KUKA KR C4 and KR 3 R540 however we can proactively inform that our team confirmed these and other flaws are currently exploitable in other robots from KUKA.
We take pride in our mission to make the robotics landscape safer for all, because there can be no safety without security.
Targeting Defenders, Manufacturer, Distributors, Systems Integrators but above all End Users, we make the results of our investigation openly available through the Robot Vulnerability Database (RVD) to empower users with all the information needed for a responsible use of these technologies. Also we invite the community as a whole to review our work, submit improvements and contribute filing tickets with new robot bugs and vulnerabilities.
Our pentesting methodology for robots consists of 9 steps as depicted below:
RVD#2549
Modern DRAM chips (DDR4 and LPDDR4 after 2015) are affected by a vulnerability in deployment of internal mitigations against RowHammer attacks known as Target Row Refresh (TRR), aka the TRRespass issue. To exploit this vulnerability, the attacker needs to create certain access patterns to trigger bit flips on affected memory modules, aka a Many-sided RowHammer attack.
This means that, even when chips advertised as RowHammer-free are used, attackers may still be able to conduct privilege-escalation attacks against the kernel, conduct privilege-escalation attacks against the Sudo binary, and achieve cross-tenant virtual-machine access by corrupting RSA keys.
RVD#2550
Critical services for operation can be terminated from windows task manager, bringing the manipulator to a halt. After this a Re-Calibration of the brakes needs to be performed. Be noted that this only can be accomplished either by a Kuka technician or by Kuka issued calibration hardware that interfaces with the manipulator furthering the delay and increasing operational costs.
Traditional cyber security practices and robot-specific cyber security needs don't overlap. We can no longer assume nor accept that taking care of ICS systems includes robots. Robots, due to their interactive nature and safety restrictions, require a dedicated security approach. This case study confirms this matter by presenting two exemplary flaws found throughout our research. In the event that the vulnerabilities we presented here were to be exploited by a bad actor, they could lead to a high impact on the availability of the robot in the best case (leading to economic losses) or to environmental or human damages in the worst one. As the saying goes: “An ounce of prevention is worth a pound of cure.” We highly encourage to take action for these robots. Perform security assessments like these periodically. Test as often as you can.
Assess your robot insecurities❯
