[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200614153759.GA27230@openwall.com>
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
