Vulns to end your space mission - A. Olchawa, M. Starcik, R. Fradique & A.Boulaich

Vulns to end your space mission - A. Olchawa, M. Starcik, R. Fradique & A.Boulaich

Speakers: Mileno (Team Lead, Vision Space), Andre (Vision Space), Ricardo

Conference: DEF CON

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

Overview

This talk by the Vision Space team, led by Mileno and featuring Andre and Ricardo, delves into critical security vulnerabilities discovered in widely used software components of space systems. Titled "Vulns to end your space mission," the presentation highlights the alarming gap in security scrutiny within the space industry, particularly concerning the ground and space segments of missions. As the number of launched satellites explodes due to commercial ventures like SpaceX and OneWeb, alongside increasing defense sector involvement, the attack surface for space systems is expanding at an unprecedented rate, creating significant incentives for advanced persistent threats (APTs) and nation-states to target these critical infrastructures.

The core message of the talk is that while disabling a satellite traditionally involved kinetic attacks, a much easier and more insidious path exists through exploiting software vulnerabilities in the ground infrastructure and the spacecraft itself. The speakers demonstrate how common software flaws, such as Cross-Site Scripting (XSS) and memory management vulnerabilities, can lead to remote code execution (RCE) on mission control systems and even directly on orbiting spacecraft. This research underscores a crucial oversight: decades-old, operationally critical software, often built without modern security considerations, is now exposed to a threat landscape it was never designed to withstand.

The talk serves as a stark warning to the space industry, emphasizing that the traditional "perimeter-based defense" approach is no longer adequate, especially with the shift to remote operations and cloud-based services for mission control. By showcasing practical exploits against open-source and NASA-developed flight software, Vision Space not only exposes the current state of vulnerability but also advocates for a fundamental shift towards proactive security integration from the design phase. The implications extend far beyond the space industry, as many satellite constellations possess dual-use potential, making their compromise a matter of national and international security.

Background

▶ Watch: Introduction to space systems vulnerability research (0:00)

To understand the context of these vulnerabilities, it's essential to grasp the architecture of a typical space system, which is broadly divided into three segments: the space segment, the ground segment, and the user segment. The space segment comprises the satellite(s) themselves, performing their designated functions in orbit. The ground segment encompasses all terrestrial infrastructure supporting the mission, including mission control centers with human operators, fiber optic networks, ground stations for communication, and science data centers for post-processing telemetry. The user segment consists of the end-user equipment, such as Starlink dishes or other terminals, which interact with the space system.

Historically, much of the public security research in space systems has focused on the user segment – dissecting user equipment, intercepting communications, or tampering with modems. However, the Vision Space team identified a significant research gap in the ground and space segments. These segments, which are responsible for the actual control, health monitoring, and data processing of spacecraft, have received comparatively less attention from the cybersecurity community. This oversight is particularly concerning given the critical nature of their functions and the potential for catastrophic consequences if compromised.

The operational landscape for space missions has also undergone significant changes. Post-COVID, the traditional "perimeter-based defense" model, where operators were physically co-located in secure mission control centers, has eroded. Operators now frequently connect remotely via VPNs, and mission infrastructure is increasingly migrating to cloud platforms like AWS and Azure, where ground station passes can be booked directly. While these shifts offer flexibility and efficiency, they introduce new attack vectors and expand the overall attack surface. Despite these modern operational paradigms, the underlying software used to control spacecraft often remains rooted in decades of legacy code. This software, which forms the human-machine interface for operators and the onboard intelligence for spacecraft, was primarily developed for functionality and reliability in an era where cybersecurity was not a primary design consideration.

The research specifically targeted several widely used open-source and NASA-developed software systems that are reused across dozens of missions. These include:

• Yamc: An open-source mission control system used by numerous smaller missions and planned for future applications like lunar rovers and the European robotic arm on the ISS.
• NASA's Open MCT: A mission control and data visualization tool used for missions such as the Mars rovers.
• OpenC3 Cosmos: Another gaining popularity open-source mission control system.
• NASA's Core Flight System (CFS): A highly critical and widely adopted onboard flight software framework with over 20 years of legacy, used in dozens of missions, including payloads on the James Webb Space Telescope.
• F-prime: Developed by NASA, originally for the Mars helicopter Ingenuity.
• AIT Core: Software used for running experiments on the ISS.

The premise of the talk is simple: instead of the costly and difficult "80s approach" of launching rockets to disable satellites, exploiting these foundational software vulnerabilities offers a "much easier time" for adversaries to achieve their objectives, potentially leading to mission disruption, data exfiltration, or complete spacecraft loss.

Key Findings

▶ Watch: Overview of space system architecture and research gap (2:00)

The Vision Space team's research uncovered a sobering reality: critical vulnerabilities are pervasive across widely adopted space system software, particularly within the ground and space segments. Their findings demonstrate that systems designed for decades of operational reliability, often without a strong security focus, are now susceptible to exploits that could compromise entire missions.

One of the most concerning overarching findings was that in "most of the systems" they investigated, they discovered "a higher critical vulnerability which could lead like to code execution or for example arbitrary file deletion." This indicates that the problem is not isolated to minor flaws but extends to fundamental weaknesses that allow for severe impact. For instance, in Yamc, they found a vulnerability allowing for arbitrary file deletion, which could effectively "wipe the disk" of a mission control system.

The team initiated their vulnerability disclosures in 2023, and the list of identified issues has been continuously growing. While acknowledging that the software itself is not inherently "bad" and maintainers have been responsive in patching reported issues, the core problem lies in the apparent lack of a security-first mindset during the development and maintenance lifecycle. As Mileno stated, "no one was actually telling them to write secure software it seems."

Beyond their initial discoveries, the researchers noted that their public disclosures spurred further investigation by the wider security community, leading to the identification of even more vulnerabilities. A subsequent research effort by a French researcher, for example, found "ways to bypass" encryption and authentication mechanisms in a plugin for NASA's Core Flight System (CFS), which was designed to provide these security features. This bypass was more severe than the team's initial findings in that area. Furthermore, other researchers, utilizing tools like Valgrind for memory checks, uncovered "much more things which were also pretty severe" in the CFS software, highlighting the depth of undiscovered issues.

These findings collectively point to a significant lack of security awareness within the space industry, affecting both developers and management. The team emphasizes that crucial security considerations, such as controlled memory access, need to be discussed and implemented "at the very beginning" of a mission's design. Retrofitting security into existing, decades-old missions with inherent access levels is "very hard to secure." This creates a dilemma, especially for missions with "dual use characteristics," where hard decisions might be necessary regarding their deployment and operational security posture. The research unequivocally demonstrates that the perceived difficulty of "space security" is often self-imposed, and "space security doesn't need to be hard" if addressed proactively.

Technical Deep Dive

▶ Watch: Identifying vulnerable open-source mission control and onboard software (4:30)

The Vision Space team provided concrete technical demonstrations of how vulnerabilities in both the ground and space segments could be exploited, showcasing the severity of their findings.

OpenC3 Mission Control System: XSS to Remote Code Execution (RCE)

The first demonstration targeted OpenC3 Cosmos, an established open-source mission control system. The system was found to be vulnerable to a Cross-Site Scripting (XSS) flaw. While XSS might seem like a common web vulnerability, its impact in a mission-critical system like OpenC3 can be devastating.

The exploitation chain involved:

1. Crafting a malicious URL: An attacker generates a specially crafted URL containing an XSS payload.
2. Phishing the operator: This URL is then used in a phishing campaign to trick a spacecraft controller into clicking it.
3. Session token theft: Upon clicking the link, the XSS payload executes within the victim's browser context. The payload's primary objective is to steal the operator's session tokens. These tokens grant authenticated access to the OpenC3 system.
4. Malicious script deployment: Using the stolen session tokens, the attacker can then authenticate to the OpenC3 system and deploy a malicious script. OpenC3 supports custom functionality through scripting languages like Ruby and Python. The attacker's script could leverage these capabilities to execute arbitrary commands on the underlying system hosting the mission control software.
5. Triggering RCE: Once the malicious script is deployed, it can be triggered, leading to Remote Code Execution (RCE) on the system that is "de facto controlling the spacecraft."

From the victim's perspective, clicking the link might appear to do nothing, as they retain access to their mission control system. However, the adversary gains full control over the system, enabling them to manipulate telemetry, send unauthorized commands, or disrupt operations. This demonstrates how a seemingly common web vulnerability, when present in critical infrastructure, can lead to complete compromise.

NASA Core Flight System (CFS): Memory Management RCE on Spacecraft

The second, and arguably more impactful, demonstration targeted the spacecraft itself, specifically an older version of NASA's Core Flight System (CFS). This vulnerability resided within the memory management module of CFS. The core weakness was that this module, intended to manage memory operations, did not impose any restrictions on which parts of the memory address space could be written to or read from. This meant an attacker could read or write to the entire process memory of CFS, not just the memory allocated to the memory management module. Since CFS often runs on Linux-type operating systems (as simulated in the demo), this level of arbitrary memory access opens up a vast array of exploitation possibilities.

The exploitation steps for achieving RCE on the spacecraft platform were complex and highly technical:

1. Assumptions: The attack assumes the adversary has access to a ground segment in their country, can send data to the spacecraft (i.e., is within its visibility), and the spacecraft is running a vulnerable, older version of CFS.
2. Targeting the Global Offset Table (GOT): The attackers focused on manipulating the Global Offset Table (GOT). The GOT is a mechanism in dynamically linked executables that holds addresses of external functions. When a function is called, the program looks up its address in the GOT.
3. Leaking function addresses: The exploit first needed to leak the memory address of a known function within CFS that would be called during normal operation. In this case, the MECHR function (likely related to command handling) was identified as one of the next functions called after a telecommand is received. Telemetry downlinked from the spacecraft was used to leak this address.
4. Identifying system() address: Concurrently, the exploit needed to find the memory address of the system() function, a standard C library function that executes shell commands. This is a common primitive for achieving RCE on Linux systems.
5. Overwriting GOT entry: The critical step involved using the memory management vulnerability to write the address of the system() function into the GOT entry originally reserved for the MECHR function.
6. Triggering RCE via telecommand: Once the GOT entry was overwritten, the next time the spacecraft attempted to call MECHR, it would instead execute system(). The attacker then sent a specific telecommand to the spacecraft. This telecommand was crafted to serve as the argument (payload) for the now-hijacked system() function.
7. Reverse Shell: For demonstration purposes, the payload executed a command to establish a reverse shell back to the attacker's listener on the ground. This confirmed full remote code execution on the simulated spacecraft platform.

This exploit showcases a profound level of control, allowing an attacker to execute arbitrary commands directly on the flight software of a spacecraft. The ability to manipulate critical memory structures like the GOT, combined with unconstrained memory read/write capabilities, represents a severe security flaw that could lead to complete mission failure or unauthorized control.

The team also mentioned finding other critical vulnerabilities, such as arbitrary file deletion in Yamc and the subsequent discovery by other researchers of bypasses for encryption and authentication plugins in CFS, further underscoring the widespread nature of these deep-seated security issues.

Demo / Proof of Concept

▶ Watch: Transition to live demonstrations of vulnerabilities (6:30)

The talk featured two compelling live demonstrations that vividly illustrated the severity and exploitability of the discovered vulnerabilities. The speakers emphasized that the "demo gods were good to us today," highlighting the complexity of live exploitation.

The first demonstration showcased an attack against the OpenC3 Cosmos mission control system. The scenario began with the OpenC3 system running, displaying typical functionalities like telemetry processing, commanding capabilities, and a script runner supporting Ruby and Python. The attack vector was an XSS vulnerability. The presenter explained that an attacker would generate a malicious URL designed to fish a user. Once a spacecraft controller (the victim) clicks this link, the XSS payload executes. While "nothing really happens" from the victim's perspective – they still see their mission control system functioning normally – the malicious script has stealthily stolen their session tokens. These tokens are then used by the adversary to deploy a malicious script onto the OpenC3 system. The culmination of this attack is the adversary gaining Remote Code Execution (RCE) on the system that directly controls the spacecraft, effectively taking over the mission control infrastructure.

The second, and arguably more technically sophisticated, demonstration targeted the spacecraft itself, specifically a simulation running an older, vulnerable version of NASA's Core Flight System (CFS). This demo assumed the attacker had access to a ground segment and was within the spacecraft's visibility to send data. The vulnerability exploited was in the CFS memory management module, which allowed arbitrary memory reads and writes across the entire CFS process memory. The exploitation process involved:

1. Starting CFS simulation and listener: The presenter initiated the CFS simulation and an attacker-controlled listener on the ground.
2. Global Offset Table (GOT) manipulation: The core of the exploit was to manipulate the GOT. The attackers knew that the MECHR function was typically called after receiving a telecommand.
3. Memory leakage: Through constant communication between the ground segment and the spacecraft (telemetry), the exploit leaked the memory address of the MECHR function from the spacecraft's GOT.
4. Function pointer swap: The leaked MECHR address was then overwritten in the GOT with the address of the system() function (a standard C library function for executing shell commands).
5. Payload delivery and RCE: A specially crafted telecommand was sent to the spacecraft. When the spacecraft attempted to execute MECHR, it instead executed system() with the telecommand's data as its argument. This effectively passed a malicious command to the system() function.
6. Reverse shell: The demonstration concluded with the successful establishment of a reverse shell from the simulated spacecraft back to the attacker's listener, confirming full RCE on the spacecraft platform.

Both demonstrations were highly effective in illustrating that theoretical vulnerabilities translate directly into practical, high-impact attacks against critical space infrastructure. They underscored the ease with which sophisticated adversaries could achieve objectives traditionally associated with kinetic attacks, simply by exploiting software flaws.

Defensive Implications

▶ Watch: First demo: OpenC3 mission control XSS leading to RCE (6:50)

The findings presented by the Vision Space team carry profound defensive implications for the space industry, necessitating a fundamental shift in how space systems are designed, developed, and operated. The core message is that "space security doesn't need to be hard," but it requires proactive, integrated measures rather than reactive patching.

1. Elevate Security Awareness: There is a critical "lack of awareness" within the space industry, affecting both developers and management. Security must become a first-order concern, not an afterthought. This requires ongoing training for developers on secure coding practices, threat modeling, and vulnerability assessment. Management needs to understand the evolving threat landscape and allocate sufficient resources for security from the outset of a mission.

1. Shift to Security-by-Design: The most significant takeaway is the necessity of integrating security from the very beginning of the system development lifecycle. Functions like unrestricted memory access, which are deeply embedded in legacy software like CFS, are "very hard to secure" once a mission is operational. Design choices that grant such powerful capabilities must be rigorously scrutinized for their security implications. New missions and system upgrades should adopt a "security-by-design" approach, where threat models inform architectural decisions and security controls are built into the core functionality, rather than being bolted on later.

1. Audit and Modernize Legacy Software: The prevalence of critical vulnerabilities in decades-old, operationally critical software like CFS and Yamc necessitates a comprehensive security audit of all such legacy systems. While maintainers have been responsive to reported vulnerabilities, the sheer volume of issues (including those found by subsequent researchers using tools like Valgrind) suggests a deeper, systemic problem. Where possible, legacy components should be modernized or replaced with more secure alternatives. If modernization isn't feasible, robust compensating controls, such as network segmentation, strict access controls, and continuous monitoring, become even more critical.

1. Secure the Expanding Attack Surface: The shift to remote operations (VPNs) and cloud-based ground station services (AWS, Azure) significantly expands the attack surface. Defenders must implement stringent security measures for remote access, including multi-factor authentication, endpoint security, and network access controls. Cloud deployments require adherence to best practices for cloud security, including proper configuration of services, identity and access management, and continuous monitoring for misconfigurations or compromises.

1. Recognize and Address Dual-Use Risks: Many satellite constellations have "dual use potential," meaning they can serve both civilian and military purposes. This characteristic makes them highly attractive targets for nation-state adversaries. For such missions, "hard decisions should be taken on how to use that mission" if its inherent security posture is inadequate. This might involve re-evaluating operational procedures, restricting certain functionalities, or investing heavily in enhanced security measures that match the criticality of its potential military applications.

1. Proactive Vulnerability Research and Disclosure: The success of Vision Space's research highlights the value of proactive, independent vulnerability research in the space sector. The industry should foster an environment that encourages ethical hacking and responsible disclosure, learning from the broader cybersecurity community's experiences. Participating in initiatives like the Aerospace Village CTF mentioned by the speakers can help build skills and awareness within the community.

In essence, defenders in the space industry must move beyond the assumption of isolation and "security through obscurity." They must embrace modern cybersecurity principles, acknowledge the sophistication of potential adversaries, and proactively build resilient systems that can withstand targeted attacks, ensuring the integrity and continuity of vital space missions.

Key Takeaways

• The attack surface for space systems is rapidly expanding due to commercial proliferation and increased defense sector involvement, making them prime targets for sophisticated adversaries.
• Contrary to traditional kinetic attacks, exploiting software vulnerabilities in the ground and space segments offers a much easier path to compromise satellites and missions.
• Widely used, often open-source or NASA-developed, mission control and onboard flight software (e.g., OpenC3, NASA's Core Flight System, Yamc) contain critical vulnerabilities, including XSS, arbitrary file deletion, and memory management flaws leading to Remote Code Execution (RCE).
• These vulnerabilities allow attackers to gain full control over mission control systems (via XSS and phishing) or directly execute arbitrary code on orbiting spacecraft (via memory corruption and GOT manipulation), potentially leading to mission disruption or failure.
• A significant lack of security awareness pervades the space industry, from developers to management, leading to systems being built and maintained without adequate cybersecurity considerations.
• Security must be integrated from the very beginning of a mission's design ("security-by-design"), as retrofitting security into decades-old legacy software with fundamental access issues is exceedingly difficult and costly.

About the Speaker(s)

The talk was delivered by a team from Vision Space, a company focused on space security.

Mileno (likely Mileno Olchawa, given the talk title's first initial "A. Olchawa") is the Team Lead at Vision Space. He introduced the talk and provided the overarching context for their research, emphasizing the growing attack surface and the motivation behind their work.

Andre (likely Andre Boulaich, given the talk title's last initial "A. Boulaich") is also with Vision Space, having worked for the company for "a couple of years now." Prior to joining Vision Space, Andre spent "a little bit over a decade" at the European Space Operations Center, bringing significant operational experience from the space industry to the team's security research. Andre led the technical demonstrations, showcasing the live exploits.

Ricardo (likely Ricardo Fradique, given the talk title's third initial "R. Fradique") was present in the room, acknowledged by Mileno. While not actively speaking on stage, he is part of the Vision Space research team.

The team also mentioned Iman (likely Iman Starcik, given the talk title's second initial "M. Starcik"), who was unfortunately unable to stay for the presentation.