Compromising Electronic Logger & Creating Truck2Truck Worm

Compromising Electronic Logger & Creating Truck2Truck Worm

Speakers: Jake Jepson, Rik Chatterjee

Conference: DEF CON 32

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

Overview

Jake Jepson and Rik Chatterjee, master’s students from Colorado State University, presented groundbreaking research at DEF CON 32 detailing the first known wireless drive-by attack on a heavy-duty truck. Their talk, "Compromising Electronic Logger & Creating Truck2Truck Worm," unveiled critical vulnerabilities in Electronic Logging Devices (ELDs), essential components of commercial vehicles mandated to record drivers' hours of service. This research highlights a significant security gap in critical infrastructure, demonstrating how a widespread device, designed for compliance, can be weaponized to remotely control a truck's engine.

The core of their work involved reverse engineering a popular ELD, discovering numerous security flaws, and developing a malicious firmware that could be wirelessly flashed onto the device. This firmware enabled the remote manipulation of the truck's engine, specifically demonstrating how to slow it down through the CAN bus. The implications extend beyond individual truck compromise, hinting at the potential for a "truck-to-truck worm" given the prevalence of these vulnerable devices and their connectivity. This presentation serves as a stark warning to manufacturers, fleet operators, and regulators about the urgent need to address cybersecurity in the commercial vehicle sector.

The research not only exposed specific device vulnerabilities but also underscored systemic issues within the ELD industry, such as pervasive code reuse, lack of security-focused mandates, and insufficient protection mechanisms. By successfully executing a drive-by attack that altered vehicle behavior, Jepson and Chatterjee have provided tangible evidence of the severe risks posed by insecure IoT devices integrated into critical transportation systems, urging a reevaluation of current security practices and regulatory frameworks.

Background

▶ Watch: Introducing wireless drive-by truck attack (0:00)

The motivation behind this research stems from the critical role commercial vehicles play in the global supply chain, a fact starkly highlighted during the recent pandemic. Recognizing trucks as integral components of critical infrastructure, the researchers focused on their cybersecurity posture. Modern heavy vehicles are highly electronic, incorporating approximately 150 Electronic Control Units (ECUs) that manage various functions. These ECUs communicate over various network protocols, with SAE J1939 being the predominant standard in U.S. commercial trucks, alongside CAN, CANFD, LIN, and increasingly, automotive Ethernet.

The introduction of the ELD mandate in 2017 by the Federal Motor Carrier Safety Administration (FMCSA) aimed to improve road safety by electronically logging drivers' hours of service, replacing unreliable paper logs. However, a significant oversight in this mandate was the complete absence of security requirements. This regulatory gap allowed manufacturers to self-certify their ELDs, leading to a proliferation of devices—around 880 variants at the time of the talk—with little to no security considerations. ELDs typically plug into a truck's diagnostic port, similar to a car's OBD-II port, and require both read and, critically, write access to the internal vehicle network to function. Furthermore, ELDs are rarely standalone, often connecting to other devices or applications via Wi-Fi, Bluetooth, or cellular networks to offload data, expanding their attack surface.

From an attacker's perspective, the initial landscape appears daunting due to the sheer number of ELD variants. Additionally, newer trucks often incorporate gateways that act as firewalls, segmenting the diagnostic port from sensitive internal ECUs. However, the researchers discovered that these perceived barriers are often less formidable than they appear. A deeper investigation revealed that the 880 variants are largely rebranded clones, with significant code reuse across only about 10 distinct underlying devices. This drastically reduces the number of targets for a widespread attack. Moreover, many older trucks still on the road, which can operate for 20-30 years, predate the widespread adoption of gateways, leaving them exposed. Even for trucks with gateways, the CSU team has previously identified diagnostic protocol flaws that can bypass these firewalls, allowing malicious messages to reach critical vehicle components. This background establishes the fertile ground for the ELD vulnerabilities uncovered in this research.

Key Findings

▶ Watch: Importance of commercial vehicles and ELD mandate (2:15)

The research yielded several critical findings that collectively demonstrate the severe insecurity of widely deployed ELDs. The initial breakthrough came from the discovery that numerous major ELD brands, over 50 in total, were selling rebranded versions of a single device: the IOSIX IO 1020 micro ELD. This pervasive code reuse meant that a vulnerability in one device could affect a vast portion of the market.

Upon physically examining the device, which is based on the ESP32 microcontroller, the researchers identified a prog port on the PCB. Hardware reverse engineering confirmed that the device's eFuses had no protections enabled, allowing for a complete firmware dump. This was the first critical step, as it provided the raw binary for software analysis.

Running strings on the dumped firmware immediately revealed significant vulnerabilities:

• A hardcoded default Wi-Fi SSID and password were present, allowing anyone within range to connect to the device's internal network.
• References to web servers and upload.php endpoints, indicating an Over-The-Air (OTA) update mechanism.
• Further scrolling uncovered a hardcoded key protecting these OTA updates, which was trivial to guess based on its structure (starting with '1' and ending with '6').

With network access, an Nmap scan on the device revealed three active services:

• A Telnet service on port 23.
• A service on port 22, initially misidentified by Nmap as SSH, but later determined to be a debug service.
• An HTTP server on port 80, which displayed device serial, version information, the OTA key, and, notably, a placeholder for "firmware-mal," hinting at the possibility of malicious firmware uploads.

The most challenging aspect was reverse engineering the Extensa architecture of the ESP32 with Ghidra, which at the time had limited community support for this specific architecture. Despite these difficulties, a crucial "snooping" technique—finding a crash dump posted by "IOSIX LLC" on the Expressif forums—provided invaluable information, including thread names and function call stacks, which helped identify the main function and understand the overall program flow.

These efforts culminated in the identification of several core vulnerabilities:

• Default network credentials: The hardcoded Wi-Fi password provided easy access.
• Always-on web server: An apparently unused web server remained active, exposing device information and potential upload points.
• Simultaneous Bluetooth and Wi-Fi activity: Multiple wireless interfaces were active, increasing the attack surface.
• Unsigned firmware: The device did not validate the cryptographic signature of uploaded firmware, allowing any modified binary to be installed.
• Weak OTA password: The hardcoded, easily discoverable key for OTA updates rendered the update mechanism insecure.
• Debug service (port 22): This service, acting as an echo server, was found to be an ideal location to inject malicious code without disrupting the original firmware's functionality.
• Secret Telnet command: A hidden function accessible via Telnet (port 23) allowed for arbitrary, wireless injection of CAN messages onto the vehicle's bus. This was a critical discovery, as it provided a direct route to vehicle control.

Technical Deep Dive

▶ Watch: Attacker's perspective and initial challenges with ELDs (5:00)

The technical deep dive into the IOSIX IO 1020 micro ELD began with its core hardware: an ESP32 microcontroller. This popular System-on-Chip (SoC) integrates Wi-Fi and Bluetooth capabilities, making it suitable for connected devices like ELDs. The first critical step was to gain access to the device's firmware. The researchers identified a prog port on the PCB, which is commonly used for flashing and debugging ESP32 devices. By checking the eFuses, which are one-time programmable memory bits used to configure security features, they confirmed that no protections (such as secure boot or flash encryption) were enabled. This allowed them to easily dump the entire firmware image from the device.

Once the firmware binary was acquired, the initial analysis involved running the strings utility. This simple but effective technique yielded immediate and significant results. The output included the hardcoded Wi-Fi SSID and, shockingly, its corresponding default password. Further inspection revealed strings related to web server functionalities, including upload.php and references to OTA (Over-The-Air) updates. Crucially, the strings output also contained a specific hardcoded OTA key (starting with '1' and ending with '6'), which was intended to protect firmware updates but was easily discoverable.

With the Wi-Fi credentials in hand, the researchers connected to the device's network and performed an Nmap scan. This revealed three open ports:

• Port 23 (Telnet): This service offered a comprehensive API, allowing control over normal ELD functions and even modification of device defaults.
• Port 22 (SSH): Initially thought to be SSH, further analysis revealed it was actually a simple debug service acting as an echo server. This seemingly innocuous service later proved to be an ideal vector for injecting malicious code.
• Port 80 (HTTP): This web server displayed basic device information (serial, version) and the discovered OTA key. Its presence, along with the upload.php endpoint, confirmed the OTA update mechanism.

The next phase involved extensive reverse engineering of the firmware using Ghidra. This proved challenging due to the ESP32's Extensa architecture, which at the time lacked robust support in major reverse engineering tools. Jake Jepson spent weeks improving Ghidra's decompilation for Extensa, grappling with disjointed functions and missing the crucial main function that orchestrates the entire program. A breakthrough came from an unconventional source: "snooping" on the Expressif forums. An account associated with "IOSIX LLC" had posted a full crash dump, which contained invaluable information, including names for various threads running on the device. By cross-referencing these thread names with strings found in the firmware, Jepson was able to locate the main function and understand the overall control flow of the ELD's software.

This detailed reverse engineering process uncovered the full extent of the vulnerabilities. The lack of firmware signing was critical, meaning any modified binary could be uploaded and executed. The hardcoded Wi-Fi credentials and OTA key provided easy access and control over the update process. The debug service on port 22 was identified as a stable, always-called function running in its own thread, making it a perfect target for injecting malicious code.

The malicious firmware was designed to exploit this debug service. It incorporated a simple logic: once a status variable confirmed that the CAN bus was initialized and connected, the firmware would begin spamming TSC1 (Torque Speed Control 1) messages. TSC1 messages are a standard part of the SAE J1939 protocol, specifically designed to control engine torque. By continuously sending these messages with specific parameters, the malicious firmware could command the engine to reduce its torque, effectively slowing down the truck. While demonstrated to slow the vehicle for safety reasons, the same mechanism could be used to accelerate it.

Further analysis of the Telnet service (port 23) revealed an even more insidious vulnerability. Within the main command handler function, among standard string comparisons for various commands, a sequence of five consecutive if statements led to a hidden send CAN function. This "secret function" allowed an attacker, once connected via Telnet, to arbitrarily inject any CAN message wirelessly onto the vehicle's internal network. This capability is extremely dangerous, as it grants direct, unauthenticated control over virtually any ECU function accessible via the CAN bus, from engine parameters to brakes and steering (if those messages are on the bus).

Demo / Proof of Concept

▶ Watch: Discovering ELD clones and lack of gateways (6:00)

The culmination of the research was a live demonstration of the wireless drive-by attack, an unprecedented feat in heavy vehicle cybersecurity. The setup involved a truck equipped with the vulnerable IOSIX IO 1020 micro ELD and a "smooth Tesla" driven by the attackers. The objective was to wirelessly reflash the ELD with the malicious firmware while the Tesla drove alongside the truck.

The demonstration proceeded as follows:

1. As the Tesla pulled alongside the truck, the attackers initiated the wireless flashing process, leveraging the exposed Wi-Fi network and the hardcoded OTA key to upload their custom firmware.
2. After approximately 30 seconds, the ELD, now running the malicious code, rebooted.
3. Upon reboot, the malicious firmware began executing its payload: continuously spamming TSC1 (Torque Speed Control 1) messages onto the truck's J1939 CAN bus. These messages commanded the engine to reduce its torque.
4. Visually, the effect was immediate and clear: the truck, despite the driver's input, began to slow down, while the Tesla pulled ahead.

The researchers emphasized that for safety reasons, they chose to demonstrate the ability to slow down the truck. However, the same mechanism, by manipulating the parameters of the TSC1 messages, could just as easily be used to speed up the truck, creating an even more hazardous scenario. The success of this wireless attack underscored its versatility; while the drive-by scenario was used, the researchers also mentioned the potential for using drones to deploy such an attack, highlighting the broad range of creative attack vectors enabled by the wireless nature of the vulnerability. The time taken for the attack (around 30 seconds when close) was also noted to vary with distance, indicating that a more persistent presence or closer proximity could facilitate a quicker compromise. This proof of concept unequivocally validated the feasibility and danger of remotely exploiting ELDs to gain control over critical vehicle functions.

Defensive Implications

▶ Watch: Acquiring vulnerable ELDs for reverse engineering (8:45)

The findings presented by Jake Jepson and Rik Chatterjee carry profound defensive implications for various stakeholders within the commercial vehicle ecosystem.

For ELD Manufacturers:

• Implement Secure Boot and Firmware Signing: The most critical defensive measure is to ensure that ELDs only execute cryptographically signed firmware. This would prevent unauthorized or malicious firmware from being loaded, even if an attacker gains wireless access.
• Eliminate Hardcoded Credentials: Default Wi-Fi SSIDs, passwords, and OTA keys must be unique for each device or securely provisioned during initial setup. Users should be prompted to change these defaults.
• Disable Unused Services: The debug service on port 22 and the always-on web server should be disabled or removed in production firmware. Any necessary diagnostic interfaces should be authenticated, encrypted, and accessible only through secure channels.
• Secure OTA Updates: Firmware updates must be cryptographically signed, encrypted, and validated before installation. The update mechanism itself should be protected by strong, unique credentials.
• Implement Principle of Least Privilege: ELDs should only be granted the minimum necessary read/write access to the CAN bus. If certain J1939 messages are not required for ELD functionality, write access to those messages should be restricted.
• Security by Design: ELD development should incorporate security considerations from the ground up, not as an afterthought. Regular security audits and penetration testing are crucial.

For Fleet Operators and Truck Owners:

• Source Secure ELDs: Prioritize ELDs from manufacturers with a demonstrated commitment to cybersecurity. Inquire about their security features, such as firmware signing and secure updates.
• Regular Updates: Ensure ELDs are kept up-to-date with the latest firmware patches provided by manufacturers.
• Network Segmentation/Gateways: While not foolproof, utilizing trucks equipped with modern gateways can provide an additional layer of defense by segmenting the diagnostic port from critical ECUs. However, operators should be aware that even gateways can have bypass vulnerabilities.
• Physical Security: While this attack was wireless, physical access to the diagnostic port should still be controlled where feasible to prevent direct manipulation or installation of rogue devices.
• Employee Training: Educate drivers and maintenance staff about potential cybersecurity threats and best practices.

For Regulators and Policymakers (e.g., FMCSA):

• Mandate Security Requirements: The current ELD mandate needs urgent revision to include explicit and robust cybersecurity requirements for device certification. This should cover secure boot, firmware signing, secure communication protocols, and vulnerability disclosure policies.
• Independent Certification: Move away from self-certification models towards independent, third-party security assessments and certifications for ELDs.
• Vulnerability Disclosure Programs: Encourage and facilitate responsible disclosure of vulnerabilities by researchers to manufacturers.

The widespread nature of the "rebranded clone" issue means that a single vulnerability can affect hundreds of thousands of vehicles. Addressing these systemic issues through a combination of stricter manufacturing standards, informed purchasing decisions, and updated regulatory frameworks is paramount to safeguarding the integrity of the commercial transportation sector.

Key Takeaways

• The current ELD mandate in the U.S. critically overlooked cybersecurity, leading to a proliferation of devices with fundamental security flaws.
• Code reuse and rebranding across over 50 different ELD brands amplify the impact of single vulnerabilities, turning one insecure device into a widespread threat to critical infrastructure.
• Wireless drive-by attacks on heavy vehicles are not theoretical; they are demonstrably feasible, allowing remote compromise and manipulation of essential vehicle functions like engine torque.
• Hardcoded default credentials, unsigned firmware, and exposed debug interfaces are pervasive and severe vulnerabilities that provide easy avenues for attackers to gain control and inject malicious code.
• The discovery of a secret Telnet command enabling arbitrary CAN message injection offers a direct, unauthenticated pathway to manipulate any function on the vehicle's internal network, from slowing down to potentially speeding up the truck.
• Responsible disclosure by researchers is crucial for identifying and patching these vulnerabilities, but systemic issues in manufacturing practices and regulatory oversight demand broader, industry-wide changes to ensure adequate security for commercial vehicles.

About the Speaker(s)

Jake Jepson and Rik Chatterjee are Systems Engineering Master students at Colorado State University (CSU). They conduct their research under the guidance of Dr. Jeremy Daily, focusing specifically on the cybersecurity of heavy vehicles. Their work extends to the security of devices attached to these vehicles, such as Electronic Logging Devices (ELDs). Their presentation at DEF CON 32 showcased their expertise in reverse engineering and offensive security techniques applied to critical transportation infrastructure.