Troopers - Day 2

Today's talks covered home & industrial robots. While robots are expected to have built-in safety to prevent them from harming humans or themselves, the speakers showed in several examples that security vulnerabilities could compromise that status:

• A humanoid robot, meant to assist its owner with home repairs, was compromised and turned into an evil robot that stabbed a tomato with a screwdriver. This is a PoC demo, but it indeed shows that a compromised robot would no longer control its movements and could hit a human in the same way.
• A remote exploit rebooted a robot and removed its safety configuration. The robot could then move without restriction, with violent movements, which could potentially hurt workers around it.

Other vulnerabilities that affect robots:

• Home robots usually come without physical security, which means an attacker can physically connect to some of their exposed ports. In one case, access to the SDcard (unsecured) revealed a QR code containing the Wi-Fi password!
• Robots can be infected with ransomware.
• A malware was found on an air-gapped industrial robot. This was a typical autorun malware meant to steal gaming credentials so it wasn't specifically targeted for the robot, but the fact that the robot was infected shows robots are not immune to malware.
• An industrial robot's action can be altered, even slightly, so that the product it manufactures contains small defects. Those defects, even if they are difficult to notice by humans, may have a big impact on the product which is created (robustness, safety, performance, etc.).

References:

• Hacking Robots before Skynet: paper video at HITBGSEC 2017 slides
• Breaking the Laws of Robotics: paper at BlackHat US 2017

It relies on two concepts:

1. Like ARM and its Thumb mode, MIPS has two different instruction sets: one with 32-bit word instructions, and another one (MIPS16) with 16-bit word instructions. However (and strangely, in my humble opinion), although most instructions of MIPS16 fit on 16 bits, it is possible to use extended instructions that will fit on 32 bits.
2. MIPS has a branch delay slot, i.e., the next instruction after the branch is executed (whether the branch is taken or not.)

The trick consists of using an extended instruction in the branch delay slot. The documentation says this should not be done as it causes "unpredictable results" but, in reality, if such a program is crafted intentionally, we see that emulators and disassemblers understand the code differently than physical hosts:

• Emulators/disassemblers consider the extended 32-bit instruction as one instruction and therefore execute it entirely as it is in the delay slot.
• Physical hosts only consider the first 16 bits as being part of the delay slot

Hence, different behaviour is observed and can be used to detect the underlying architecture.

See PoC GTFO vol 15, article 9.

PoC GTFO is a highly technical journal, with absolutely amazing and innovative articles. While elite, this technique is likely to be used in obfuscators, anti-disassemblers, and CTF challenges.

There were several other interesting talks today, including the vulnerabilities of yacht navigation systems, but let's keep the blog post short and refer you to the TROOPERS webpage for more information.

-- the Crypto Girl

Sign up for our weekly FortiGuard intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.