An analysis of the Thales satellite hacking demo at CYSAT 2023 with the MITRE EMB3D™ Threat Model

0
22

Disclaimer

Please be informed that the analysis detailed in this article is entirely separate from the hacking experiment conducted by the Thales team on the satellite.

Both activities are independent of each other and were carried out by different teams. There is no association between me and the team that conducted the hacking experiment.

This work is conducted on a personal basis and is independent of my work at Thales. Thales is in no way involved in this work, and Thales’s responsibilities cannot be engaged under any circumstances.

All slides embedded in this article are public slides presented by Thales during the CYSAT 2023 conference and available in the Youtube video which presents the Thales experiment.

Purpose of the article

In this article, I show how I used the MITRE EMB3D™ Threat Model to break down the experiment of Thales satellite hacking demo at CYSAT 2023, identify key lessons learned, and record possible countermeasures.

Brandon Bailey and Brad Roeher from the SPARTA team already did an analysis of the Thales satellite hacking demo (summarized in this article, full article here) but with the SPARTA framework. You can enter to the SPARTA portal here.

The goal with this article is to go further by using the MITRE EMB3D™, a Threat Model for embedded systems, to identify threats and possible associated countermeasures.

Important Note

Before we dive in, I want to clarify an important distinction between threats and vulnerabilities.

Threat modeling tools focus on identifying threats, which are potential risks that could be exploited by an attacker. Vulnerabilities, on the other hand, are specific weaknesses in a system that can be exploited.

In this analysis, it turns out that the threats identified by the threat model were actual vulnerabilities, as they could be exploited by the team.

Hacking demo at CYSAT 2023: what was the point again

For the third edition of CYSAT, the European event entirely dedicated to cybersecurity for the space industry, taking place on 26-27 April 2023 at Station F in Paris, the European Space Agency (ESA) set up a satellite test bench to simulate attempts to seize control of OPS-SAT, a nanosatellite operated by the agency for demonstration purposes.

Thales’s offensive cybersecurity team stepped up to the challenge, identifying vulnerabilities that could enable malicious actors to disrupt operation of the ESA satellite.

Figure 1: Thales Cyber Security Experiment Context (Slide courtesy The European Space Agency).

The results of the ethical satellite hacking exercise, the first of its kind in the world, will be used to tighten security for the satellite and its onboard applications, helping to improve the cyber resilience of space systems, protect sensitive data and support the long-term success of space programs.

To know more about the Thales Demo in video

What is OPS-SAT

OPS-SAT is a small, CubeSat-class satellite developed by the European Space Agency (ESA) to serve as a testbed for innovative software, systems, and operational concepts in space.

From a cybersecurity perspective, OPS-SAT represents a critical platform for experimenting with and addressing the unique challenges of securing space-based assets.

Figure 2: What is the OPS-SAT Space Lab? (Slide courtesy The European Space Agency).

What is MITRE EMB3D™ Threat Model

EMB3D™ is a Cybersecurity Threat Model released by MITRE in May 2024 and dedicated for Embedded Devices.

EMB3D is aligned with and expands on several existing models, including Common Weakness EnumerationMITRE ATT&CK®, and Common Vulnerabilities and Exposures, but with a specific embedded-device focus. The threats defined within EMB3D are based on observation of use by threat actors, proof-of-concept and theoretical/conceptual security research publications, and device vulnerability and weakness reports. These threats are mapped to device properties to help users develop and tailor accurate threat models for specific embedded devices.

Figure 3: The MITRE EMB3D™ Threat Model (figure courtesy The MITRE Corporation).

Each threat description include a set of Foundational, Intermediate, and Leading mitigations. These mitigations will provide guidance on what technical mechanisms can best prevent or reduce the risk of that threat.

For each threat, EMB3D will suggest technical mechanisms that vendors should build into the device to mitigate the given threat. EMB3D is a comprehensive framework for the entire security ecosystem—device vendors, asset owners, security researchers, and testing organizations.

To know more about the MITRE EMB3D™ Cybersecurity Threat Model for Embedded Devices, check our article here.

Analysis of the Thales OPS-SAT hacking Attack Chain

The figure below is showing a summary of the full attack flow used by the Thales team to conduct the attack on OPS-SAT.

Figure 4: Summary of the full attack flow (Slide courtesy Thales Group)

Step 1: Unsafe Java deserialization

To introduce the compromised or flawed software onto the spacecraft, the team needed to bypass security checks and evaluations. To achieve their objective, they introduced a deserialization vulnerability into the software, enabling defensive mechanism evasion and potential exploitation for executing arbitrary commands.

Figure 5: The Deserialization Vulnerability (Slide courtesy Thales Group)

The insecure deserialization threat is documented in the EMB3D Threat Model with the following Threat ID (TID) and Properties ID (PID):

Threat ID Properties ID
TID-326: Insecure Deserialization PID-3121: Device includes support for object oriented programming languages(e.g., Java, Python, PHP, C++)
Table 1: Identified threats for the step 1 (Unsafe Java deserialization)
Figure 6: Stay Undetected – Success! (Slide courtesy Thales Group)

Step 2: Applications Binaries Modified

Once the insecure deserialization achieved, the team uploaded a malicious code with the deserialization vulnerability to modify the application-level binaries on the remote device to introduce unauthorized code and to execute arbitrary commands on the remote system.

Figure 7: Stay Undetected – Execute Arbitrary Commands (Slide courtesy Thales Group)

The ability to modify application-level binaries and to install Untrusted Application on a remote system is documented in the EMB3D Threat Model with the following threats ID and properties ID:

Threat ID Properties ID
TID-301: Applications Binaries Modified PID-31: Application-level software is present and running on the device
TID-302: Install Untrusted Application PID-32: Device includes the ability to deploy custom or external programs (e.g., ladder logic, compiled binaries)
TID-307: Device Code Representations Inconsistent PID-324: Device includes support for “program uploads” to retrieve programs from the device from an engineering workstation
TID-308: Code Overwritten to Avoid Detection
TID-309: Device Exploits Engineering Workstation
Table 2: Identified threats for the step 2 (Applications Binaries Modified)

Step 3: Privilege escalation via the CAN bus

At this stage, their app runs as an unprivileged Linux user and has no direct access to sensors but though the supervisor. Their objective is now to find system configuration issues or vulnerabilities to realize a privilege escalation from user to root.

They identified that anyone can talk on the CAN bus, including unprivileged apps. And then, all commands send on the CAN bus are executing as root by a client that runs as root and that decodes and executes as root whatever command it receives.

Figure 8: Taking Control – Privilege Escalation from User to Root (Slide courtesy Thales Group)

The ability to privilege escalation is documented in the EMB3D Threat Model with the following threats ID and properties ID:

Threat ID Properties ID
TID-114: Peripheral Data Bus Interception
PID-13: Device includes peripheral chips and integrated data buses
TID-412: Network Routing Capability Abuse PID-42: Device includes procedure to forward or route network messages
TID-204: Untrusted Programs Can Access Privileged OS Functions PID-2321: Device lacks an access enforcement/privilege mechanism
TID-219: OS/Kernel Privilege Escalation PID-23221: Device includes and enforces OS user accounts
Table 3: Identified threats for the step 3 (Privilege escalation via the CAN Bus)
Figure 9: Taking Control – Arbitrary Code Execution as Root (Slide courtesy Thales Group)

Step 4: Persistence

At this stage, the app escalated as root. Now, the team needed to ensure persistent effects on sensors. They identified a jar library on the Supervisor that is writable by root user. A jar is simply a zip file, with compiled Java bytecode inside. The team crafted a bytecode based on the original one, and simply replace some files inside the jar. The supervisor now runs the jar containing the malicious bytecode.

Figure 10: Persistence – Injection of a Jar Library (Slide courtesy Thales Group)

The ability to manipulate Runtime Environment, to modify System Component and modify native library of the operating system are documented in the EMB3D Threat Model with the following threats ID and properties ID:

Threat ID Properties ID
TID-304: Manipulate Runtime Environment PID-322: Device includes a program runtime environment for custom or external programs
TID-305: Program Executes Dangerous System Calls PID-3231: Device includes ability to run custom/external programs as native binary without a confined/restricted environment
TID-203: Malicious OS Kernel Driver/Module Installable PID-231: Device includes an operating system that uses drivers/modules that can be loaded
TID-202: Exploitable System Network Stack Component PID-23: Device includes OS/kernel
TID-307: Device Code Representations Inconsistent PID-324: Device includes support for “program uploads” to retrieve programs from the device from an engineering workstation
TID-308: Code Overwritten to Avoid Detection
Table 4: Identified threats for the step 4 (Persistence)

Step 5: OPS-SAT attack by tampering with camera and ADCS

Once the team escalated as root and ensured persistency, they took control on the supervisor and the demo effects was achieved.

Figure 11: Demo Effects – Tampering with Camera & ADCS (Slide courtesy Thales Group)
  • They could alter/delete all images captured by the camera
  • They could override satellite attitude requested by other apps
  • This also provides persistence for the malicious code since the supervisor starts early and is almost always running
Figure 12: Other Potential Effects (Slide courtesy Thales Group)

Threat Heat Map

Using the EMB3D Threat Mapper feature, we create the following Threat Heat Map which represents all the threats affecting the system.

With the EMB3D Threat model, we identified  14 cyber threats. The data is shown into an Excel sheet.

Table 5: Threat Heat Map of the OPS-SAT system

Cyber risk mitigation for satellite system

The figure below shows the high-level countermeasures guidance provided by Thales.

Figure 13: Mitigation Risk – Prevention (Slide courtesy Thales Group)

The figure below shows the result of the analysis conducted by Brandon Bailey & Brad Roeher of the Thales experiment with the SPARTA framework (you can enter to the SPARTA portal here). In this figure, they are showing the full attack chain overlaid with SPARTA TTPs and associated countermeasures (full article of their analysis here).

Figure 14: The full attack chain overlaid with SPARTA TTPs and associated countermeasures. (Slide courtesy Thales Group and SPARTA Team)

In the rest of this article, I propose to identify a list of associated mitigations proposed by EMB3D Threat Model.

 

About Associated Mitigations in  the EMB3D Threat Model

In light of the various threats we have identified, we outline below a list of associated mitigations proposed by EMB3D Threat Model.

Mitigation tiers

These mitigations have varying efficiencies and challenges with their implementations.

Mitigation tiers (foundational/intermediate/leading) are intended to help better understand how to assess the challenge of deploying mitigations and better strategize and prioritize efforts to add additional mitigations or technologies to address threats.

Table 6: List of Mitigation Tiers in the MITRE EMB3D threat model

ISA/IEC 62443-4-2 Mappings

ISA is the International Society of Automation. ISA/IEC 62443 is the applicable standard for cybersecurity of OT and ICS (IACS). Each associated mitigation is mapped with the ISA/IEC 62443-4-2.

List of Associated Mitigations for the OPS-SAT

Step 1: Unsafe Java deserialization

Threats Associated Mitigations Level IEC 62443 4-2 Mappings
TID-326 – Insecure Deserialization
MID-077 – Secure Deserialization Foundational
  • CR 3.5 – Input validation
  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
Table 7: Identified mitigations for the step 1 (Unsafe Java deserialization)

Step 2: Applications Binaries Modified

Threats Associated Mitigations Level IEC 62443 4-2 Mappings
TID-301 – Applications Binaries Modified MID-009 – Operating System-based Runtime Integrity Check Intermediate
  • CR 3.4 – Software and information integrity
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation Leading
TID-302 – Install Untrusted Application MID-041 – Cryptographically Signed Vendor-supplied Programs Foundational
  • CR 3.4 – Software and information integrity
MID-051 – Disallow User-Provided Code Foundational
  • SAR / EDR / HDR / NDR 3.2 – Protection for malicious code
  • CR 3.4 – Software and information integrity
MID-040 – Cryptographically Signed Custom Programs Intermediate
MID-009 – Operating System-based Runtime Integrity Check Intermediate
  • CR 3.4 – Software and information integrity
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation Leading
TID-307 – Device Code Representations Inconsistent MID-042 – Device Checks Consistency Between Binary/Running Code and Textual Code Foundational
  • CR 3.4 – Software and information integrity
TID-308 – Code Overwritten to Avoid Detection MID-017 – Security-relevant Auditing and Logging Foundational
  • CR 2.8 – Auditable events
  • CR 3.7 – Error handling
TID-309 – Device Exploits Engineering Workstation MID-008 – Decidable Protocols and Parsers Intermediate
  • none
Table 8: Identified mitigations for the step 2 (Applications Binaries Modified)

Step 3: Privilege escalation via the CAN bus

Threats Associated Mitigations Level IEC 62443 4-2 Mappings
TID-114 – Peripheral Data Bus Interception
MID-068 – Data Bus Encryption and Message Authentication Intermediate
  • CR 3.1 – Communication integrity – RE (1) Communication authentication
TID-412 – Network Routing Capability Abuse MID-017 – Security-relevant Auditing and Logging Foundational
  • CR 2.8 – Auditable events
  • CR 3.7 – Error handling
MID-038 – Authenticate for Administrative Actions Foundational
  • CR 2.1 – Authorization Enforcement
MID-083 – Network Firewall/Access Control List Foundational
  • CR 5.1 – Network segmentation
TID-204 – Untrusted Programs Can Access Privileged OS Functions MID-012 – OS-based Access Control Mechanisms Foundational
  • CR 2.1 – Authorization Enforcement
TID-219 – OS/Kernel Privilege Escalation
Table 9: Identified mitigations for the step 3 (Privilege escalation via the CAN bus)

Step 4: Persistence

Threats Associated Mitigations Level IEC 62443 4-2 Mappings
TID-304 – Manipulate Runtime Environment MID-013 – Process and Thread Memory Segmentation Foundational
  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
MID-009 – Operating System-based Runtime Integrity Check Intermediate
  • CR 3.4 – Software and information integrity
MID-015 – Containerization Intermediate
  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
  • CR 3.4 – Software and information integrity
TID-305 – Program Executes Dangerous System Calls MID-015 – Containerization Intermediate
  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
  • CR 3.4 – Software and information integrity
TID-203 – Malicious OS Kernel Driver/Module Installable MID-009 – Operating System-based Runtime Integrity Check Intermediate
  • CR 3.4 – Software and information integrity
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation Leading
TID-202 – Exploitable System Network Stack Component MID-007 – Control Flow Manipulation Protections Intermediate
  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
MID-008 – Decidable Protocols and Parsers Intermediate
  • none
TID-307 – Device Code Representations Inconsistent MID-042 – Device Checks Consistency Between Binary/Running Code and Textual Code Foundational
  • CR 3.4 – Software and information integrity
TID-308 – Code Overwritten to Avoid Detection MID-017 – Security-relevant Auditing and Logging Foundational
  • CR 2.8 – Auditable events
  • CR 3.7 – Error handling
Table 10: Identified mitigations for the step 4 (Persistence)

The Advantages of the EMB3D Threat Model for a Satellite System

The EMB3D threat model enables the prioritization of mitigations through categorization into levels (fundamental, intermediate, advanced). This allows for a gradual implementation.

The EMB3D threat model is aligned with standards. The mitigations are mapped to the security controls specified in the ISA/IEC 62443-4-2 standard for industrial control systems.

The EMB3D threat model is complementary to the SPARTA framework. It helps propose additional mitigations, allowing to create a consolidated list of security measures.

Next steps to go further

After identifying the mitigations and countermeasures proposed by the EMB3D threat model, here are the next steps you can take.

The next step in the study will be to verify if the countermeasures proposed by the EMB3D threat model can be embedded on the OPS-SAT system and can effectively prevent all the actions carried out by the team.

The next step can be also to develop an implementation plan and a roadmap to implement the selected mitigations, considering technical and operational constraints.

We could also do a comparative analysis by comparing the mitigations proposed by the EMB3D threat model and the SPARTA framework to check their relevance and to identify overlaps and differences. This will allow to create a consolidated list of security measures.

Acknowledgments

Many thanks to ESA, to the CYSAT conference and to the Thales team for making this experiment possible, and for making it so enriching for the community.

A big thank you also to the SPARTA team, who inspired this article and contribute to strengthening the cybersecurity of satellites and space systems.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.