The content of the article
What are the rootkits for Linux
Rootkits help an attacker secure access to a hacked system, while the emphasis is on the maximum invisibility of the malware. To do this, they hide network connections, processes, folders, files, fake their contents. Typically, a rootkit carries hacking tools to control an infected machine, with which the villain can install and hide in the system DDoS bot or miner (by the way, one such, Skidmap, discovered relatively recently). Most often, these utilities include backdoors, and not only those that can be easily detected by an external port scanner, but using technology Port knocking (something like “tapping ports”) when a port is opened only after a correct and predetermined sequence of requests to closed ports.
Traditionally, all rootkits are divided into working in user space and working in kernel space. Against the former, there are already utilities that can detect many of them: chkrootkit, rkhunter, Antidoto and a project with a straightforward title linux-malware-detect. Therefore, “nuclear” rootkits, which are more difficult to detect directly on the infected system, are of more interest, although some of these utilities can also be detected (but not deleted).
Linux kernel rootkits are usually implemented as loadable kernel modules (LKM, Loadable Kernel Modules), but there are even more exotic ways: malicious code is written directly to the kernel memory via the device file
/dev/kmem or implemented in the early stages of loading with a modification
initrafms (if you are familiar with such rootkits, let me know – only theoretical descriptions come across, but I could not find samples). Now, however, cases of infection with "nuclear" rootkits are rarely written, but the very recently discovered Skidmap suggests that this threat should not be forgotten.
Downloadable kernel modules (
*.koto kernel 2.6 –
*.o) allow you to dynamically expand the functionality of the kernel without the need to recompile it whole. A very useful mechanism for increasing the flexibility of the system and very suitable for creating rootkits that would have the highest possible privileges.
The vital tasks of every rootkit
There are many structures in the kernel that describe the current state of the system. For example, this is a list of running processes, consisting of pointers to process descriptors, which is used by the scheduler. Another important object is a list of loaded kernel modules, where each element points to a handle to a loaded module. It is used by the commands that operate on LKM:
modprobe and the like. These lists relate to internal kernel objects.
Any malicious module first removes itself from the list of loaded modules, because if LKM is not described in it, then the kernel considers that such a module is not loaded. This means that it will not appear in the output
lsmod and will not be unloaded using
rmmod. This technique is called manipulating internal kernel objects (DKOM, Direct Kernel Object Manipulation) and is described in detail in article on Habré.
Also, any good rootkit takes care of how to stay in service after a system restart. For example, Snakso, discovered in 2012, for this prescribes the module load command in
/etc/rc.local, rkduck prefers file
/etc/rc.modules, but Reptile depending on the target system can use and
/etc/modules. Skidmap brings variety to this list and is fixed in cron task scheduler scripts. In general, other files that affect Linux booting, including boot scripts, may be suitable for this purpose. Next, we will call these files startup files.
/etc/rc.localcontains commands that must be executed at system startup. Rootkits add a command there
insmod <путь к вредоносному LKM>.
/etc/rc.modulescontains a list of kernel modules that need to be loaded at startup – at an earlier stage of loading the OS than when using
/etc/rc.local. This file is typical for RPM distributions.
/etc/modulesalso contains a list of modules, but is used in deb-systems.
And everything seems to be simple: check the contents of these files for suspicious lines, and everything will be fine on your system. But the rootkit is not a rootkit, if it does not hide yet that these files are modified. It can intercept system calls and even the kernel functions that are behind these calls: for example, Snakso and Reptile intercept the functions of the VFS (Virtual File System) kernel file subsystem. Rootkits check to see if there was something among the read that needs to be hidden from the eyes of the user or administrator, and if necessary, modify the buffer with the read data.
And when an unsuspecting (or suspecting) user tries to view the contents of a modified rootkit file, he will see only a list of completely legitimate modules or commands. This is what becomes a problem when trying to detect a rootkit while working behind an infected machine. Generally speaking, when infecting rootkits with a kernel level, you should not believe anything that the kernel tells us.
Materiel: how LKM rootkits sweep tracks
Before starting the fight against malicious modules, you need to analyze in more detail the mechanisms by which they hide in the system themselves and hide their protégés – in order to know what to specifically deal with.
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the Xakep.ru community.
Join the Xakep.ru Community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of Xakep.ru