Offensive Security Testing Safeguarding the Final Frontier

Offensive Security Testing: Safeguarding the Final Frontier

Speakers: Andrzej Olchawa

Conference: DEF CON 32

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

Overview

Andrzej Olchawa's DEF CON 32 talk, "Offensive Security Testing: Safeguarding the Final Frontier," delivers a stark warning about the security posture of critical space infrastructure, specifically focusing on the ground segment. The presentation systematically breaks down the architecture of space mission control systems, highlighting their inherent vulnerabilities and the expanded attack surface introduced by recent operational shifts. Olchawa argues that while the space community has begun to acknowledge security through policies and requirements, a crucial element is still missing: proactive, offensive security testing.

The talk unveils a series of significant vulnerabilities discovered in widely used open-source mission control software developed by entities like NASA. These findings, ranging from common web application flaws like Cross-Site Scripting (XSS) and SQL Injection to more severe issues like Local Code Execution and Arbitrary File Deletion, underscore a critical gap in the development and deployment lifecycle of these systems. Olchawa not only details these vulnerabilities but also demonstrates how chaining seemingly minor flaws can lead to catastrophic outcomes, such as the complete compromise of sensitive mission data.

This presentation is highly relevant for anyone involved in critical infrastructure security, software development for high-stakes environments, and, particularly, for the burgeoning space industry. As space operations become more distributed and reliant on internet-connected systems, understanding and mitigating these vulnerabilities is paramount to preventing potential espionage, sabotage, or disruption of vital space missions. The talk serves as a compelling call to action for the space community to adopt a more mature and proactive security testing methodology before adversaries exploit these readily discoverable weaknesses.

Background

▶ Watch: Introduction: Mission Control Systems and New Attack Surface (0:00)

The space mission ground segment is a complex ecosystem of interconnected components essential for controlling and communicating with spacecraft. This segment includes ground stations, data processing facilities, and, crucially, the Mission Control System (MCS). While many ground segment components operate autonomously, the MCS serves as the primary interface between human operators (spacecraft controllers) and the spacecraft itself. This human-system interaction makes the MCS arguably the most vulnerable link in the entire space mission chain, as human factors often represent the weakest point in any information system.

Historically, space missions were operated from highly secure, dedicated mission control rooms with restricted access. This model provided a significant physical security barrier. However, recent global events, most notably the COVID-19 pandemic, have forced space organizations to adapt, opening up their operations to allow remote access for spacecraft operators. While this shift enabled operational continuity, it inadvertently introduced a vast new attack surface. Many MCS applications, developed over decades, are often built on outdated software stacks, making them susceptible to common, well-understood vulnerabilities prevalent in other enterprise applications.

The space community has indeed recognized the growing importance of cybersecurity. Efforts include expanding security strategies, imposing stringent security policies, and introducing specific security requirements into system development. Yet, Olchawa contends that these reactive and policy-driven measures are insufficient. The fundamental missing piece, he argues, is offensive security testing – the proactive simulation of attacks to identify and remediate vulnerabilities before malicious actors exploit them. Given that many organizations develop their own proprietary or open-source MCS, often due to the unique challenges of space operations, these systems frequently lack the rigorous security scrutiny applied to more mainstream software. This context set the stage for Olchawa's team to investigate several prominent open-source MCS platforms, revealing the alarming state of their security.

Key Findings

▶ Watch: Disclosed Vulnerabilities in NASA Open MCT, YMCS, AIT Core (3:00)

Andrzej Olchawa's research uncovered a significant array of vulnerabilities across multiple open-source mission control systems, challenging the perception of inherent security in space-related software. All identified vulnerabilities were responsibly disclosed to the respective vendors, have been addressed, and assigned CVE numbers, underscoring their validity and impact.

The findings were categorized by the specific MCS examined:

• NASA Open MCT: This web-based mission control framework was found to be vulnerable to:
• Prototype Pollution: A JavaScript vulnerability that allows an attacker to add or modify arbitrary properties of objects, potentially leading to Cross-Site Scripting (XSS) or even Remote Code Execution (RCE) in certain contexts.
• Cross-Site Scripting (XSS): A pervasive web vulnerability allowing attackers to inject malicious client-side scripts into web pages viewed by other users.
• Cross-Site Request Forgery (CSRF): A vulnerability that tricks authenticated users into submitting an unwanted request to a web application.

• YMCS (Yellowstone Mission Control System): Described as one of the more established mission control systems, YMCS exhibited a wider range of critical flaws:
• Directory Traversal: A vulnerability allowing attackers to access files and directories stored outside the intended web root directory, potentially exposing sensitive system files or configuration data.
• Arbitrary File Deletion: The ability for an attacker to delete any file on the server, which could lead to denial of service or data destruction.
• Session Hijacking: Exploiting weaknesses in session management to take over an authenticated user's session.
• Multiple XSS vulnerabilities: Further instances of client-side script injection.

• NASA AIT core: A framework designed for developing ground segment software, NASA AIT core presented severe backend and communication issues:
• SQL Injection: A critical database vulnerability allowing attackers to interfere with queries that an application makes to its database, potentially leading to data exfiltration, modification, or even server compromise.
• Multiple Local Code Executions: The most severe type of vulnerability, enabling an attacker to run arbitrary code on the underlying server with the privileges of the application.
• Missing Encryption in Communication: A fundamental security oversight where sensitive data transmitted between components or with operators is sent in plaintext, making it vulnerable to eavesdropping and tampering.

While some of these vulnerabilities, like individual XSS instances, might seem to have limited direct impact on a mission, Olchawa powerfully demonstrated that vulnerability chaining dramatically amplifies their severity. A prime example was the combination of Directory Traversal, Session Hijacking, and XSS in YMCS. This chain allowed attackers, once an XSS payload was triggered, to retrieve any arbitrary file stored on the YMCS server, leading to severe sensitive information disclosure. This highlights that the true risk often lies not in isolated flaws, but in their synergistic exploitation.

Technical Deep Dive

▶ Watch: Severe Impact of Chained Vulnerabilities in YMCS (4:00)

The vulnerabilities discovered in mission control systems underscore a fundamental lack of modern security practices in their development and deployment. Let's delve deeper into the technical implications of these findings, particularly focusing on the most impactful ones and their chaining potential.

Cross-Site Scripting (XSS) was prevalent across NASA Open MCT and YMCS. XSS vulnerabilities arise when web applications fail to properly validate or sanitize user-supplied input before rendering it in a web page. An attacker can inject malicious JavaScript, which then executes in the victim's browser. In the context of an MCS, a successful XSS attack could:

• Steal session cookies: Allowing an attacker to hijack an authenticated user's session without needing their credentials.
• Deface the MCS interface: Presenting false telemetry or telecommand statuses to operators.
• Phish for credentials: Displaying fake login forms to capture operator usernames and passwords.
• Perform actions on behalf of the user: If the MCS allows actions via JavaScript, an attacker could issue commands or modify system settings.

Directory Traversal (or Path Traversal), found in YMCS, is a critical file system vulnerability. It occurs when an application uses user-supplied input to construct file paths without proper sanitization. An attacker can inject sequences like ../ (dot-dot-slash) to navigate outside the intended directory structure and access arbitrary files on the server. In YMCS, this could expose configuration files, logs, sensitive mission data, or even system binaries, which could then be exfiltrated or modified.

Session Hijacking in YMCS, when combined with XSS, becomes particularly potent. If an XSS payload can steal a session cookie, an attacker can then impersonate the legitimate user, gaining full access to their MCS session. This bypasses authentication mechanisms entirely and allows the attacker to perform any action the compromised user is authorized to do, including sending telecommands or accessing sensitive telemetry.

The most critical technical finding was the vulnerability chain in YMCS: XSS + Session Hijacking + Directory Traversal.

1. An attacker crafts a malicious JavaScript payload (the XSS component).
2. This payload is somehow injected into the YMCS interface, perhaps through a shared telemetry display or a malicious internal email.
3. When an operator (Bob in the demo scenario) views the compromised interface, the XSS payload executes in their browser.
4. The JavaScript, leveraging the Session Hijacking vulnerability, gains access to Bob's current authenticated session.
5. Crucially, the script then uses the Directory Traversal vulnerability to craft requests that retrieve arbitrary files from the YMCS server's file system. For example, the script might send an AJAX request to an internal YMCS endpoint, specifying a path like ../../../../etc/passwd or /var/log/ymcs.log.
6. The retrieved file content is then exfiltrated by the malicious JavaScript to an attacker-controlled server. This chain allows an attacker to effectively read any file on the YMCS server, potentially revealing cryptographic keys, mission plans, operator credentials, or sensitive system configurations.

SQL Injection in NASA AIT core highlights a common flaw in database interactions. If AIT core components construct SQL queries by concatenating user input directly without using parameterized queries, an attacker can inject malicious SQL code. This could lead to:

• Data exfiltration: Reading entire database tables.
• Data modification/deletion: Altering or destroying mission-critical data.
• Authentication bypass: Logging in as an administrator.
• Remote Code Execution: In some database configurations, SQL Injection can even lead to executing operating system commands.

Finally, the missing encryption in communication in NASA AIT core is a severe oversight. Sending data in plaintext (unencrypted) over a network, especially one that might span public internet segments due to remote operations, exposes all transmitted information to eavesdropping and tampering. An attacker with network access could read sensitive telecommands, telemetry data, or operator credentials, and potentially modify commands or data in transit, leading to incorrect spacecraft operations or data corruption. This fundamental flaw undermines the integrity and confidentiality of the entire communication channel.

These vulnerabilities collectively paint a picture of MCS applications that, despite their critical function, suffer from security issues commonly addressed in mainstream web development years or even decades ago. The ability to chain these flaws, as demonstrated, significantly escalates the risk from theoretical to catastrophic.

Demo / Proof of Concept

▶ Watch: Live Exploit Demo: XSS Trigger and Data Exfiltration (7:00)

The talk included a compelling demonstration illustrating the devastating potential of chaining seemingly disparate vulnerabilities within the YMCS system. The scenario unfolded as follows:

1. Reconnaissance and Initial Compromise: The attacker begins with a reconnaissance phase, gathering information about the target organization and its employees (e.g., Alice and Bob) from publicly available sources. They then launch a phishing campaign targeting Alice, a colleague of Bob. Alice unfortunately falls victim, clicking a malicious link or opening an infected document, which deploys a Command and Control (C2) beacon on her workstation. This compromises Alice's machine, giving the attacker a foothold within the organization's internal network.

1. Internal Phishing and Payload Delivery: From Alice's compromised workstation, the attacker learns about Bob, another spacecraft operator, through her emails. The attacker then crafts an internal phishing email, impersonating Alice, and sends it to Bob. This email contains a malicious payload designed to trigger the XSS vulnerability within YMCS. The attacker leverages the trust between colleagues to ensure Bob is likely to interact with the payload.

1. Exploit Chain Execution: The demo shows a custom exploit script developed by Olchawa's team. This script first generates the malicious payload, named Xfil.js, and simultaneously starts an HTTP server on the attacker's C2 machine.

• Bob, trusting the email from Alice, is tricked into loading the Xfil.js file onto the YMCS server. This is framed as a legitimate action, such as Alice sharing a new telemetry display with Bob.
• When Bob subsequently opens this seemingly innocuous telemetry display within the YMCS interface, the embedded Xfil.js payload executes in his browser.
• Under the hood, this JavaScript payload triggers the chained exploit: it leverages the XSS to execute arbitrary code, utilizes the Session Hijacking vulnerability to operate within Bob's authenticated session, and then exploits the Directory Traversal flaw to craft requests for arbitrary files on the YMCS server.
• The content of these retrieved files is then exfiltrated back to the attacker's HTTP server, which was set up at the beginning of the exploit.

1. Demonstrated Outcome: The live demonstration visually represented this process. Bob opens what appears to be a blank or simple telemetry display. However, silently in the background, the malicious JavaScript is busy retrieving files from the YMCS server and sending them to the attacker. The attacker's terminal, running the HTTP server, shows incoming requests and the content of the exfiltrated files, confirming successful arbitrary file retrieval from the mission control system.

This proof of concept powerfully illustrated that even seemingly "minor" vulnerabilities, when chained together and combined with social engineering, can lead to complete compromise of sensitive data within a mission-critical system like YMCS. It highlighted the real-world impact of neglecting fundamental security hygiene in space software.

Defensive Implications

▶ Watch: Conclusion: Urgency for Offensive Security Testing (8:00)

The findings presented by Andrzej Olchawa serve as a critical wake-up call for the space industry and organizations operating similar high-stakes, custom-built systems. The primary and most urgent defensive implication is the absolute necessity of offensive security testing.

1. Embrace Offensive Security Testing: The most significant takeaway is that current security strategies, policies, and requirements are insufficient without proactive, offensive testing. Organizations must integrate penetration testing, red teaming, and vulnerability research into their development and operational lifecycles. This can be achieved by:

• Hiring specialized services: Engaging external security firms with expertise in offensive security.
• Developing in-house capabilities: Training and equipping internal teams to conduct continuous offensive testing.
• This testing must occur before systems are deployed and on an ongoing basis to catch new vulnerabilities and regressions.

1. Address Fundamental Software Vulnerabilities: The presence of common web vulnerabilities like XSS, SQL Injection, CSRF, and Directory Traversal indicates a need to re-evaluate basic secure coding practices.

• Input Validation and Output Encoding: Implement rigorous input validation for all user-supplied data to prevent injection attacks (XSS, SQLi, Directory Traversal). Ensure proper output encoding to prevent injected scripts from executing in browsers.
• Parameterized Queries: Always use parameterized queries or Prepared Statements for database interactions to prevent SQL Injection.
• Session Management: Implement robust session management practices, including secure cookie flags (HttpOnly, Secure, SameSite), strong session IDs, and proper session invalidation to prevent Session Hijacking.
• Access Control: Enforce strict Least Privilege principles and Role-Based Access Control (RBAC) to limit the impact of a compromised account.

1. Implement Robust Encryption: The discovery of missing encryption in NASA AIT core communication is a critical flaw. All data in transit, especially for mission control systems, must be encrypted using strong, modern cryptographic protocols (e.g., TLS 1.3). This protects against eavesdropping, tampering, and man-in-the-middle attacks.

1. Secure the Supply Chain and Development Lifecycle: Given that many MCS are custom-developed or rely on open-source frameworks, organizations must scrutinize their entire software supply chain.

• Secure Development Lifecycle (SDL): Integrate security considerations from the design phase through deployment and maintenance.
• Code Review and Static/Dynamic Analysis: Regularly perform security code reviews and utilize automated Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools.
• Dependency Scanning: Continuously monitor and patch third-party libraries and components for known vulnerabilities.

1. Strengthen User Awareness and Phishing Resistance: The demo highlighted social engineering as an initial vector. Organizations must invest in comprehensive cybersecurity awareness training for all personnel, particularly spacecraft operators. This includes recognizing phishing attempts (internal and external), understanding the risks of opening suspicious attachments or clicking unknown links, and reporting suspicious activity.

1. Regular Patching and Updates: Outdated software is a recurring theme. Establish robust processes for regularly patching and updating all MCS components, operating systems, and underlying infrastructure to address known vulnerabilities promptly.

By adopting these defensive strategies, space organizations can move beyond reactive policy enforcement to a proactive security posture, significantly reducing their attack surface and enhancing the resilience of their mission-critical ground segments against sophisticated adversaries.

Key Takeaways

• The increasing shift to remote operations for space missions has significantly expanded the attack surface for critical Mission Control Systems (MCS).
• Many MCS applications, including those developed by prominent organizations like NASA, are built on outdated software stacks and are highly vulnerable to common web application flaws like XSS, SQL Injection, Directory Traversal, and Session Hijacking.
• Offensive security testing (e.g., penetration testing, red teaming) is critically lacking in the space sector, creating blind spots that adversaries can readily exploit.
• Seemingly minor individual vulnerabilities, when chained together, can lead to severe compromises, as demonstrated by the YMCS exploit enabling arbitrary file retrieval from the mission control server.
• Fundamental security oversights, such as missing encryption in communication and local code execution vulnerabilities, pose direct and catastrophic risks to mission integrity and data confidentiality.
• Space organizations must urgently integrate proactive offensive security testing into their development and operational frameworks, alongside robust secure coding practices, regular patching, and comprehensive user training, to safeguard the future of space exploration.

About the Speaker(s)

Andrzej Olchawa is a dedicated security researcher with a focus on offensive security testing, particularly within critical and high-stakes environments such as space systems. His work involves identifying significant vulnerabilities in complex software applications, understanding their potential impact, and demonstrating their exploitability through proofs of concept. Olchawa is committed to responsible disclosure, ensuring that vulnerabilities are reported to vendors and addressed before they can be maliciously exploited. His presentation at DEF CON 32 highlights his expertise in uncovering deep-seated security flaws in specialized systems and advocating for more robust, proactive security measures in critical infrastructure.