Archive for the ‘security’ Category

Linux userspace rootkit detector

Looking through the various rootkit detector:


Some are linux, and some are Windows. So here I am proposing more features to add to this technology – linux userspace rootkit detector (not kernel-based rootkit):

1. Dynamic library injection through LD_PRELOAD. So upon the startup of the process, the envionment variable LD_PRELOAD would have been defined. This is not common, but can be easily detected:

/proc/PID/environ will display all the environment variables upon starting up of process.

As you can see above, the environment variables are NULL terminated, and so “grep” will not work – which is newline based, but overcoming this is easy.

2. Network port opening: rootkit may be listening on certain ports waiting for incoming connections. Thus a simple “netstat” should reveal some abnormal listening ports.

3. Network connections: for a server which mainly deals with LAN-based transaction (eg, Oracle database) then all the communications most likely will arise from local communication. But the existence of a rootkit will disrupt this generalization adnd patterns. Some internet IP address in this communication exchanges will likely indicate the existence of internal LAN-based agent communicating with internet-based agents.

4. In dynamic library injection as described in (1) above, you will like to see some weird library files injected into the traditional locations of library files:

Either “lsof” or “cat /proc/PID/smaps” will reveal all the dynamic libraries loaded by the process:

Therefore detect the possible existence of outliers in the dynamic libraries enumeration – for example, the name of the library files can come from some other non-standard directories – is this normal?

BUT do take note that the non-existence of the dynamic files does not mean it is not used – a shellcode can be written to dynamically call dlopen() to load the library file.    (and then you have to use vulnerability to execute the shellcode).  And thereafter dlclose() it after use.

And there are so many other possibilities: what if a process is actively snooping on the keyboard buffer (for each terminal)? what if someone is listening on the mouse?

Doing a “dmesg|grep hda”, I can find a lot of references to /devices/pci* indicating things like /sound/cardx/inputy, or devices/*sound/card0/input0 – these are called “devfs”.

Two techniques are available:   Linux notification API and devices capturing program via devfs.

If you issue a “lsof” you can easily estimate how many mouse and keyboard listening processes are there:



TPM2 and Linux (Intel NUC + TPM2 + Linux)

Back to school: Learning security in Linux: old and new stuff

Linux Security: Securing and Hardening Linux Production Systems

And Ubuntu has a matrix to show its security features:

Seccomp and Sandboxing:

“What the Chrome developers would like is a more flexible way of specifying which system calls can be run directly by code inside the sandbox.One suggestion that came out was to add a new “mode” to seccomp. The API was designed with the idea that different applications might have different security requirements; it includes a “mode” value which specifies the restrictions that should be put in place. Only the original mode has ever been implemented, but others can certainly be added. Creating a new mode which allowed the initiating process to specify which system calls would be allowed would make the facility more useful for situations like the Chrome sandbox.”

Bypassing module_disabled functionality (disabling kernel modules loading):

%d bloggers like this: