Disabling the target robot is less dangerous than the attacker having total control over the robot, but can be an
effective technique depending on the context nonetheless. Powering off the robot usually requires access to the
operating system running on the robot itself. Using a simple "poweroff" command (or equivalent) is often enough, as
this command is often not locked behind higher permissions. If it is, the attacker must first gain higher access
through some form of privilege escalation.
Mitigations
Limiting the users who can initiate the shutdown protocol on the robot greatly reduces the attack surface. Ensuring
that users with higher permissions can power off the robot will fully mitigate this attack, given that there is no
privilege escalation exploit present.
Detections
The robot itself powering off is fairly obvious. One could have a health check service that pings the robot
periodically to see if it is still available, and if not, it may have been powered off.
Ethical Considerations
Just as when physically powering off a robot, doing it via a software method can create a dangerous situation or do damage to it's surroundings. One should be aware of the consequences to the environment or others when a robot is turned of abruptly and when necessary take precautions.
Documented incidents with autonomous robots
During a pentest on the Jackal robot from Clear Path Robotics, admin access was granted by inputting default
credentials through SSH. With admin permissions, the linux command "poweroff" was initiated, and the robot shut
itself down. This also is the case with the Unitree as shown below.
