Date: Sun, 14 Jun 2020 17:37:59 +0200
From: Solar Designer <solar@âŚnwall.com>
To: lkrg-users@âŚts.openwall.com
Subject: rootkit detection
Hi,
Adam found this interesting Masterâs Thesis of Juho Junnila, entitled
âEffectiveness of Linux Rootkit Detection Toolsâ:
http://jultika.oulu.fi/files/nbnfioulu-202004201485.pdf
It shows LKRG as the most effective kernel rootkit detector (of those
tested), as long as LKRG is loaded before the rootkit. It also shows
LKRG sometimes detect rootkits even when LKRG is loaded after the
rootkit (we never intended that to work, but it sometimes does anyway,
which is OK). Finally, it shows that LKRG never detects pure userspace
rootkits (as expected; it would probably be a bug if it did).
In particular, when LKRG is loaded before the rootkit, it detected 8 out
of 9 kernel rootkits tested: Diamorphine, Honey Pot Bears,
LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit,
Sutekh. There were no false positives. No other tested rootkit
detector was anywhere close to LKRGâs effectiveness at detecting kernel
rootkits, with AIDE, OSSEC, and Rootkit Hunter detecting 2 out of 9
each, and Chkrootkit detecting none. These other detectors did,
however, detect some userspace rootkits, which LKRG doesnât try to. The
combination of AIDE and LKRG is shown to be most effective, detecting 14
out of 15 rootkits total (both user and kernel space ones).
None of the tools detected Keysniffer, which the thesis describes as:
âKeysniffer is an LKM that can be classified as a kernel mode rootkit
due to its kernel hooking capabilities. It is a keylogger that records
keyboard events to debugfs, an in-memory file system used for Linux
kernel debugging. It does not feature any particular anti-detection
mechanisms except that it prevents accessing the log file by non-root
users and the module is named âkisni.koâ by default to avoid immediate
suspicion when listing kernel modules. (Jana, 2019.) While Keysniffer
may not meet the criteria of all rootkit definitions due to its lack of
specific hiding functionalities, it does meet the criteria by Harley and
Lee (2007) and is thus included in this study.â
While the above doesnât say it, I think the non-detection of Keysniffer
by LKRG is due to it being too similar to non-malicious kernel modules.
The functionality described would conceivably be provided by a module
not intended for malicious use, and the module doesnât need to mess with
the kernelâs integrity to provide this functionality. The non-detection
by other tools is probably because Keysniffer wasnât popular enough, as
its signature-based detection is definitely practical.
Of course, none of these rootkits tried to bypass LKRG. If they wanted
to, they could e.g. simply ârmmod p_lkrgâ before loading themselves into
the kernel. (Or the attacker could do that manually.) In LKRG
development, weâre currently more focused on exploits run before the
attacker got legitimate-looking privileged access to the system. Weâre
not as focused on rootkits, which are loaded with legitimate-looking
privileged access.
That said, there are a few things we could do in the future to make it
more difficult and/or less reliable to bypass detection by LKRG-aware
rootkit loading. We could password-protect the module unloading and
sysctl interfaces of LKRG, and/or provide a way to disable those after
initial configuration. We could also provide setup instructions and/or
our own userspace components around LKRG where alerts would be sent to a
remote system, including alerts of LKRG being unloaded or reconfigured.
Alexander