Attack Vectors in NASA cFS
Trying to assess the vulnerabilities present in modern satellite software
Introduction
What is the purpose of the author?
The authors are trying to assess the vulnerabilities present in modern satellite software. There are several major concerns in regards to basic cyber-security practices that are not implemented in modern satellite systems. The authors hope to provide some basic guidance on building a robust cybersecurity process to protect the Software Bus on satellite systems from cyber attacks. In the past, security professionals believed that the obscurity of flight software and the complexity of it would deter would be bad actors from exploiting the software. This is no longer the case and poses a major security concern (Schalk et al., 2022, p. 350).
What is being researched?
NASA's OSS (open Source Software) cFS (core Flight System) is a generic software architecture framework used on several spacecraft, satellites, and even Raspberry Pi's. The GitHub repository consists of several submodules that anyone can use to build their own flight software with the framework already provided (https://github.com/nasa/cFS). NASA has many goals for cFS that mainly focus on efficiency and cost effectivity for anyone with an interest or goal to utilize flight software for satellites. This will increase collaboration and accelerate development for many individuals as well as businesses (Schalk et al., 2022, p. 352)[2]. It is mentioned that security is not stated anywhere in the cFS design documents, but instead it is recommended that you build your own security alongside your software (Schalk et al., 2022, p. 352)[2]. Since this is the primary software that is used on satellite Software Bus', the authors believe that this will provide the most coverage with their recommended results.
The SPP (Space Packet Protocol) was developed by the CCSDS (Consultative Committee for Space Data Systems) and was built as a reliable communication standard for satellites and is widely adopted by the industry. It does not provide any security function, but security functions can be implemented at the SDLS (Space Data Link Security) protocols at the network layer. SDLS should be implemented if you are aiming for secure communications (as everyone should) (Schalk et al., 2022, p. 351). This still requires cryptographic keys on both ends of the ground station and satellite to be secure.
The authors will be using a tool called OSK (OpenSatKit). OSK is an open source software package used to test out starting up new satellite missions and learning how to operate a ground station and controlling a satellite (Schalk et al., 2022, p. 351). It will be as close to implementing a cyber attack on a real satellite as possible.
Why is researching this problem important?
Most ASAT (Anti-Satellite) research focuses on the electronic and jamming aspects via hypothetical scenarios on unsecured satellites, but when it does focus on cyber security vulnerabilities in satellite systems has mainly focused on protocols, encryption, and credential management, which means the focus is on the data-link side and not in the systems architecture. There are opportunities to focus on cyber ASAT as it is cheap and can take place in "non-hypothetical" scenarios in which real satellites are accessed (Schalk et al., 2022, p. 350). The world is growing more dependent on satellites and with the rise of Reusable Rockets, CubeSats, and OSS (Open Source Software) driving down the cost of a launch, we are going to see a boom in the industry (Schalk et al., 2022, p. 350) and if we are unable to protect these extremely valuable and critical assets, we face major ramifications on national security.
Theory
What is the major theory that the author is proposing?
Up until the recent commercial boom in the space industry and the open sourcing of cFS, most of the details about satellite hardware and software was limited to the government and military. This closed system had a high barrier to entry and significantly limited the amount of research possible into satellite systems (Schalk et al., 2022, p. 351). Now, we have more open source systems that allow for more people to access space.
The Air Force's recent hackathon had a project that showed how easy it is to exploit faulty encryption schemes. Even when it was setup properly it acted as a single point of failure that could easily be exploited. More layers of security are needed than just encryption (Schalk et al., 2022, p. 350). Being able to disable a satellite by non-kinetic means can pose a significant advantage for countries with limited arsenals, but strong cyber capabilities. The threat is very cost advantageous relative to kinetic or electronic ASAT means and can be done by an individual or group of individuals (Schalk et al., 2022, p. 350). The Authors believe that this is a very possible reality in which a small group of nefarious actors with limited resources would be able to disable satellites using the cFS framework.
What is the hypothesis?
Putting all of that together, the authors believe that they can simulate a real satellite operation (OSK) using Open Source and extremely popular flight software (cFS) and use the basic satellite communication protocol (SPP) to do so. If they are able to show at least one exploit that allows them to simulate taken a satellite offline in the same way that a nefarious actor would, they prove the hypothesis of critical cyber-security flaws in open source software.
The authors will do this by attacking the Software Bus in the simulated system. It will be useful to understand some of the common software architecture before moving on further.
The basic architecture of a satellite system is a ground station that transmits commands via up-link and listens for satellite telemetry via down-link. The satellite in space receives the commands form the ground station and executes them then sends back the data (Schalk et al., 2022, p. 352).
Previous versions of satellites had customized and complex hardware that was used to transmit data throughout the satellite. New versions streamline the process by using a Network/Software Bus that receives the data then transmits to other systems/hardware of the satellite, which has helped streamline the satellite manufacturing process (Schalk et al., 2022, p. 351). Also, older satellites would be configured based on their mission, but the cFS allows for "plug and play" opportunities that allow for changing the software and mission via the cFS framework via the cFE. While this is very powerful in its flexibility, you are now able to move data via the Software Bus where in previous architectures you were unable, this opens the door for exploitation (Schalk et al., 2022, p. 353).
The cFE (Core Flight Executive Service) is the backbone of the cFS architecture which relies on the Software Bus. When the satellite starts a number of applications automatically subscribe to the Software Busand start to receive messages. The ground station send a command to the satellite, which then receives it via its communication application and sends the message to the Software Bus. Once all applications that are supposed to receive the message receive it, the command executes. Reverse the process to send data back to the Ground Station (Schalk et al., 2022, p. 353).
![[cFE.png]]
Data Collection and Analysis
What/How was the data collected?
Schalk, Brodnik, and Brown collected data via their testing of a simulated satellite network using NASA's open source and widely popular cFS framework. With some Python programming and computer architecture familiarity they were able to exploit and attack simulated satellite networks that currently several government, military, and commercial launch providers and satellite operators use (Schalk et al., 2022, p. 351).
The data was collected as a response to the actions of the simulated nefarious actors. If the cFS stopped responding, the logs were checked to determine what the failure issue was in the framework. It was a binary response for success criteria, either the satellite continued to work after the cyber attack or it didn't.
What did the analysis show?
Schalk, Brodnik, and Brown were able to simulate 4 different exploits on cFS via OSK; a Replay Attack, a cyber based DoS Satellite attack, an exploit command that deletes the ingest module, and an systematic brute force exploit that sends cFS commands to delete an application of any name (Schalk et al., 2022, p. 353).
In the "Replay" attack Schalk, et al. where able to send a no-op (no operation) command to the health and safety module that did nothing. They were able to repeat this process and insert their own commands into the module and the module was unable to tell a difference between the commands. This means that an adversary could attack the module be putting a nefarious script into a command sent to any module (Schalk et al., 2022, p. 354).
A DoS attack is a "Denial of Service" where you overwhelm the cpu and prevent it from being able to process all of the data coming into the satellite. This is very similar to electronic jamming of a satellite, but significantly cheaper and easier. Jamming requires big, complex equipment that requires a lot of power to jam the external systems. A DoS attack just needs to overwhelm the Software Bus and no other systems (Schalk et al., 2022, p. 354). The Python code on this was extremely simplistic and I didn't have enough room in this paper to explain it and same with the other examples.
The exploit command that deleted the ingest module vulnerability was severe enough the Schalk et al., named this the Cyber-ASAT attack. This is an exploit in the cFS command that deletes the command ingest module that is responsible for receiving commands from a ground station. There is an actual command that deletes applications running on cFS in the cFS framework. This is a major vulnerability. The only way to fix this is to manually reset the software, which is impossible unless you do it from space (Schalk et al., 2022, p. 354). It is equivalent to being able to run a command on your computer that deletes the program that reads input from your mouse and keyboard, and then the only way to reset it is to climb Mount Everest to hit a button.
Schalk et al. were able to exploit the cFS via a brute force attack that iterates through the Software Bus guessing the name and version of applications and deleting them. This is far less sophisticated than their exploit command that deletes the ingest module attack, but just as effective. Since the Software Bus can only handle so many commands at a time this will take quite. while to exploit (Schalk et al., 2022, p. 354).
When dealing with the Software Bus in a satellite, every application has the ability to send and receive commands over the Software Bus with the highest level of permissions. That means that a security exploit in say, an x-ray sensor, has the ability to access and change the software and messages sent to the avionics or data storage. Every message on the Software Bus will be assumed to be a message from an authorized ground station. Stack on-top of this issue that the satellite is using SPP, which has no built-in security mechanisms (Schalk et al., 2022, p. 353).
These 4 types of attacks were very effective against satellites where users would assume that the software was secure.
Results
What were the outputs? Did it prove the authors hypothesis?
A major vulnerability in satellite systems that are using a Software Bus for communication is the fact that if the Software Bus goes down, then the whole satellite goes down. This is also true for the command ingestion module, if that goes down, communications via uplink are unable to be received and the whole satellite is lost (Schalk et al., 2022, p. 353). Security should be developed beyond believing that the data link layer of the network architecture will always be secure (Schalk et al., 2022, p. 355).
There should be an implementation of tools that will scan for vulnerabilities on the system. There also should be command validations that verify the commands will not harm the system or that they are not malicious. Also, there should be remote reset tools that allow the system to be reset to initial mission settings in the case of a compromise (Schalk et al., 2022, p. 355). The architectures that are deployed on satellites need to have the most recent principles of cyber-security employed. They need to rely on Zero-Trust Networks and layered permissions (Schalk et al., 2022, p. p. 355).
Critique
Do you agree with the conclusions drawn from the research? Why or Why Not?
I agree that the lack of security around open source satellite systems is highly exploitable and poses a major risk to national security. This is one of the major reasons that I am in the Master's Program for Space Studies. Technological advantage means nothing if it can easily be disabled cheaply and anonymously from a computer anywhere in the world. These brilliant students in cyber security have laid a foundation for people like myself to go and deploy and simulate similar scenarios in industry. This might be a situation in which I pitch the idea in my day job to setup a simulation lab for satellite operations. The relative cost to doing this is cheaper than procuring a new coffee machine.
Are there any other callouts? Was the data gathered correctly, too much/too little? Where the underlying principles of the research sound?
I would have liked to see some concrete examples of applying some of their recommendations or at least a diagram. That may be a follow up item for them in their research, but just naming cyber security best practices doesn't go as far as showing them. I would say for their process it is very similar to my day to day work as a software developer. I.e. I need to create/add a feature to an application or module, I search GitHub to see if there is already open source software that is similar, if there is I pull or fork the repo into a company managed git account, then I start deploying from the cloned or forked repo. They did exactly that in their research which is highly aligned with industry standards. At bigger companies you may have to go through an additional cyber security review if you are deploying to prod, but with some fancy "word-salading" you can get around most concerns.
Future Work
What future work should come from this research?
Researchers that are leading the field in satellite cyber security are Gregory Falco, who runs Cornell's Aerospace Adversary group that works on research related to satellite cybersecurity and has had dozens of papers to the teams names. James Pavur is also another leading researcher and wrote his thesis on developing security for the new space race (Schalk et al., 2022, p. 351). While this is a great start, we need to have significantly more time and funding security research into open source satellite systems. While these vulnerabilities are the easiest to exploit and have a major impact, they are also the easiest and most cost effective for researching as the simulation environments that replicate the real world are nearly identical and can easily be setup. You could have fleets of university researchers with a couple grand in funding for some cloud or lab resources to constantly learn and combat new threats.
