Teleoperation command hijacking and emergency-stop abuse

1. Summary

The Raven II teleoperated surgical robot communicates with its remote operator console over the Interoperable Telesurgery Protocol (ITP), which carries motion commands and feedback without encryption or authentication [1][6]. Because the robot accepts any well-formed ITP packet regardless of origin and acts on the packet bearing the highest sequence number, an attacker positioned on the network path between console and robot can read, alter, and inject commands to hijack robot motion [1][7]. The same lack of authentication lets a single crafted packet trip the robot’s software emergency stop, and repeated packets hold it in a halted state, denying operation mid-procedure [3][8].

2. Affected products & versions

3. The vulnerability in detail

The flaw lives in the communication link between the surgeon’s control console and the Raven II robot itself. Raven II is an open research platform built on Linux and the Robot Operating System (ROS), and it exchanges teleoperation data with its console using the Interoperable Telesurgery Protocol (ITP), a publicly documented protocol designed to let heterogeneous consoles and robots interoperate [1][6]. In the studied configuration this link runs over standard IP networking, and in real-world telesurgery scenarios it is expected to traverse public or otherwise untrusted networks so that a surgeon in one location can operate on a patient in another [6][7]. The protocol’s openness is a design goal for interoperability, but it also means an attacker knows the exact wire format they need to speak.

The root cause is an absence of two basic protections at the ITP layer: there is no encryption of the command and feedback stream, and there is no authentication of the packet source [1]. The robot’s control logic does not verify who sent a given command. It accepts any syntactically valid ITP packet from any source on the path and, critically, arbitrates between competing commands by acting on the packet carrying the highest sequence number [1]. This maps to a cluster of well-understood weakness classes: CWE-306 (missing authentication for a critical function — motion control accepts unauthenticated input), CWE-319 (cleartext transmission of sensitive information — commands and feedback, including video, travel unencrypted [7]), and CWE-345 (insufficient verification of data authenticity — the robot trusts the highest-sequence packet without confirming its origin or integrity).

The mechanism that turns this into control takeover is a sequence-number leading attack. Because the robot always honors the highest sequence number it has seen, an attacker who can observe the current sequence number and then transmit a packet with a higher one effectively wins the arbitration and supplies the command the robot will execute [1]. There is no cryptographic binding between the legitimate console and the packets the robot obeys, so “highest number wins” becomes “attacker wins” the moment the attacker can inject at all.

The primary precondition is an on-path, man-in-the-middle (MITM) position between the console and the robot. In the demonstrations this is obtained on the local network — for example by ARP poisoning the segment or interposing on the connecting router — so the attacker sits between surgeon and robot and can remove, modify, or insert commands in the stream [7][8]. This is a demonstrated capability rather than an internet-default one: it requires the attacker to reach a network position on the path, which is exactly the position telesurgery-over-public-networks is likely to expose [6].

A representative end-to-end exploitation chain, as reproduced by the researchers, is:

1. Gain an on-path MITM position between the console and the robot (e.g., via ARP poisoning on the shared segment) [7][8].
2. Passively capture the unencrypted ITP traffic and extract the current sequence number from the command stream [1].
3. Inject a packet bearing a higher sequence number to take over robot motion, overriding the surgeon’s legitimate commands [1].
4. Alternatively (or additionally), send a “leading” packet whose commanded values exceed the robot’s safe limits, which trips the software emergency stop (E-stop) and halts the robot [3][8].
5. Repeat the leading packet to prevent the operator from resetting the E-stop, holding the robot in a halted, un-resettable state — a denial of service that stalls the procedure [8].

Framed against the researchers’ taxonomy, the same defect enables three attack classes: intention-manipulation and intention-modification (altering the command/feedback loop so the surgeon-robot perception loop drives unintended actuation), full hijacking (taking effective control authority over motion without credentials), and denial of service via E-stop abuse [1][6].

Proof-of-concept status: this was reproduced in a laboratory setting by University of Washington researchers, including a study with 20 participants operating the robot under attack [1][3]. The team also experimentally evaluated AES encryption of the link as a mitigation and proposed operator-signature biometric authentication as a complementary defense [1][3].

4. Discovery & timeline

The work was performed by University of Washington researchers Tamara Bonaci (lead author), Jeffrey Herron, Tariq Yusuf, Junjie Yan, Tadayoshi Kohno, and Howard Jay Chizeck (BioRobotics Lab co-director) [1][3]. The research was published as an arXiv preprint, “To Make a Robot Secure: An Experimental Analysis of Cyber Security Threats Against Teleoperated Surgical Robots,” in April 2015, with an author-hosted full text on the UW ECE site [1][2]. The University of Washington issued an official institutional announcement on May 7, 2015, describing the two demonstrated attack classes and the proposed operator-signature defense [3]. Because Raven II is an open research platform rather than a fielded commercial product, this was a research disclosure rather than a coordinated vendor advisory with a patch date; no fixed version is documented [1][3]. The work supported by NSF grant CNS-1329751 [3]. Follow-on academic research extended the threat model, including targeted-attack analysis (DSN 2016) and self-learning malware leveraging leaked ROS control data (USENIX RAID 2019) [4][5].

5. Technical reference

• CVE(s): none assigned (research platform; no vendor CVE).
• CWE: CWE-306 (Missing Authentication for a Critical Function), CWE-319 (Cleartext Transmission of Sensitive Information), CWE-345 (Insufficient Verification of Data Authenticity) [1][7].
• CVSS: no official vendor/NVD CVSS vector exists. If scored informally, the network-adjacent MITM precondition (an on-path position, not internet-default) would sit between CVSS Attack Vector Network and Adjacent; impact spans integrity (command hijacking) and availability (E-stop DoS), with the deepest real-world consequence — patient physical harm — falling outside what the CVSS impact metrics capture. The lack of a clean CVSS mapping is itself a key point (see section 6).
• Code/commit refs: none published; Raven II runs a Linux + ROS stack and the ITP link is the affected surface [1].

6. Consequence & CFSE path analysis

Real-world consequence: an attacker on the network path between a surgeon and a Raven II robot can alter or fully take over the robot’s motion during a procedure, or halt the robot at will, without any credentials. In a live telesurgery context the tangible outcome is patient physical injury from unintended actuation, or a procedure stalled mid-operation by an un-resettable emergency stop — physical-world harm to a patient, not merely data compromise.

Why the CFSE Path Score diverges from CVSS: CVSS impact metrics (confidentiality/integrity/availability of information) have no dimension for patient bodily harm or loss of physical control authority over a surgical actuator, and there is no CVE or official vector at all. The paths here are therefore UNSCORABLE by CVSS, which is exactly why the CFSE decomposition carries the weight. CFSE consequence bands and verdict:

• Verdict: CRITICAL.
• The entry decomposes the Raven II teleoperation attack into three co-dominant CRITICAL paths, all UNSCORABLE by CVSS and drawn from the 2015 UW “To Make a Robot Secure” research.
• PERCEPTION_TO_ACTION (co-dominant): a network MITM on the unauthenticated/unencrypted ITP link reads and alters the command/feedback stream so the corrupted surgeon-robot perception loop drives unintended actuation (PH4/DP4/AT3).
• DEVICE_CONTROL_SAFETY: full command hijacking, where the attacker gains effective control authority over robot motion without credentials and can override operator inputs to drive dangerous, patient-injuring actuation (PH4/AT3).
• DEVICE_AVAILABILITY: emergency-stop (E-stop) abuse, where a single unauthenticated packet triggers the robot’s own fail-safe to deny operation mid-procedure (EC3, PH3, AT2).
• Shared factors across all three paths: RE2 (on-path network MITM position, demonstrated but not internet-default), SR3 (protocol-class reuse across deployments using the same unprotected protocol), SX2 (per-link scale with no fleet mechanism), OR2 (operational recovery), and EV3 (reproduced/documented).
• No cap or systemic uplift applies, so the overall path_verdict is CRITICAL.

7. Remediation & mitigations

Grounded in what the researchers proposed and tested for this specific link:

• Encrypt the ITP command/feedback link. The researchers experimentally evaluated AES encryption of the teleoperation traffic; encrypting the stream removes the cleartext-transmission weakness (CWE-319) and raises the bar on injection [1][6]. Note the press caveat that encryption/authentication is low-cost/high-benefit but not by itself a complete defense against a determined MITM [6].
• Add source authentication / integrity to the link so the robot no longer obeys any highest-sequence packet from any origin, directly addressing CWE-306 and CWE-345 [1].
• Operator-signature (biometric) authentication: the UW team proposed continuously authenticating the operator via their movement/control signature, so that a hijacked or spoofed command stream can be distinguished from the legitimate surgeon [1][3].
• Harden the E-stop path against abuse: because a single leading packet can trip the software E-stop and repeated packets keep it un-resettable, the fail-safe logic and reset path need protection against unauthenticated triggering to avoid turning the safety mechanism into a DoS lever [3][8].
• Network isolation: avoid running the teleoperation link over public/untrusted networks where an on-path MITM is reachable; segment and protect the path between console and robot [6][7].

8. Sources

[1] To Make a Robot Secure: An Experimental Analysis of Cyber Security Threats Against Teleoperated Surgical Robots — arXiv (University of Washington: Bonaci, Herron, Yusuf, Yan, Kohno, Chizeck) — https://arxiv.org/abs/1504.04339 — Canonical primary source: defines the no-auth/no-encryption ITP defect, the sequence-number leading attack, command hijacking, single-packet E-stop DoS, the 20-participant study, and AES/operator-signature mitigations. Credibility: researcher-primary. [2] To Make a Robot Secure (author-hosted full-text PDF, UW ECE) — University of Washington, Dept. of Electrical & Computer Engineering — https://wp.ece.uw.edu/wp-content/uploads/sites/25/2014/05/arXiv_April_2015.pdf — Stable author-hosted full text confirming institutional provenance of the primary paper. Credibility: researcher-primary. [3] UW researchers hack a teleoperated surgical robot to reveal security flaws — University of Washington News — https://www.washington.edu/news/2015/05/07/uw-researchers-hack-a-teleoperated-surgical-robot-to-reveal-security-flaws/ — Official institutional announcement: two demonstrated attack classes, single-packet E-stop DoS, named authors (Bonaci, Chizeck), NSF CNS-1329751, and the operator-signature defense. Credibility: primary-advisory. [4] Smart Malware that Uses Leaked Control Data of Robotic Applications: The Case of Raven-II Surgical Robots — USENIX RAID 2019 (Chung, Li, et al.) — https://www.usenix.org/conference/raid2019/presentation/chung — Peer-reviewed follow-on: self-learning malware using leaked ROS control data to time a payload at a critical surgical stage; extends the threat model beyond 2015 MITM/E-stop. Credibility: researcher-primary. [5] Targeted Attacks on Teleoperated Surgical Robots (DSN 2016) — Alemzadeh et al. (IEEE/IFIP DSN 2016) — https://homa-alem.github.io/papers/DSN_2016.pdf — Independent peer-reviewed analysis of dynamic model-based targeted attacks against teleoperated surgical robots including Raven II; corroborates and extends the actuation-manipulation threat. Credibility: researcher-primary. [6] Security Experts Hack Teleoperated Surgical Robot — MIT Technology Review — https://www.technologyreview.com/2015/04/24/168339/security-experts-hack-teleoperated-surgical-robot/ — Reputable press confirming the three attack categories, the public ITP over standard networks as the enabling weakness, the repeated-E-stop DoS, and the low-cost/incomplete nature of encryption alone. Credibility: reputable-press. [7] Telesurgery Vulnerable to Remote Hacks, Hijacks — Kaspersky (official blog) — https://www.kaspersky.com/blog/hacking-robotic-surgeons/8570/ — Security-vendor coverage of the MITM control mechanics (remove/modify/insert commands), unencrypted video, and public-network exposure. Credibility: reputable-press. [8] Researchers hijack teleoperated surgical robot: Remote surgery hacking threats — Computerworld — https://www.computerworld.com/article/1365326/researchers-hijack-teleoperated-surgical-robot-remote-surgery-hacking-threats.html — Mainstream technical press: MITM on the connecting router intercepts surgeon-robot traffic, remove/modify/insert commands, and E-stop abuse halting the procedure. Credibility: reputable-press.