Spock SLAF : A Shared Library Application Firewall “SLAF”

Spock SLAF is a Shared Library Application Firewall “SLAF”. It has the purpose to protect any service that uses the OpenSSL library. The SLAF inserts hooking to intercept all communication to detect security anomalies and block and log attacks like buffer overflow, path traversal, XSS and SQL injection. So to detect anomalies, Spock uses Deterministic Finite Automaton with rank scores to compute risks and create alerts for each context.

My beginning purpose in this project is to protect any binary that has communication with TLS using OpenSSL resources.

Features

• Action to Block, log and detect security anomalies like SQL injection, XSS, path traversal from SSL_read() function(get input buffers).
• Capacity to run in any programme that uses the OpenSSL library.
• If detect anomaly in TLS context, Spock saves the IP address of the attacker, date time and attack “payload” register in log file.

Etymology

The motivation for this tool was released during a mitigation project in the past seven years an old. Following my freelancer task, an old client has disclosed a problem around deprecated proprietary binary with many vulnerabilities like Heap buffer overflows, remote buffer overflow and path traversal. The big problem of binary context is the application turn abandonware with no patch fixes, but the enterprise needs to run production loads. So my solution was to insert seccomp() to restrict syscalls in the process(you know, block calls like system()/execv()). I replaced libc’s malloc() with “DieHard”, an error-resistant memory allocator. On the other hand, another initiative was little hooking in OpenSSL’s SSL_read() function to restrict some evil payloads, another option.

Another option is to use libreSSL and up a monitor to listen if it has a compatibility bug. The lousy point of LibreSSL is the performance; you can see that if you use a tool like gprof to get a benchmark between OpenSSL and LibreSSL. So OpenSSL is cool but not safest like LibreSSL or lib Sodium. Looking at the performance context, if you get arithmetic functions to big int of OpenSSL, some resources like Big int operations BN_new() do not have a good performance like libGMP. So relax. Performance is not always the best path for security. Security validations and extra buffer and proper bounds checks have an expected cost, without this, you can see a lot of problems for example looking to spectre/meltdown in the past.

Following additional facts, external rules of server using BSD’s firewall(aka packet filter), using custom rules to allow only by IP and OS fingerprint. So that freelancer task stuck in my mind, now you can see my new solution following a global approach to protect TLS communication in the server context.

The first step compile to deploy

Clone the repository:

$ git clone https://github.com/CoolerVoid/spock_slaf

Enter in the folder:

$ cd CoolerVoid/spock_slaf

Compile the content:

$ make clean; make

Now you can see the shared library “spock_slaf.so.1” in “bin” directory.

Second step inject to protect

Second step is inject shared library in your binary that uses OpenSSL following communication context(server).

So now we can use LD_PRELOAD trick:

$ LD_PRELOAD=/home/cooler/spock_slaf/bin/spock_slaf.so.1 bin/rest_server
note: change /home/cooler/spock_slaf/bin/ to your full path name