The Crowdstrike Incident - Practical Part
Summary
In this article, we show an experimental approach of what mechanism leads to the Crowdstrike Incident of July 2024. For the theoretical part, please consult: https://wiki.elvis.science/index.php?title=The_Crowdstrike_Incident
Preamble
The Falcon software itself is only distributed to corporate customers, as it is purely an enterprise product. Therefore, experimenting with the Falcon Sensor for private or student purposes is not possible. However, we will practically demonstrate the mechanisms that led to the system failure. We will address the following points:
- Out-of-bounds memory access
- Race condition
- Channel-file internals
Requirements
For experimenting on a safe environment, we will setup a virtual machine.
- Operating system: MacOS Sequoia 15.1.1
- Virtualization: UTM; https://mac.getutm.app/
- Virtualized system: Windows 11, ARM-version (compatible for Apple Silicon)
- for coding in C: CLion as IDE
- for coding in Java: IntelliJ as IDE
Description
Demonstrating Out-Of-Bound Memory Access
For the practical demonstration, a virtual environment is set up using Windows 11 via UTM on macOS as the host operating system, ARM variant. This allows for experimentation independent of the host system. CLion, an IDE for C, is installed on the virtual machine. The reason for using C as the programming language lies in its memory management - here, faulty memory access can be simulated very easily. We write a program that is supposed to store data passed into an array. An object is defined using TYPEDEF and later instantiated in the running program, which receives more data to write than memory space allocated. This subsequently leads to a malfunction in memory management. In the case of the incident in question, an out-of-bounds write error occurred.
Code-Example