Threat Vectors in Robotics OTA Updates
Welcome to the “OTA Security Series!”. This collection is designed to help scaling robotics teams instill security into their OTA pipelines and defend themselves against imminent threats.
Setting the Stage
In their infancy, robotics teams use hacky measures to perform updates; to deploy software, they SSH into the robot, run git pull, and sometimes even compile code on the device!
This workflow is manageable with one or two robots, but as the fleet grows and the product matures, it becomes untenable. Customers have an expectation of privacy for their devices. They don’t want their vendors to shell into their machines. And even if they didn’t care, the manual updating flow collapses once you’re juggling more than a handful of robots.
Gone are the days of a single engineer tweaking a feature and quickly deploying it. Now, in the name of process1, there’s a concept of a release cycle: Software Engineers furiously program a new feature set, and when they’re finished, the code is ‘frozen’. Then, the Quality Assurance team tests the code to ensure it performs well on the robot. Finally, via an OTA update, the code is canary released to the fleet. It’s a structured and strict process with guardrails in place to promote safety and performance.
The shift from hacky scripts to OTA pipelines solves the scaling problem, but creates new challenges. OTA updates open up a larger attack surface. Engineers get so focused on making deployments work at all that they often miss the security risks they’re introducing.
This series is about these risks: how attackers exploit OTA pipelines, and what robotics teams can do to defend against them. In this first blog, we’ll look at the most common threat vectors, drawing lessons from past attacks in IoT and automotive.
Man-in-the-Middle Attacks
A man-in-the-middle (MitM) attack occurs when an attacker intercepts traffic between a robot and the update server. The attacker can observe, modify, or replace data in transit.
In OTA, this can be crippling if the robot accepts a fake update with malicious software or leaks sensitive information.
Attackers can:
Eavesdrop: Monitor what is being sent back and forth, like software packages, logs, or data dumps. These messages can contain IP or private customer data, which the attacker exploits.
Tamper: Swap in a malicious update or inject malware.
Impersonate: Pretend to be either the server or the robot for later advantage.
They have multiple ways to attack:
Let’s say that our robot wants to talk to the URL
https://cloudbucket.robot.comfor its newest update. When the robot requests the DNS, an attacker can inject a fake DNS2, pointing the robot to a malicious server. Without strict certificate validation, the robot will download the attacker’s update without question.Compromised Wi-Fi Access Point
Usually, when robots are deployed to customer sites, they are connected to a WiFi network, such as
warehouse_wifi. This network will have an SSID. With a $50 Wi-Fi adapter and open-source tools3, an attacker can clone the SSID. If the robot trusts SSIDs blindly, it will connect to the attacker’s network. Now, the attacker is in the driver’s seat, and all the traffic will flow through their router.An attacker might not even need to create their own WiFi network to succeed. Often, in logistics and manufacturing facilities, local routers are outdated and inexpensive, making them easier to exploit.
Before 2015, weak SSL/TLS made downgrade attacks common. An attacker could block HTTPS, force HTTP, and read or modify traffic in plaintext. If your robot doesn’t verify signatures on updates, it won’t notice the tampering. Today, modern TLS makes this attack rare, but it’s a reminder of why strict signature checks matter.
Let’s look at a real-world example of a MitM attack, the Jeep Cherokee Hack of 2015:
In 2015, security researchers demonstrated a remote exploit against the Jeep Cherokee. The attack chain started through the car’s infotainment system, which was exposed to an internet-connected service for OTA updates, among other pipelines.
The service had weak authentication and ran with high system privileges.
Once compromised, the attacker could pivot from the infotainment unit onto the vehicle’s CAN bus.
Over the CAN bus, they could send arbitrary messages to critical ECUs (engine, brakes, steering). Famously, the researchers cut the transmission of a Jeep while it was driving.
Chrysler had to recall 1.4 million of its vehicles!
Unauthorized Firmware Access
If an attacker can gain the ability to read, modify, or replace firmware, they own the system.
For OTA, that risk shows up in two ways:
Extract: Attackers pull firmware off the device (via debug ports or external storage) to reverse-engineer it or look for vulnerabilities.
Inject: Attackers load their own firmware onto your robot. Unlike application code, firmware persists across reboots and can even disable future updates.
Firmware attacks can be physical or remote:
Physical access is outside the scope of OTA, but teams should still be cognizant of it. Many early-stage companies start by shipping developer kit SoCs (Jetson AGX Orin Dev Kit). These dev kits often ship with the JTAG/UART debug ports exposed. So stay vigilant!
For OTA, the concern is insecure update paths. If your robots accept unsigned images or rely only on weak checks, an attacker can push malicious firmware remotely.
The importance of authentication was highlighted by the D-Link Router Firmware Vulnerability in 2019:
In 2019, Fortinet researchers found that several D-Link routers gave the ability to install arbitrary system commands via a script in the router’s firmware.
Because there was no authentication needed, commands could be executed as the root user!
D-Link responded days after the disclosure by declaring the affected models End-Of-Life. This meant that unless users replaced their hardware, they were stuck running exploitable firmware.
Downgrade / Replay Attacks
A downgrade or replay attack forces a robot to install an older version of software. Because the image was once validly signed, it still passes cryptographic checks, but it may contain known vulnerabilities.
If an attacker can get your robot to run on a software version with known CVEs, their job becomes easier. They don’t have to devise any zero-days. Instead, they can rely on often publicly documented details to attack.
Replay attacks often piggyback on other weaknesses:
Man-in-the-middle or DNS spoofing can redirect a robot to download an older package.
Local caches or storage of older versions let attackers trigger a reinstall.
Weak validation that checks only the signature, not the version or freshness, allows the downgrade to succeed.
Let’s see how this affected Android, the biggest mobile OS in the world:
A series of these exploits plagued Android devices in the 2010s. Every month, Android devices receive OTA updates. Each update would be a signed zip file that passes signature verification. However, for a long time, Android only checked that the signature was valid, not whether the update was newer than what was currently installed.
Attackers could grab an older, signed update from OEM archives or a device cache and push it back onto the phone. The update would pass signature checks, but re-enable known vulnerabilities. One infamous case was the Stagefright bug (2015), where a crafted MMS could execute code on the device. Rollbacks let attackers bring that bug ‘back to life’ even after it had been patched.
To remedy this, starting in Android 8.0, Google introduced rollback protection. This meant that devices kept a rollback index in a trusted, tamper-resistant storage. Each time an OTA update was installed, it would burn a higher version number into that rollback index. If you tried to downgrade it with a replay attack, the bootloader would fail to boot, even if the signature is valid.
Since most robotics fleets have never gotten to real scale, they haven’t experienced this problem. They allow rollbacks if the deployed software is failing. But mature organizations don’t do this. For example, Amazon consumer devices only ‘roll forward’. This is a best practice that limits the downside of reintroducing CVEs.
Conclusion
We’ve looked at three of the biggest OTA threat vectors: man-in-the-middle attacks, unauthorized firmware access, and downgrade/replay exploits. Each has burned IoT and Automotive companies in the past, and while there haven’t been any high-profile exploits in robotics, we’d like it if none of our readers set a precedent!
OTA updates are a crucial component of scaling a fleet of robots, but they also open the door for attacks. The best teams prioritize security best practices while building up their pipeline to mitigate potential threats.
In the next blog, we’ll talk about how to do just that. We’ll cover the best practices to keep OTA secure, so your robots can scale safely.
Series Index
Best Practices [coming soon]
OTA Security Diagram [coming soon]
An engineering manager’s favorite word!
DNS injection is when an attacker tampers with the DNS lookup process, tricking a device into resolving a domain name to the wrong IP address. This can happen if an attacker compromises the DNS resolver itself, or slips forged DNS responses into the traffic before the legitimate ones arrive.
See Aircrack-ng and hostapd.