This method of checking for a LKM rootkit is, in many ways, similar to taking the system off line and performing a forensic analysis of the filesystems. LKM rootkits which employ anti-forensic methods, would not be detectable. As such, I have encountered two such LKM rootkits within the wild for Linux. In the LKM itself this is achieved by replacing or using wrappers at the VFS layer (not modifying the system call table). The replacement code operates by obfuscating the inode and file data, such as xor'ing the data and inode with a static key, except when the rootkit owner 'authenticates' themselves to the rootkit. These anti-forensic methods would most likely appear as a dirty or damaged filesystem, as they introduce anomalies within the filesystem to conceal either the file's inode, or the whole text of the concealed files. AFIK, the only trustable method of detecting a rootkit's presence is to trace to booting of a system, authenticating first the kernel image itself, and all of the executed code after that. (do not forget about your initrd on linux) ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Apr 19 2002 - 07:14:29 PDT