Exein core for Linux based firmware
Exein framework's goal is to accomplish the task of protecting the target system from undesirable behavior, introducing the self-protecting and remote-monitoring set of tools into the embedded systems arena.
The natural position of a piece of software providing Run-time anomaly detection features is within the Linux kernel using the Linux Security Module ecosystem.
The task of analyzing the system behavior enumerating system's event is divided into three macro functions:
The LSM Exein is the part of the Exein solution which interfaces with the Linux kernel and exports the system events data to the userspace application module for the analysis. Its main functions are:
The Exein_interface is the glue that makes it possible for the userspace MLEPlayer to communicate with the LSM Exein. It accomplishes this task by defining a new protocol within the Linux Netlink stack. It also provides userspace tools for debugging purposes.
The next part of the list is the code part where the actual computation is performed by the machine learning algorithms. The code block element is called MLEPlayer.
The MLEPlayer embodies the following functions:
Once this repo have been downloaded, in order to build Exein you may want to follow the next steps:
In order to build the Exein you need an environment which includes the following dependencies:
Follow these steps:
To build libexnl is a quite straight forward process. Simply go to the main lib directory and run make
; then place the ./lib/libexnl.so files in your project lib directory.
To build mle-player is a quite straight forward process. Simply go to the main app directory and run make
; then place the mle-player files in its final destination.
To tag an executable is as easy as adding a section in your elf executable file. Here's an example:
echo -ne "\x33\x33" > exein
objcopy --add-section .exein=exein --set-section-flags .exein=noload,readonly /usr/sbin/uhttpd
rm exein
NOTE: you need to use your native architecture objcopy, or the cross tool for your target architecture.
The training of a model starts with the extraction of the target process behavioral data. To collect data from a tagged running process, enable kernel training mode and use /utils/training-forwarder
included in this repository. To enable kernel training mode, just write something in /proc/exein/mode_ctl
.
Just compile the training-forwarder
for your target architecture and run it specifying the monitored process tag and the udp destination where the training-receiver server is listening.
For example to forward training data for tag 13107 to the server listening at UDP:192.168.1.10:13107 using kernel seed 35465436 use the following:
echo 1 > /proc/exein/mode_ctl
./training-forwarder 192.168.1.10 13107 13107 35465436 1350
and then use the training-receiver application. The objective of this activity is to collect the regular behavioral data, therefore it is suggested to test all the functionalities you expect to be used in the target application. The training receiver tool will produce a fairly large csv containing the application regular behavior. At the time of this writing, the online service for training models is not online yet. If you need to train a new model feel free to send the csv file produced by the training receiver tool to test <at> exein.io and we'll send you back the trained model.
MLE-Player is acting as client with respect to the kernel service. In order to receive processes data it needs to register itself to the kernel. For security reasons, each time the kernel is compiled it will generate a random seed, which will be used by the client to prove it is authorized to communicate with the kernel. This seed needs to be specified in the MLE-Player command-line. ROOT users can retrieve this information using the following:
# dmesg |grep "ExeinLSM - lsm is active"
[ 0.001962] ExeinLSM - lsm is active: seed [1841749789]
to start an instance of the MLE-Player you may use the following syntax
# mle-player 1841749789 ARMEL-F-414162-config-13107.ini ARMEL-F-414162-model-13107.tflite
where the first argument is the security kernel seed, the second is the path of the model config file, and the third is the tflite model.
This repository comes with a few models targeted to uhttpd
as example. You can find them in the /sample-models
directory.
Here's an example where the monitored process is the uhttpd.
During the test you should observe that regular traffic to the server is allowed, whereas the non regular behavior of an HTTP server instance acting as a shell is detected and terminated.
Looking at the MLE-Player output, you should see something like the following:
Starting Exein monitoring for tag: 13107
libexnl staring up
Now checking pid 835
INFO: Initialized TensorFlow Lite runtime.
Now checking pid 4432
Now checking pid 4438
Removing pid 4432
Now checking pid 4463
Removing pid 4463
Now checking pid 4481
Block process: 4438
Removing pid 4438
Removing pid 4481
Here's a brief description of the most meaningful parts:
Tags are a central concept of the Exein framework. They act as classifiers and let the Exein framework identify the target processes and their children. Tags are basically 16-bits identifiers that are embedded into executables by adding a section within the ELF header and are checked every time the executable is ran.
Now checking pid 835 notifies the process 835 was added to the watch-list.