How to Hijack a Satellite: Exploiting Memory Corruption in LEO Systems

TLDR: Recent research into Low Earth Orbit (LEO) satellite firmware reveals that many systems lack basic security controls like encryption and authentication. By exploiting memory corruption vulnerabilities in the Command and Data Handling (CDHS) subsystem, an attacker can gain arbitrary code execution and hijack satellite control. Pentesters and researchers should focus on auditing custom communication protocols and identifying insecure memory management practices in embedded satellite firmware.

Satellites are no longer the exclusive domain of nation-states with billion-dollar budgets. The rise of LEO constellations and the democratization of space technology mean that small, relatively inexpensive satellites are being launched at an unprecedented rate. While this shift has accelerated innovation, it has also introduced a massive, largely unexamined attack surface. Security researchers are finally beginning to pull back the curtain on these systems, and the findings are exactly what you would expect from a field that has prioritized mission success over security for decades.

The Reality of Satellite Security

Most LEO satellites rely on the CubeSat Space Protocol (CSP), a lightweight network-layer delivery protocol designed for small satellite networks. While CSP is efficient, it is not inherently secure. In many implementations, developers treat the satellite as a "trusted" environment, assuming that because the hardware is in space, it is inaccessible. This is a dangerous fallacy. As demonstrated in recent research, the barrier to entry for interacting with these systems is surprisingly low. With a modest investment in ground station equipment, an attacker can communicate with a satellite, and if the firmware is poorly written, they can compromise it.

The primary attack vector is the Command and Data Handling (CDHS) subsystem. This is the brain of the satellite, responsible for processing incoming telecommands and managing telemetry. When this subsystem is exposed to untrusted input without proper validation, it becomes a playground for memory corruption exploits.

Exploiting Memory Corruption in Space

The research highlights a critical vulnerability pattern: the use of unsafe string handling functions in the CDHS. In one case study, the firmware contained a command that accepted a log file name from a telecommand packet. The code then used this input to perform a string concatenation into a fixed-size stack buffer.

// Simplified example of the vulnerable pattern
void handle_log_command(char *packet_data) {
    char log_file_name[32];
    // Vulnerable: no bounds checking on packet_data
    strcpy(log_file_name, packet_data); 
    // ...
}

Because the system lacks modern exploit mitigations like Address Space Layout Randomization (ASLR) or stack canaries, this is a textbook stack-based buffer overflow. An attacker can overwrite the return address on the stack to redirect execution flow to their own payload. In an emulated environment using QEMU, researchers successfully demonstrated this by hijacking the control flow to bypass authentication checks. Once the authentication logic is bypassed, the attacker can send arbitrary commands to the satellite, effectively seizing control.

Why This Matters for Pentesters

If you are performing a security assessment on an IoT device or an embedded system, you are already looking at the right things. The vulnerabilities found in satellite firmware are identical to those found in terrestrial embedded devices: lack of input validation, insecure use of C standard library functions, and the absence of OWASP A02:2021-Cryptographic Failures.

The real-world risk is not just data theft. It is the potential for physical impact. By hijacking the control flow, an attacker could potentially manipulate the Attitude Determination and Control System (ADCS), which manages the satellite's orientation. While the research focused on emulated environments, the implications for operational satellites are severe. A compromised satellite could be used to disrupt communication services, perform unauthorized surveillance, or, in a worst-case scenario, contribute to the Kessler Syndrome, where a chain reaction of collisions renders orbital paths unusable for generations.

The Defensive Gap

Defending these systems is difficult because of the constraints. Satellite hardware is often radiation-hardened and runs on low-power processors with limited memory. Developers are forced to make trade-offs, often sacrificing security for performance and power efficiency. However, "tight margins" is no longer a valid excuse for shipping code without basic memory safety.

Blue teams must push for the adoption of secure coding standards and the implementation of basic mitigations. Even on resource-constrained systems, developers can use safer alternatives to strcpy and gets, such as strncpy or strlcpy. Furthermore, implementing OWASP A07:2021-Identification and Authentication Failures controls is non-negotiable. If a satellite is reachable, it must be able to verify the identity of the sender. Relying on "security by obscurity"—the hope that an attacker won't know the protocol or the command structure—is not a strategy.

The space industry is at a crossroads. As more companies launch constellations, the pressure to move fast will only increase. If the security community does not hold these organizations accountable for the integrity of their firmware, we are essentially leaving the keys to our orbital infrastructure in an unlocked car. Start looking at the protocols, start fuzzing the command parsers, and start asking why these systems are still being deployed without the most basic protections. The next big exploit might not be on a web server; it might be in low earth orbit.