With the rise of new space, space missions are becoming increasingly more accessible. This is caused by the increased use of commercial-off-the-shelf components as well as the possibility of having multiple parties operating on a single satellite platform. This development combined with a new attitude towards the security of these systems has exposed some flaws in current designs. These concerns are in the lack of defense-in-depth measures on board the satellite and the fully trusted nature of the internal bus. In this thesis we perform a high-level risk analysis for CubeSat missions and map them to the SPACE-SHIELD framework. We then implement several mitigations based on the identified risks, with a focus on less explored research areas. The performance of the mitigations is then evaluated in order to test their viability for use in the industry. We provide a simulator setup for testing and evaluating the mitigations. In order to improve the security of CubeSats we ran several fuzzing campaigns, which have led to the discovery of potentially vulnerable sections of code. Furthermore, we implemented mitigations to achieve network segmentation and end-to-end security on the internal bus of the device. The authenticated encryption scheme implemented for end-to-end security uses the NIST standard for lightweight cryptography known as Ascon. The measurements show that our reference implementation of this AEAD scheme has an overhead of 15% for message payload sizes of 200 bytes. Lastly, we contribute to several entries in the SPACE-SHIELD framework which were lacking before.

System calls are a primary way in which applications to communicate with the kernel. This is to allow them to perform sensitive tasks, however, an application will typically not require all of the system calls available to function properly. Despite this, the Linux kernel allows a program to perform any system call it wishes. This is bad for security, as it allows an attacker full access to the kernel after gaining code execution in a vulnerable program. By extracting a minimal set of system calls for a given program, we can sandbox it and only allow those system calls to be executed, greatly reducing the attack surface. In this paper, we analyze existing solutions that address system call set extraction. In particular, we will focus on applying these to configurable binaries. That is, binaries which can be compiled with a variety of different settings. For this paper, we have chosen to analyze cat as a minimal example, and busybox as the configurable application. We compile busybox in the following configurations, among variations: the default configuration, a configuration containing a minimal set of features and a configuration containing a maximal set of features. We analyze the performance of the tools Binalyzer, Sysfilter and Confine on these binaries. We see that Confine has significantly worse performance than both Binalyzer and Sysfilter. We also see that Sysfilter has better performance than Binalyzer when the complexity of the busybox binary is increased. We conclude that Sysfilter outperforms Binalyzer on binaries without debug symbols, while the opposite is true when performing analysis on binaries with debug symbols.

System call sandboxing is the idea to restrict the set of system calls an application is able to invoke.
This reduces the attack surface available to an attacker exploiting the binary, and adheres to the principle of least privilege, giving entities the minimum required permissions needed to perform their function.

The key goal is to automatically identify which system calls to block, since it is a complex, manual task requiring great insight into the program and its dependencies.

This paper investigates and compares various static analysis based solutions in this field, such as sysfilter [3], Confine [5] and Chestnut [2], by measuring their accuracy and analysis time. Furthermore a simple dynamic analysis based solution is created for the sake of comparison with the previously mentioned tools. The tools are evaluated on a small set of commonly used Linux applications, such as ls, sqlite and Redis, and the results are reported.

In addition to the aforementioned tools, temporal specialization [6], a solution which considers multiple execution phases is also investigated and compared with a purely dynamic analysis solution having support for multiple phases of execution.

The research shows that although dynamic analysis underapproximates the set of required system calls it can adapt to a custom usage profile.
Additionally, although static analysis is slower and more complex, the research explores areas of improvement such as precomputing or multiple threads.

All complex programs are bound to contain software bugs, of which some could be exploited. These exploits rely on the application being able to start – or become – a process that it should not normally. To exploit these applications in this way, the attacker needs the operating system’s kernel to escalate the attacked program’s permissions or to start another process. Sandboxing is a way of stopping the attacker by limiting, which calls a program can make to the kernel – if a program never does start new processes, the sandbox application intercepts all requests (system calls) to do so. In this paper, I develop a script to collect a list of a program’s used system calls (shortened to syscalls) obtained dynamically by an external tool, and compare its output to existing – static – solutions, which extract a program’s system calls by examining its machine code from the binary. Three out of four tested programs functioned correctly after applying the filter, and the fourth one’s failure may be caused by the program I used to perform the sandboxing – firejail. All four resulting lists were almost half the size of the next best performing tested application. Further research should be done into why one of the applications failed in the same scenario that was used to record the syscalls, and how each syscall’s arguments can be filtered to further decrease the possible attack surface.