Disclaimer: ESA has been notified of every vulnerability in this article, two month before the publishing of the article. The team has patched every vulnerability presented in this article. The team has been able to read the article a week before it has been made public. No modification on this article as been allowed from CYSEC or ESA.

Hacking satellite.

Two big words, that sound really impressive. At least to me.

It's a dream among hacking culture, primary built from the different series / movies of the spy / hacker that can "redirect a satellite" to get a better view of his enemy from the orbit.

And from my childhood, I always dreamed of getting that amount of skills. Hacking something you can't see, but that can see you. Because of the power it gives to his user, it's probably among the most critical system in a country defense, and so satellites should be pretty hard to hack.

Or are they ?

During January of this year I stumbled upon an ad for an hacking contest organized by an enterprise called CYSEC that is specialized in space industry.

This enterprise, was calling for hacker participation, with the idea be able to demonstrate in live the possibility and risk of an attack on critical device like satellite during one of their event called the HackCYSAT.

The idea is to raise awareness in the Space industry on these risks, that are getting more and more common. Especially with the new space needs.

The target for this demonstration is an ESA's experimental next generation satelite called the OPS-SAT, built by the same named research team and directed by David Evans.

The rules are simple, the attack should only exploit the payload, system image is provided, and ESA will also provide an experimenter access to the real OPS-SAT to demonstrate and try our attacks.

Because Hacking satellite are two big words, I started by reading publications from the research team, just to get an overview of the size, and my ability to study and maybe hack such device.

And it was pretty accessible.

And so, I registered as an "OPS-SAT experimenter", and after confirmation, I started to work.

Architecture overview

OPS-SAT is a pretty cool satellite. It's a cubesat built to demonstrate an embedded experimental architecture around the "NanoSAT-MF".

The idea of this architecture is to give way more flexibility to current satellite structure by allowing remote upload of application. From earth to satellite.

Allowing the ground operator to upgrade it, or to make new tests. Giving more flexibility and a better lifetime.

Baremetal

To overcome the technical challenge that represent such project, the OPS-SAT team came with a pretty interesting architecture, reusing proven techniques from the commercial embedded computing field and adapting them to space usage. This architecture is divided in two part, the Bus and the Payload.

The bus is taking care of communications (low-level) with it's UHF antenna / transceiver. It also act as a backup solution to reset the system, and to transfer the data when CCSDS engine is unavailable. Very robust solution.

The payload is composed of a 4 MitySOM-5CSX SoM, on the same motherboard, that operate in cold redundancy, along with 4 1GB microSD cards. This part is called the SEPP for "Satellite Experimenters Processing Platform". With it, come all the high-level communication stuff with the different sensors like an HD camera. Everything is communicating by i2c that transport CAN protocol as application layer.

Sweet SEPP

This MitySOM-5CSX SoM comes with a dual core Cortex-A9 @800mhz, and with 1GB of ram. This SoM (System On Module) is built to run on Yocto Linux, a busybox based Linux distribution.

The disk image of the currently, in production, system as been has been given by the OPS-SAT team to every contenders after registration.

Software

First thing I've done is studying from the research paper. As they give everything you need to understand goal, issues, solutions, and so choice that has been made.

The first goal of the NanoSAT MF architecture is the ability to upload / test new experiments or programs. To do so, theses applications are controlled by the NanoSAT MF Supervisor. It's basically the core of all this software architecture.

It's developed in java and take care of all the high level communication stuff such as package management, application management, sensors controlling. And provide an easy to use IPC-CAN API to communicate. Depending of the implementation it can directly have root rights, or through the use of sudo (we'll speak about that later)

To interact with this supervisor and so, the sensors it control, you're application need to use the NanoSAT MF Framework that will translate you're Java calls into the IPC-CAN protocol.

This framework is open-source, and anybody can take a look on it.
Examples and real applications are also available in open-source, like the "OPS-SAT SmartCam":

https://github.com/georgeslabreche/opssat-smartcam

Ground station & application upload process

The ground station and communication bus system are out of scope, but I think it's interresting to get a little overview of it for a better understanding of the OPS-SAT team work.

To upload & control application on the satellite, the OPS-SAT team developped a "Data relay" server that can be called with classic Ethernet IP addr TCP / UDP protocols, that will send experimenters data to a "Mission control system" to translate these data into space protocols (you don't want details there's like a undered of them).

In order to upload data, the "Data relay" server support SFTP upload as well as MAL protocol.

To demonstrate our attack, the OPS-SAT team give us access to this "Data relay" as a normal experimenter.

Let's hack

After this quick overview, the critical part is obviously the Supervisor. Exploitation of it could result to total takeover of the satellite, plus there's a good surface attack from the framework. That why I start with it.

Extraction of the Supervisor JAR file

The ESA provided a system image along with a bmap file that is basically a partition map.

Because the supervisor is probably on a extX filesystem, I decided to go directly with binwalk:

binwalk -e ops-sat-image.mityarm-201810171116-mmcblk.direct

And then in ext-root:

Then I just searched with grep for all .jar files.

Take a look at this line:

lib/systemd/system/nmf.service:ExecStart=/usr/bin/java -classpath "/usr/lib/java/*" esa.mo.nmf.provider.NanoSatMOSupervisorOPSSATImpl

We learn that classpath is /usr/lib/java, and so here is the content of it:

Reverse Engineering of the Supervisor

When I'm in front of a Java application or .jar file, I usually go directly for JADX or any other Java bytecode decompiler depending of the results given by them.

And again, not disappointed. ESA did not remove symbols, or function / variable name from the production image. Making it way easier for me to study it. I mark this as a flaw, we'll speak about that later.

Studying of the code

The first thing I do after decompilation is to search for some keywords on every files. To test for usual vulnerability like RCE (Remote code execution).

Here are few results I got for the keyword shell:

The last one is pretty interesting, here is the code of it:

Is exactly what I look as a starting point. This call contain a string concatenation that can be an injection point for an RCE. Actually this one is not, because str is a string generated with too much formatting and without any control given to the user.

And after few starting points identified, I just read all code around them, and try to understand how can the inputs be manipulated, and how the perfect situation can be created through user actions.

Of course, this is just the starting, If you want to really understand your target, you need to read everything, extract code, make test, etc.

Vulnerabilities found

All theses vulnerability has been reported to ESA, and I personally reviewed fix for them.

Privileged Path traversal write by Zip Slip on upload MAL action. (critical)

After more exploration on the code, I came across a class called NMFPackageManager that take care of the application upload, starting, etc. Especially because all theses class methods are doing system or filesystem interaction, and can be directly called though a MAL access.

The method that interest us here is the installFiles one, that once the package is uploaded take care of uncompression, and move files to the intended path.

The vulnerable part of this code is these three lines:

Basically this code get the current zipFile entry, and then path from the entry.name (which is the relative path of the file from the root archive) and then merge them with just a File.separator between them.

This implementation is vulnerable to ZipSlip vulnerability.

ZipSlip is a vulnerability that is very common in these uncompression implementations.
It is based on an excess of trust on the zip format.

Because the zip format allow archives content files to contains any path valid caracters as a file name, including .. and /. This can be used to describe file location in the previous directory path. Like so: ../../myfile.txt

When the implementation just merge the entry name with the target directory, it is vulnerable to path traversal write allowing to write any file to any location of the filesystem.

In case of a target directory of /home/exp1013/packages/ the merging of an entry name of ../../../root/hello.txt would lead to a result of:

/home/exp1013/packages/../../../root/hello.txt

That is equal to:

/root/hello.txt

Combined with the next vulnerability, and by targeting specific files, this lead to complete takeover of the satellite with root privilege.

Run tests & Exploitation

In case of advanced reverse engineering the best is to directly emulate the system with the use of, for example Qemu. But here, the usage of MAL protocol make things way more complex, and my time is limited.

So I decided, after verifying that no modification occurs on the function inputs that could false my tests, to just extract this code part and test it locally.

To be accepted by the supervisor, the archive needs to follow the NMF Package guidelines. This format use a file called nmfPackage.receipt to act as a file index as well as a package descriptor.

After a bit more of reverse engineering, I've been able to deduct the format of it, here is an example:

It is composed of:

• The version of the package format
• The package name
• The package version
• The timestamp of when the package has been created.

And then, for each file in the archive a chain of FilePath and FileCRC entries. Here, FilePath is the relative path of the zip entry, and FileCRC is the corresponding CRC-32 hash of the file in decimal, this hash has to match the calculated hash by the supervisor to be a valid package.

In our case we'll need to add our file with the return carriage included in the path, as it correspond to our entry name, along with the correct CRC, and to then add both the nmfPackage.receipt and our entry to get our exploit.

Unfortunatly, most archive manager refuse to name an entry with return carriage included.

To do so, I tried to use the project evilarc (https://github.com/ptoomey3/evilarc), but the lack of maintainers made it hard to properly use. Also it didn't fit perfectly to my need. So I decided to go for python with the use of zipfile library.

And here is our package !

To test it, I just had to put one return carriage and dummy payload. Then point my tester on it, validating the exploitation of this vulnerability.

This is obviously very critical has it can be triggered without the app needed to start.

Simple scenario for an IRL exploitation would be to convince the OPS-SAT team to upload this package, by impersonating a normal experimenter.

I didn't wait the end of the competition to show OPS-SAT team this vulnerability.

Mitigation

Don't trust inputs.

The above line is the vulnerable implementation as described earlier. A quick fix could be to patch the generateFilePathForSystem function to sanitize .. caracters, like so:

But even better would be to use dirname like function (Java not my primary language) that get the end filename of a path.

Sudo misconfiguration & Supervisor run as root. (medium)

Also, when I study a new system, I always check the /etc/passwd & /etc/sudoers files.

/etc/sudoers is configured to import every configuration files in /etc/sudoers.d where there's presence of a file called supervisor.

Here, sudo for supervisor user is configured to give root access without the need to provide any password.

Obviously this is a really bad idea as, in case of an RCE (Remote code / command execution), privilege escalation is as easy as saying it.

ESA team confirmed me later, that in production they just started supervisor as root.

So in production, if you get RCE... you're root. Again, don't do that.

Remote command execution on app starting (minor)

Another vulnerability that have a great potential of exploitation, is the implementation of the startApp function, that can be directly called by MAL action.

To start an app the startAppProcess method, generate an appLauncherCommand with the method assembleAppLauncherCommand called with the app name provided to it. This appLauncherCommand is then executed directly as a system command.

In order to correctly generate this command, the assembleAppLauncherCommand perform an operating system detection (from what I know it's not meant to run on a different operating system than linux, I assume this detection is for test purpose), then it craft the command accordingly.

In case of linux, the command is generated by the lines 9 & 10 of the above code.

Again by just merging command with trimmedAppName variable without any sanitizing of inputs, is a bad idea.

But is it vulnerable ?

Yes. trimmedAppName depend, in fact, on the name of the root app folder.

This is tricky because, if it depend on a folder name, it's only vulnerable on Linux.
In order to inject our payload in the command string, we'll need to use special characters to chain commands like &&, |, etc.

Windows don't allow theses characters in filenames, but linux does, and in fact we could create an app with a root folder name of myapp && rm -rf / that once it is launched, will delete everything on filesystem, with again, root rights.

This is scary, and is a real vulnerability, but it's minor. Because the mean of the app starting process, is to execute /bin/sh script. So, we could create a malicious .sh script in place of exploiting this vulnerability. Anyway code execution can occur by design, we'll speak about that later.

Denial of service on app starting by JVM misconfiguration (medium)

Because of the default configuration of the JVM, that allow each program to use 2go of ram. It is possible with a malicious app, to overflow memory and to slow down the entire satellite system by triggering swap write, using a lot of CPU & RAM resources.

With enough time, kernel panic can be triggered.

With repeated and constant attack, satellite can be completely unusable for a period of time decided by the attacker.

The problem of running external application outside of the JVM.

Finally, to give control of their experimenters on the applications they are testing, the OPS-SAT team give control on the operating system though a remote shell as a unpriviledged user. This is also, very bad practice as, an experimenter can attempt priviledge escalation though kernel vulnerability or CPU vulnerability like Meltdown or Spectre.

Geopolitical implies

Satellite has already been a priority target in state conflicts, and people learned it again with the current ongoing conflict between Ukraine and Russia.

Few days after the start of the conflict, hack of European Satellite as a part of military strategy has been reported.

This is no surprise as It has already been reported in the past, and people has been imagining it for years now.

As explained in the start of this article, hacking and therefore controlling enemy satellite allow to cut part of communications, information gathering such as mapping, and basically can help you win a war.

ESA should really team up with security expert in order to avoid some of the vulnerability presented here, most of them as been detected in few days of work, and with very simple techniques.

As I answered in submission to the question "What message would you like to communicate?":

Implementations can be vulnerable, and most implementations are.
No system is secure by default.
By building more complex system, the space industry also take risk to get vulnerable implementations.
Hackers should be part of the development team in order to push back the most as they can the line where difficulty / reliability of the attack is not worth the work involved.

Report & Collaboration with the ESA

ESA has been pretty open to critics on their implementation and architecture.

And especially on the reported vulnerability, that has been patched in weeks.

I enjoyed my relation with the David Evans' team, and would enjoy to work with them again in the future.

Conclusion & thanks

Hope you liked this article, if so, follow me on social networks.

If you think I can be useful for one of your projects, there's a "Hire me" button down bellow.

Thanks to everyone of my readers for giving me a little bit of their time.

Thanks to every people who sent me very kind messages by mail these last months, I appreciate it.

Thanks to David Evans, Dominik Marszk, and all the ESA's OPS-SAT team for their support and feedback.

Sources

• https://directory.eoportal.org/web/eoportal/satellite-missions/o/ops-sat
• https://www.researchgate.net/publication/303098634_OPS-SAT_Operational_Concept_for_ESA%27S_First_Mission_Dedicated_to_Operational_Technology
• https://www.researchgate.net/publication/275639081_CCSDS_Mission_Operations_Services_on_OPS-SAT
• https://www.researchgate.net/publication/303098575_OPS-SAT_Preparing_for_the_Operations_of_ESA's_First_NanoSat