Hijacking Marine Autopilots via Unauthenticated CAN Bus Injection

TLDR: Researchers at DEF CON 2025 demonstrated that marine autopilot systems are vulnerable to address-claiming attacks due to a complete lack of authentication on the NMEA 2000 protocol. By reverse engineering the firmware, they identified that an attacker can inject arbitrary CAN bus messages to hijack steering and engine controls. This research highlights a critical failure in OWASP A07:2021 – Identification and Authentication Failures within industrial and maritime environments.

Marine systems are often treated as air-gapped, isolated environments, but that assumption is rapidly becoming a liability. As modern vessels integrate more IoT sensors, wireless connectivity, and remote management features, the attack surface has expanded far beyond the physical bridge. The recent research presented at DEF CON 2025 on hijacking marine autopilots proves that the underlying communication protocols, specifically NMEA 2000, are fundamentally broken when it comes to trust. If you can get a device onto the CAN bus, you effectively own the vessel's navigation and propulsion systems.

The Mechanics of the Address-Claiming Attack

At the heart of this vulnerability is the NMEA 2000 protocol, which relies on the Controller Area Network (CAN) standard. CAN was designed for reliability in harsh environments, not for security. It is a broadcast-based protocol where every node on the bus sees every message. When a new device joins the network, it must claim a source address between 0 and 253. This process is handled by an address-claim message.

The vulnerability exists because the protocol lacks any form of cryptographic authentication. An attacker can simply wait for a legitimate device to claim an address and then broadcast a new address-claim message with a higher priority, effectively forcing the legitimate device off the network. Once the attacker has successfully claimed the address, they can inject arbitrary messages. In the demonstration, the researchers used a custom setup with a chart plotter and an autopilot computer to show that they could not only claim the address but also send commands to control the steering wheel and the engine controller.

Reverse Engineering the Firmware

The researchers gained access to the autopilot's firmware by identifying a 20-pin header on the PCB, which they accessed using a Tigard multi-protocol tool. After extracting the firmware, they used Ghidra to perform software reverse engineering. The goal was to identify the specific functions responsible for CAN bus communication and the address-claiming process.

By mapping the memory and identifying the code regions responsible for sending CAN frames, they were able to patch the binary. The patch was straightforward: they modified the firmware to hard-code a malicious address-claim message. This modified firmware was then saved to an SD card and uploaded to the autopilot via the device's standard update mechanism. Because the update process itself lacked signature verification, the autopilot accepted the malicious firmware without question. This is a classic example of how insecure firmware updates can lead to full system compromise.

Real-World Implications for Pentesters

For a security researcher or pentester, this finding is a wake-up call. If you are performing a security assessment on a vessel or any industrial system using CAN bus, you cannot assume that the network is secure. The lack of authentication means that any device with physical access to the CAN bus can become a pivot point.

During an engagement, your focus should be on identifying the physical access points to the CAN bus. Once you have access, tools like candump and cansend from the can-utils suite are your primary weapons. You are not looking for complex exploits; you are looking for the ability to inject messages that the system will trust implicitly. The impact of this is severe: an attacker could potentially steer a vessel into a collision or disable its propulsion system, creating a significant safety risk. The research resulted in CVE-2025-50575, which serves as a reminder that these vulnerabilities are being tracked and should be taken seriously.

Defensive Strategies

Defending against this type of attack requires a shift in how we approach industrial security. First and foremost, manufacturers must implement secure boot and firmware signing to prevent the installation of malicious code. Disabling JTAG and other programming ports in production units is a mandatory step to prevent unauthorized firmware extraction and modification.

Furthermore, network segmentation and the use of Hardware Security Modules (HSM) can help ensure that only authorized devices can communicate on the bus. While these measures do not fix the underlying protocol flaws, they significantly raise the bar for an attacker. If you are working with a blue team, advocate for monitoring CAN bus traffic for anomalous address-claim messages or unexpected command patterns. The era of trusting the bus is over; it is time to start treating these systems with the same level of scrutiny as any other networked device.