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.