Dead Reckoning: Hijacking Marine Autopilots

Dead Reckoning: Hijacking Marine Autopilots

Speakers: Carson Green, Master's Student, Colorado State University; Rik Chatterjee, PhD Student, Colorado State University

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=tFrZ75IECjg

Overview

In "Dead Reckoning: Hijacking Marine Autopilots," Carson Green and Rik Chatterjee from Colorado State University's System Cyber Research Lab unveil critical vulnerabilities within marine autopilot systems. Their research demonstrates how a malicious firmware update, delivered over the NMEA 2000 network, can lead to remote code execution (RCE) and arbitrary CAN message injection. The presentation culminates in a vivid demonstration of an address claim attack, effectively seizing control of vital marine network components.

This talk highlights a prevalent and often overlooked security gap in cyber-physical systems, specifically within the maritime industry. While marine vessels are frequently perceived as isolated or "air-gapped," their increasing modernization and reliance on interconnected electronic control units expose them to significant cyber threats. The researchers meticulously detail their responsible disclosure process, including informing the manufacturer and securing a CVE ID, underscoring the ethical imperative behind their work to enhance the cybersecurity posture of critical infrastructure.

The implications of this research are far-reaching. Beyond the immediate disruption of navigation, the ability to inject arbitrary messages into a marine CAN network could impact engine control, safety systems, and even GPS data, posing risks to commercial shipping, military operations, and search and rescue efforts. Green and Chatterjee's findings serve as a stark reminder that fundamental secure software development practices are often absent in these specialized embedded systems, necessitating a re-evaluation of security standards across the maritime sector.

Background

▶ Watch: Introduction and malicious firmware update demonstration (0:00)

The motivation behind investigating marine systems stemmed from the speakers' prior work on commercial vehicle cybersecurity, particularly their familiarity with the CAN bus and J1939 protocol. Recognizing the architectural similarities, specifically the use of NMEA 2000 over CAN in boats, drew them to explore this new domain. Modern marine vessels, from pleasure crafts to large shipping vessels, heavily rely on autopilots for critical functions such as maintaining heading, controlling the rudder, and interfacing with GPS and other navigational data. These systems, while vital, often lack the rigorous security considerations found in other IT environments.

A foundational understanding of the Controller Area Network (CAN) is essential to grasp the vulnerabilities discussed. CAN is a robust, two-wire, message-based network designed for embedded computers, or Electronic Control Units (ECUs), in harsh environments. It employs differential signaling and arbitration to manage communication conflicts, making it reliable for critical applications in diverse industries, including automotive, industrial control, and marine systems. Beneath the NMEA 2000 application layer, marine systems predominantly utilize the physical CAN network.

One of the central vulnerabilities exploited in this research revolves around the address claim process inherent to CAN-based networks like NMEA 2000. When a new device or node joins the network, it must acquire a unique source address, typically ranging from 0 to 253. This is achieved by sending an address claim message containing a unique "name" in its data field. Conflicts in address claiming are resolved based on name priority, where the device with the lower numerical value in its name field wins the claim for a specific address. Critically, the CAN protocol, and by extension NMEA 2000, lacks any robust authentication mechanism for these address claims. This fundamental design flaw allows a malicious actor to impersonate or "steal" the address of a legitimate device.

The speakers illustrate this with an address claim attack scenario: a legitimate engine controller claims address zero and begins communicating. A malicious autopilot node then joins the network, claims the same address zero but with a lower name priority value. Consequently, the legitimate engine controller is effectively "thrown off" the network because its claimed address is usurped, and all other network nodes now recognize the malicious autopilot as the engine controller. This type of attack can lead to denial of service or, more dangerously, allow the attacker to inject arbitrary messages as the impersonated device.

Marine system architectures vary significantly in complexity. Smaller pleasure crafts might have relatively simple networks, while larger shipping vessels feature intricate interconnected systems comprising displays, laptops, compasses, autopilots, and engine controllers, all communicating over the NMEA 2000 backbone. The researchers specifically focused on a common setup: a chart plotter connected to an autopilot computer via the NMEA 2000 protocol, powered by a standard supply. This configuration represents a prevalent attack surface, especially given the common practice of updating these systems via SD cards or direct laptop connections. The broader context of cyber-physical system security underscores the urgency of this research, as these systems are increasingly seen as targets for state-sponsored actors and other malicious groups, challenging the long-held belief that they are inherently secure due to physical isolation.

Key Findings

▶ Watch: Why boats? Similarities to CAN/J1939 networks (2:30)

The research uncovered several significant vulnerabilities and demonstrated a powerful attack chain against marine autopilots. Foremost among these findings was the profound insecurity of the firmware update process. The manufacturer provided software updates online, which, when applied, were transmitted over the NMEA 2000/CAN network without any form of cryptographic authentication. The update mechanism relied solely on a basic checksum for integrity verification, leaving it wide open to interception, modification, and re-injection of malicious firmware. This lack of robust authentication is a critical lapse, as it means any actor with network access can potentially compromise the device.

Another pivotal discovery was the presence of an unlocked programming port, specifically a JTAG interface, on the target autopilot's Printed Circuit Board (PCB). This port was not secured or disabled in production units, granting researchers direct, unrestricted physical access. This access allowed them to extract the device's original firmware, modify it, and re-upload it, bypassing any software-level protections that might have been in place. Furthermore, the JTAG port facilitated live debugging and register viewing, invaluable for understanding the device's internal operations and identifying suitable points for exploitation.

Leveraging this physical access, the team performed extensive firmware reverse engineering. They utilized a "very popular tool" (implying industry-standard disassemblers like Ghidra or IDA Pro) to identify the binary architecture, analyze code regions, and make the raw binary code human-readable. A key objective was to locate the CAN send function within the firmware by correlating its operations with specific hardware registers. This meticulous process of renaming functions and mapping code flow was essential for understanding how the autopilot transmits messages over the NMEA 2000 network.

The culmination of these efforts was the achievement of remote code execution (RCE) on the autopilot. By patching the legitimate firmware to include their malicious code—specifically, a hard-coded address claim message—and then re-uploading this modified firmware through the manufacturer's update mechanism, they demonstrated full control over the autopilot's execution. This RCE capability, in turn, enabled arbitrary CAN injection. The researchers emphasized that while their proof-of-concept focused on an address claim attack, the RCE allowed them to send any targeted messages over the CAN network. This could include falsifying GPS commands, manipulating rudder controls, or interfering with other critical marine network components, showcasing the broad potential for malicious control.

As part of their commitment to responsible disclosure, the researchers informed the manufacturer of their findings. Notably, the manufacturer lacked a formal vulnerability reporting system, highlighting a common gap in security maturity within certain industrial sectors. Despite this, Green and Chatterjee successfully submitted their findings to MITRE, resulting in the allocation of a CVE ID. At the time of the talk, the CVE was in a reserved but public state, with more details to be released post-presentation, though the specific company and product name were intentionally withheld to prevent immediate exploitation. This responsible approach underscores the researchers' ethical goal of improving security without causing harm.

Ultimately, the research unequivocally demonstrated a systemic lack of fundamental security practices. The absence of signed firmware, disabled JTAG ports in production, firmware encryption, and a secure boot process during power-up created a permissive environment for these vulnerabilities to thrive. These findings serve as a critical wake-up call for the maritime industry regarding the necessity of adopting robust cybersecurity engineering principles.

Technical Deep Dive

▶ Watch: CAN Network 101: basics and applications (4:00)

The technical execution of the "Dead Reckoning" attack involved a meticulous process of hardware analysis, firmware reverse engineering, and custom firmware patching. The initial phase focused on understanding the autopilot's physical components. The researchers removed the autopilot from its enclosure to access the Printed Circuit Board (PCB). Their goal was to identify critical components by their small part numbers, often requiring microscopes, and then locate corresponding datasheets, user manuals, and wiring diagrams. A crucial early observation was the presence of a standard NMEA 2000 connector, which provided direct access to the CAN high and CAN low lines, as well as power and ground.

Further investigation into the autopilot's hardware revealed key features and interfaces. The device was capable of sending and receiving NMEA 2000 frames, controlling the steering wheel through a feedback mechanism, and directly controlling the angle of the rudder. A significant finding was a prominent 20-pin header on the PCB. This header turned out to be an unlocked programming port, specifically a JTAG interface. This port was instrumental, allowing the team to extract the existing firmware, modify it, and upload custom firmware, in addition to performing live debugging and viewing chip registers. The availability of a software update online from the manufacturer was also noted, providing a critical avenue for re-injecting modified firmware. Understanding the memory map for the device's specific chip architecture was also a vital step in preparing for effective firmware reverse engineering.

For hardware interaction, the researchers initially used a Tyiggard tool, later switching to a JLink for improved consistency when interfacing with the programming port. This direct access to the microcontroller's internal workings was the foundation for their software reverse engineering efforts.

The software reverse engineering process followed a standard methodology adapted for embedded systems:

1. Identifying Binary Architecture: Determining the microcontroller's architecture (e.g., ARM, MIPS) to correctly interpret the raw binary.
2. Disassembly and Analysis: Using popular reverse engineering tools (implied to be Ghidra or IDA Pro) to disassemble the binary, transforming machine code into a more human-readable assembly language.
3. Function Identification and Renaming: This labor-intensive step involved analyzing code flow, identifying common patterns, and correlating them with known functionalities. A primary goal was to pinpoint the specific functions responsible for CAN communication, particularly the CAN send function, by observing which registers were manipulated during message transmission. This involved countless hours of tracing execution paths and renaming functions to reflect their purpose.
4. Locating the Patch Target: Once the CAN send function was identified, the objective was to find a suitable location within the firmware to inject malicious code. The researchers aimed to modify an existing function to instead hard-code and send an address claim message.

Their specific modification involved patching the arguments of the CAN send function. Instead of passing dynamic message and data buffer arguments, they hard-coded these to construct a specific address claim message designed to usurp an existing device's address on the NMEA 2000 network.

The final step involved packaging this modified firmware for distribution. The manufacturer's online update file was an S-record encoded into an XML format. The researchers, using information from sources like Wikipedia, reverse-engineered the S-record format, including its headers and checksums. This allowed them to properly integrate their patched opcodes into the S-record, re-calculate the checksums, and then re-encode the entire malicious firmware back into the XML format. This "malicious upgrades" file was then saved onto an SD card. The attack vector involved inserting this SD card into the chart plotter, navigating its interface to select the malicious firmware file, choosing the autopilot as the target device, and initiating the "upgrade" process.

Crucially, the update was then transmitted over the NMEA 2000 network to the autopilot without any authentication—only a simple checksum. Upon receiving the malicious update, the autopilot rebooted and began executing the injected code, specifically sending out the crafted address claim messages. This demonstrated not only remote code execution but also the ability to perform arbitrary CAN injection, allowing the compromised autopilot to send any desired message onto the network, including falsified GPS data or direct actuator commands, thereby gaining control over physical marine systems.

Demo / Proof of Concept

▶ Watch: Broader motivation: securing cyber-physical systems (6:07)

The "Dead Reckoning" presentation included a live demonstration of the address claim attack, showcasing the practical implications of the discovered vulnerabilities. The demo setup consisted of a typical marine network configuration: a chart plotter, the target autopilot, and an engine controller representing a legitimate device on the NMEA 2000 network. The goal was to demonstrate how the compromised autopilot could hijack the engine controller's network identity.

Initially, the live demo faced technical difficulties with display connectivity for the chart plotter. However, the speakers quickly adapted, directing the audience's attention to their on-stage setup and later successfully utilizing a simulator to illustrate the attack.

In the working demonstration, the researchers first showed the normal operation of the marine network simulator, with legitimate messages flowing. The engine controller was identified as active on the network, specifically noting its source ID of 00. This established the baseline state before the attack.

The core of the proof-of-concept involved the firmware update process. The malicious firmware, previously crafted and saved onto an SD card, was inserted into the chart plotter. Through the chart plotter's interface, the researchers navigated to the "malicious upgrades" file, selected the autopilot as the target device for the update, and initiated the "start upgrade" command.

As the update commenced, the speakers highlighted the critical security flaw: the upgrade was transmitted over the NMEA 2000 network to the autopilot without any authentication process and in plain text. This lack of security meant that not only could a malicious file be uploaded, but a simple capture and replay attack of a legitimate firmware update could also be used to compromise the device, if an attacker could modify the captured update.

Upon receiving and processing the malicious firmware, the autopilot rebooted. Immediately after, the network traffic dramatically changed. The previously active engine controller, identified by source ID 00, was kicked off the network. Its place was taken by a flood of address claim messages originating from the now-compromised autopilot. This visually confirmed that the autopilot had successfully usurped the engine controller's address.

The implications of this successful address claim attack were then explained: with the engine controller removed from the network, it would no longer receive critical messages from other network components. Drawing a parallel to a truck scenario, the speakers described how a brake system might send messages to the engine and transmission to slow down. In a marine context, this could mean the engine failing to receive commands from navigation systems, throttle controls, or safety overrides. The compromised autopilot could then inject its own commands as if it were the engine, leading to potentially dangerous physical control manipulations or denial of service for critical functions.

The demo effectively validated the research findings, demonstrating that remote code execution on the autopilot could lead to arbitrary CAN injection, with significant consequences for marine system integrity and safety. The discussion also touched upon future possibilities, such as entirely wireless attacks if marine IoT devices with Wi-Fi capabilities become more prevalent and are integrated without proper security.

Defensive Implications

▶ Watch: Marine system architecture and experimental setup (7:00)

The findings from "Dead Reckoning: Hijacking Marine Autopilots" present a clear mandate for manufacturers and operators within the maritime industry to re-evaluate and significantly enhance their cybersecurity posture. The vulnerabilities exposed are not isolated flaws but symptomatic of a broader lack of adherence to fundamental secure software development lifecycle (SSDLC) practices in embedded systems.

The most critical defensive implication is the urgent need to implement secure software practices across the board:

1. Signed Firmware: All firmware updates must be cryptographically signed by the manufacturer. Devices should only accept and install updates with valid signatures, preventing the loading of malicious or tampered firmware. This would directly mitigate the attack demonstrated, where unsigned, modified firmware was accepted.
2. Disable JTAG/Programming Ports in Production: Physical debugging and programming interfaces, such as JTAG, are essential during development but pose a severe security risk if left enabled and unprotected in production units. These ports must be physically or logically disabled, or access must be secured with strong authentication mechanisms, to prevent unauthorized extraction or modification of firmware.
3. Encrypt Firmware: Encrypting firmware protects intellectual property and significantly raises the bar for reverse engineering efforts. While not preventing execution of modified code if the device can decrypt it, it makes the initial analysis and modification much more difficult, slowing down attackers.
4. Remove Identifiers from PCB Components in Production: Obfuscating hardware details by removing easily readable part numbers from PCB components in production units makes it harder for attackers to quickly identify datasheets and potential vulnerabilities, thereby increasing the effort required for hardware reverse engineering.
5. Implement Secure Boot: A secure boot process ensures that only trusted and authorized firmware is loaded and executed when the device powers on. This chain of trust, starting from an immutable root of trust, verifies the integrity and authenticity of each stage of the boot process, preventing malicious code from gaining control early in the system startup.

Beyond these foundational software practices, specific network and operational recommendations emerge:

• Authentication for Updates: The lack of authentication for firmware updates over the NMEA 2000 network is a glaring vulnerability. Manufacturers must implement robust authentication protocols, possibly involving mutual authentication between the update source (e.g., chart plotter) and the target device (autopilot), before any firmware transfer occurs.
• Network Segmentation and Monitoring: While not always feasible in simpler marine systems, larger vessels could benefit from network segmentation to isolate critical components. Additionally, continuous monitoring of NMEA 2000 networks for unusual traffic patterns, such as unexpected address claim messages or anomalous commands, could help detect ongoing attacks.
• Vulnerability Reporting Systems: Manufacturers must establish clear, accessible, and responsive vulnerability reporting systems. The researchers' experience of the manufacturer lacking such a system underscores a broader industry immaturity that needs addressing. A formal channel encourages ethical hackers to report findings, allowing for timely patching and mitigation.
• Awareness and Training: Operators and maintenance personnel should be educated on the risks of unauthorized firmware updates and the importance of only using trusted sources and secure procedures for system maintenance.

In summary, defending against these types of attacks requires a multi-layered approach, starting with fundamental security by design principles at the manufacturing level and extending to operational security practices on the vessels themselves. The maritime industry, often relying on legacy systems and a perception of isolation, must rapidly evolve its cybersecurity posture to meet the challenges of an increasingly interconnected world.

Key Takeaways

• Marine autopilots and NMEA 2000 networks are vulnerable to sophisticated cyberattacks, challenging the outdated perception of these systems as inherently "air-gapped" or secure due to physical isolation.
• The absence of crucial security controls, such as firmware authentication and the presence of unprotected programming ports (e.g., JTAG) in production devices, enables attackers to achieve remote code execution and arbitrary CAN message injection.
• Address claim attacks, leveraging the lack of authentication in the NMEA 2000/CAN protocol, can disrupt critical marine systems by forcefully removing legitimate devices (like engine controllers) from the network, leading to potential denial of service or malicious control.
• The research highlights the importance of responsible disclosure, demonstrating how ethical hacking and subsequent reporting to organizations like MITRE can lead to the assignment of CVE IDs for critical vulnerabilities, even when manufacturers lack formal reporting mechanisms.
• Manufacturers of marine electronics must urgently adopt fundamental secure software development lifecycle practices, including cryptographic signing of firmware, disabling debugging ports in production, implementing secure boot processes, and robust authentication for all network-based updates.
• The growing integration of IoT devices, often with Wi-Fi capabilities, into marine systems introduces new attack vectors, suggesting that future exploits may be entirely wireless, negating the need for physical access to the vessel's network.

About the Speaker(s)

Carson Green is a current Master's student in Systems Engineering at Colorado State University. He holds a Bachelor's degree in Electrical Engineering, providing him with a strong foundation in hardware and embedded systems, which was evident in the detailed hardware reverse engineering aspects of this research.

Rik Chatterjee is a current PhD student in Systems Engineering at Colorado State University. His academic background includes a Bachelor's in Computer Science and a Master's in Systems, equipping him with expertise in software analysis and complex system architectures, crucial for the firmware reverse engineering and protocol analysis presented.

Both Carson and Rik conduct their research at the System Cyber Research Lab located at the Powerhouse Energy Campus at Colorado State University, under the guidance of Dr. Jeremy Daly, an associate professor in their department. Their primary research focus areas include critical infrastructure cybersecurity and commercial vehicle cybersecurity. They have a history of presenting at major conferences, including a previous main stage presentation at DEF CON on commercial vehicle cyber security, demonstrating their ongoing commitment to securing cyber-physical systems.