SPARTA: CYBERSECURITY FOR SPACE MISSIONS
Hacking an On-Orbit Satellite: An Analysis of the CYSAT 2023 Demo
During the CYSAT ’23 conference, April 26–27 in Paris, France, cybersecurity researchers demonstrated how they seized control of a European Space Agency (ESA) satellite.
Authors: Brandon Bailey & Brad Roeher
Prior to CYSAT ’23, researchers from the Thales Group worked in collaboration with ESA members to create a structured experiment unveiled at CYSAT ’23. The experiment involved performing a cyber-attack against ESA’s OPS-SAT, a nanosatellite launched in December 2019, containing “an experimental computer ten times more powerful than any current ESA spacecraft.”
The SPARTA team analyzed Thales Group’s CYSAT ’23 presentation material along with reporting from The Record, to deconstruct the experiment, extract lessons learned, and document potential countermeasures. The SPARTA Framework was used to identify the tactics, techniques, and associated countermeasures associated with the experiment/attack.
The CYSAT ’23 cyber exercise builds upon similar events like the Hack-a-Sat program sponsored by the U.S. Air Force and U.S. Space Force. Hack-a-Sat 4 at DefCon 31 in August 2023 will leverage an in-orbit Aerospace 3U CubeSat named Moonlighter. The CubeSat has a cyber payload independently recoverable via an alternate communication path, developed to train defensive cybersecurity researchers on a controlled operational system.
Analysis of the OPS-SAT Attack Chain
Background on the OPS-SAT mission which served as the target is detailed in the Thales presentation, below.
The analysis of the attack chain below describes the CYSAT experiment with the addition of the tactics, techniques, and procedures (TTPs) a true attacker might need to conduct a real attack on OPS-SAT.
“The company said its ethical hackers exploited the satellite’s ‘standard access rights to gain control of its application environment’ before then exploiting vulnerabilities and introducing malicious code to the satellite’s systems.”
“Hackers to show they can take over a European Space Agency satellite.” The Record, April 25, 2023.
The researchers were given access to the payload to execute software — part of the design of OPS-SAT—and users get access to the payload interface to run experiments.
If this were a real attack, the attacker would need valid credentials and access to the payload, and the ability to upload software. The researchers/attackers would also need to develop an exploit and select a delivery/execution method for the exploits. These TTPs are covered under the resource development tactic within SPARTA.
As with virtually all cyber-attacks significant reconnaissance and resource development are required to obtain initial access. In this case, initial access was gained with a simulated software supply chain attack via the hosted payload.
- Reconnaissance: Gather Spacecraft Communications Information: Valid Credentials
- Resource Development: Exploit/Payload
- Resource Development: Identify/Select Delivery Mechanism
- Resource Development: Upload Exploit/Payload
- Initial Access: Compromise Hosted Payload
- Initial Access: Compromise Supply Chain: Software Supply Chain
Via this simulated supply chain injection, the researcher implanted a vulnerable piece of code to exploit later. According to Thales, ESA’s standard practice is to scan/test payload code before uploading to the spacecraft; therefore, embedding malicious code would have likely been detected by ESA.
The Deserialization Vulnerability
Researchers had to evade any security scanning or testing to get the malicious/vulnerable software onto the spacecraft. This is an interesting twist on software supply chain attacks where the malware was not necessarily placed into the software, but a vulnerable piece of code was implanted which could be exploited to gain code execution.
By injecting a deserialization vulnerability into the software, it provided defensive evasion in addition to code execution. The deserialization vulnerability is a standard attack prevalent in terrestrial systems for several years.
At the software layer, standard software weaknesses/vulnerabilities can impact the spacecraft. This is unsurprising given the trend for spacecraft to leverage similar technology stacks to terrestrial systems, i.e., Linux, Java, C/C++, etc.
The researchers then used the uploaded code with the deserialization vulnerability to execute arbitrary commands/code on the operating system. This technique was ultimately used to escalate to root privilege on the spacecraft.
Since this code was not considered malicious per se, the applicable TTP from SPARTA is from the execution tactic.
- Execution: Exploit Code Flaws
- Execution: Exploit Code Flaws: Flight Software
Maintaining a Foothold
After achieving code execution, the researchers proceeded to attempt to escalate and establish persistence.
The researchers took advantage of the vulnerability/misconfiguration in the operating system, as well as the absence of bus segregation, due to the fact that numerous software components run as root. Due to the CAN spacecraft bus not properly implementing any segmentation, researchers could send messages across the bus. These messages would be processed by software not typically intended for communication with the payload software.
This leveraged two TTPs from SPARTA from the execution and the other from the lateral movement tactics.
Execution: Exploit Code Flaws: Operating System
Lateral Movement: Exploit Lack of Bus Segregation
For good measure, the researchers wanted to achieve root-level persistence on the spacecraft, electing to inject a software backdoor into the system. This is covered under the SPARTA persistence tactic.
Persistence: Backdoor: Software
This was accomplished with a standard injection technique—a JAVA library injection where malicious bytecode was injected into the JAR file. OWASP provides a significant amount of literature on the topic of injection attacks. Once root access is granted, however, injection attacks are difficult to prevent. A good intrusion detection system is the only real hope for detecting the behavior in these situations.
The OPS-SAT Attack
Once persistence and escalation occurred, the researchers proceeded to attack the “mission” — to affect the integrity of the imagery collected by the camera.
“This made it possible to compromise the data sent back to Earth, in particular by modifying the images captured by the satellite’s camera, and to achieve other objectives such as masking selected geographic areas in the satellite imagery while concealing their activities to avoid detection by ESA,” said Thales.
“Hackers to show they can take over a European Space Agency satellite.” The Record, April 25, 2023.
Execution: Modify On-Board Values: Science/Payload Data
When attackers attack a spacecraft, they are likely looking to impact the mission. This could be imagery, signals collection, etc. Thales Group was able to affect the downlinked payload data to demonstrate the effect. Below are some other effects they mentioned could be achieved post-escalation and persistence, but were not executed. Given root access and persistence, the attacks are basically endless.
- Execution: Attitude Determination & Control Subsystem
- Execution: Electrical Power Subsystem
- Exfiltration: Eavesdropping
- Impact: Deception (or Misdirection), Disruption, Denial, Degradation, Destruction
Risk Mitigation for Space Cyber
Given this attack chain, the question is what can be done about this? What countermeasures would have prevented this?
The Thales Group provided high-level guidance. SPARTA can be leveraged for more detailed countermeasure guidance.
Using the SPARTA Navigator, we create the attack chain. The data is exported into Excel to identify the relevant countermeasures. The analysis then needs to be performed to confirm the associated countermeasure has application for the specific TTPs.
SPARTA helps by providing a menu of countermeasures sorted by defense-in-depth category to help reduce the risk of TTPs. We used the SPARTA navigator to map the attack chain to SPARTA TTPs as shown below:
After exporting the SPARTA Navigator data, eight countermeasures were identified. Five of the eight are terrestrial countermeasures to prevent the vulnerable software from making its way onto the spacecraft. The remaining three are countermeasures on board the spacecraft to protect from and/or detect the TTPs executed during the experiment.
SPARTA Takeaways
When dissecting the flow of an attack, it is important to understand the entire chain. This is crucial because countermeasures can be deployed at each step to disrupt the attack. In this cyber experiment, initial access was granted via the hosted payload. While some may view this as contrived, for OPS-SAT having the ability to upload software to conduct experiments is the intent of the mission.
It is not farfetched when considering hosted payloads in general. Many spacecraft have hosted payloads deployed on their spacecraft/bus, therefore using a compromised payload as an initial access vector is certainly plausible. The initial access via hosted payload in conjunction with a software supply chain injection fully enables the initial access tactic.
The next part of the attack chain is to establish code execution, persistence, and escalation/lateral movement. This was performed by leveraging a pre-positioned vulnerability in the payload code in conjunction with leveraging the lack of segmentation on the CAN bus and lack of least privilege. Using the lack of bus segmentation, i.e., the CAN bus, and the lack of proper privilege management, i.e., running as root, allowed full spacecraft compromise.
Lack of proper bus segmentation is a common vulnerability on many spacecraft. Additionally, process isolation, overly permissive files, and running everything as root is common. While the experiment was manufactured, the TTPs used and the vulnerabilities exploited are valid. The attack briefed at CYSAT confirms that many of the TTPs within SPARTA are accurate and the associated countermeasures in SPARTA can aid in TTP mitigation. The countermeasures documented are directly from SPARTA. If they had been implemented properly on OPS-SAT this specific attack would not have been possible.
This experiment also validates the importance of defense-in-depth. Since ground controls failed to catch the vulnerable payload software, the recommendation would be to implement segmentation, least privilege, and/or onboard IDS capabilities as prevention.
Kudos to CYSEC, the organizers of CYSAT, Thales Group, and ESA for conducting this experiment and sharing their research with the world. Information sharing across the space community will be key as the industry begins to reduce cyber risk across missions.
ICYMI: A full retrospective of the CYSAT 2022 event broadcasted live from Paris, France. Hosted over two days, this was the first opportunity for the space community to discuss cyber challenges related to space missions.
Comments or questions? Please visit the SPARTA contribute page or email sparta@aero.org.
