Syscall hooking is a slightly more clever user-mode rootkit methodology that alters the signal handling of syscalls to modify the way programs operate. This methodology takes advantage of the fact that an application's behavior can be altered by changing the default action taken by a process when a signal is delivered. There are various methodologies for performing this, but they all have the same end result: Call function x that returns function y.
One of the newer methodologies is detailed in a whitepaper by "Pluf" entitled "Linux Per-Process Syscall Hooking" (http://www.s21sec.com/descargas/linuxhooking.pdf). This method involves placing hooks in the syscall wrappers code of glibc (as a means of trapping the syscall) to modify the signal handling of the specific syscall wrappers. It is coded in assembly, which means it is as small and fast as possible. The code needs to be capable of the following:
• Utilizing the ptrace interface on Linux and coping or "injecting" itself to the target process
• Avoiding ASLR or similar mechanisms
• Accessing a disassembler engine
• Performing symbol resolution
• Implementing symbol hot-patching routines
• Accessing a sigtrap handler able to dispatch syscall requests
• Error handling in the event of a crash
This particular methodology (as detailed by "Pluf") is fairly new and the proof of concept (POC) has only been out a couple of months (at the time of this writing). Few rootkits in the public arena take advantage of it, but expect to see much more in the future after the bugs are worked out of the POC.
Other forms of syscall hooking have been available for some time, however, and there are many examples of loadable kernel modules that change the way certain system calls are handled by the Linux kernel. Loadable kernel modules are commonplace in Linux and provide most of the driver functionality for the various devices installed on systems. Whenever a new piece of hardware is installed, Linux will load a kernel module for the particular hardware from the kernel itself, if it has one, or the user is forced to load it using insmod or some kind of setup file. This works as long as the module being loaded for an ordinary device, like a SCSI card or a network adapter, is trusted. If a driver is downloaded from a dubious site on the Internet, unforeseen and unpredictable problems can surface.
Some of the more well-known examples of Linux kernel mode rootkits are (in order of popularity, from top to bottom):
• Adore A command-line-based loadable kernel module rootkit supporting Linux kernels 2.2, 2.4, and 2.6, and providing the following functionalities:
• Execute a process as root
• Hide Adore module
• Kernel Intrusion System (KIS) A very slick loadable kernel module rootkit providing all of the functionality of Adore but operated from a very sophisticated GUI and with additional built-in administrative functionality.
• SucKIT A fully functional rootkit that does not require loadable kernel module support. It is loaded through /dev/kmem and is capable of hiding processes, files, and connections. It also includes firewall bypass and connect-back functionality.
Was this article helpful?
Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.