User Level Rootkit: Computer Security Systems

User Level Rootkit Computer Security SystemsHamid TarmazdiSohaib Irshad1 cosmosLet us have a look at the definition of the word. The word has two comp one and only(a)nts, root and kit. Root is usually a UNIX/Linux term that is utilize for administrators just like we do in Windows. The word kit is used to denote the programs that allow someone to gain illegal access to root/admin train of the computer by executing some programs in the kit. All of this is done without the consent or knowledge of the end-substance absubstance abuser.This document is the final report on the user level rootkit developed by our team. It contains new and updated information from previous documents. The general aspects are discussed to provide a overview on rootkits in general and specifically user level rootkits. Different features have been described with principle snippets or pseudo reckon depending on complexity and length of the code. The aim has been to make this document as self equal as possible , so the reader can gain information on rootkits and user level rootkits and then proceed to flesh outs of implementing one.2 Usage on that point are two primary usances for rootkit.Backdoor remote command or control of the computerSoftware eavesdropping.Rootkits are used to administratively control a computer, both through legitimate means or otherwise. This means that one can execute files, access logs, monitor the user activity and even able to swap the computer configuration. If we consider the strict definition of rootkit, even some versions of VNC are rootkits.One mannequin of the rootkit use was by Sony BMGs attempt to install a software on user machines to prevent copyright violations.3 PropagationRootkits do not propagate by themselves. They are one single per centum of three part component which we call as Blended Threat. A blended threat has three snippets of code that are dropper, loader and rootkit itself.Dropper initializes the inductance of the rootkit. Dropper is usually activated through human intervention (read error) for example clicking a spiteful link. After it initiates, it executes loader program and then deletes itself to avoid any detection. After the loader has been activated, it causes a buffer overflow which then loads the rootkit into the memory. One of the recent examples of such an attack are through propagation of malicious links through social media sites (Facebook and Twitter). After clicking a malicious link, the rootkit takes control of the client and then sends out messages to every contact on the list. Other example is through Rich content such as PDF files. Just opening such files will execute dropper code and the rootkit is subsequently installed, infecting the computer.4 Types of Rootkits in that location are several types of rootkits that we can discuss.4.1 User-mode rootkitsSuch rootkits usually put up on a computer with administrative rights. This allows the usermode rootkits to change security options and hide outline processes, files, governance drivers, block network ports and system services. These rootkits remain on the infected computer through copying of required files on target computers heavy(p) drive and launch automatically with every system reboot.4.2 Kernel-mode rootkitsBecause the user-mode rootkits can be found by rootkit detection softwares running in nitty-gritty mode, malware developers developed kernel mode rootkits. They placed the rootkit in the same level as operating system and rootkit detection software. In other words, the Operating system could not find the rootkit.4.3 User-mode/kernel-mode hybrid rootkitSome malware developers designed the hybrid of both the rootkits, user-mode for higher stability and kernel mode for greater stealth ability. It is the near triple-crown and most popular rootkit at this moment.4.4 Firmware rootkitThe next sophisticated form of rootkit is firmware rootkit. It is a very complex and harder to detect rootkit. It hides itsel f into the firmware of the computer and set up every time the PC gets rebooted. It can be installed with any firmware such as microprocessor code to PCI expansion card firmware.4.5 Virtual rootkitThese are the most new kind of rootkit in the industry and the most difficult to detect. It acts like a software implementation of a hardware set in a manner similar to used by VMware. Such rootkits are almost invisible. One of the examples of such rootkits is Blue Pill.5 Polymorphism and Detection of RootkitsPolymorphism is one of the techniques that make us difficult to find and remove malwares such as rootkits. It is defined as the ability by the rootkit to rewrite the core assemblycode that makes antivirus pr antispyware signature based defenses useless.6 HistoryThe term rootkit or root kit genuinely is attributed to maliciously modified set of admin- istrative tools in a Unix OS that is granted a root access. If an intruder substitutes the standard administrative tools on a system w ith a program such as rootkit, the intruder could gain root access over the system whilst at the same time obscuring these activities from the legitimate system administrator. These rootkits known as first generation rootkits were prosperous to detect using the tools such as Tripwire. First documented computer virus was discovered in 1986. It used cloaking techniques to hide itself. The Brain virus intercepted more attempts to read the boot sector and then made sure these attacks are redirected to elsewhere on the disk. These disks contained confidential data and also a copy of the original boot sector. Over time, DOS-virus cloaking methods have become more sophisti- cated, with the usage of advanced techniques including the hooking of low-level disk INT 13H BIOS interrupt calls to hide unauthorized modifications to files.7 FeaturesThis theatrical role contains information on general piecealities of the rootkit developed by our team. Feature set is divided into small tasks and t hese tasks are individually completed and integrated.7.1 Achieved functionalityFollowing is a comminuted breakdown of the feature set including implementation expounds.The rootkit shall be installed through modifying LD PRELOAD to pre-load our dynamic subroutine library with our functions to replace their original counterparts in standard C library.The rootkit shall hide LD PRELOAD environment variable.The rootkit shall start automatically on user login.The mechanism of the rootkit must be hidden.7.2 Subtasks7.2.1 req.1To achieve req.1 we have finished sideline sub tasks A sample C program which makes a call to a method from standard C library.A sample dynamic library which redefines the function called in our program.Modifying LD PRELOAD to preload our custom library. modify the modified function to also run the original function in addition to the modified code to avoid breaking functionality.Acceptance criteria req.1 After successfully executing sub-task 4 running the prog ram created in sub-task 1 would result in execution of the modified function in our library created in sub-task 2 in addition to running the original function from standard C libraries. This gives the capability to spy on user program, modify its input/output,etc. Achieving req.1 allows us to run our code within a user program.7.2.2 req.2Following subtasks are finished for req.2.Identify the functions used to retrieve LD PRELOAD by programsHook the functions to hide LD PRELOADAcceptance criteria req.2 The function to check environment variables is getenv, when hooked it should not return the value for LD PRELOAD.7.2.3 req.3To achieve req.3 following tasks have been perusedCreate a volume for initiating the rootkit. We have created a pseudocode for our script which puts our preload library into /lib.Modify /etc/ld.so.preload to include an entry for hooking the dynamic library we have placed in /lib.Acceptance criteria req.3 A script which successfully copies the library and applies the changes to preload when executed.7.2.4 req.4To hide the rootkit, the rootkit file and entry must be hidden. For more detail on hiding please refer to Section 9.Identify the functions involved in listing files The functions are identified in itemization 6.Hook these functions to hide our mechanism. Modified version of 6 out of 8 functions are coded.Acceptance criteria req.4 In order to hide the rootkit, the folder containing the rootkit or the rootkit files and any script must be hidden in addition to hiding LD PRELOAD(req.2). The files and folder of the rootkit shall not be visible.8 ImplementationFollowing we have details on implementation of the different features.8.1 req.1Sub-task 1Following C program is used as a sample program to demonstrate the mechanism.Listing 1 Sample C Programinclude main()printf(This is a valid program.)Sub-task 2We have used printf function as an example for demonstration of this feature, modified version is compiled into a shared dynamic library u sing the following commands gcc -fPIC -c -o fakeprintf.o fakeprintf.cgcc -shared -o libfakeprintf.so fakeprintf.oArgument -fPIC is for position independent code to used in dynamic linking.Listing 2 fakeprintf.cdefine GNU SOURCE include int printf(const char format, ) Sub-task 3To modify LD PRELOAD we can run the following command export LD PRELOAD=$PWD/libfakeprintf.soNow when we run our sample C program there will be no output as the printf function in the modified library will get executed instead of the original printf.Sub-task 4To run the original function in addition to the modified function, we pauperization to obtain a pointer to the original function using dlsym 2 with the argument RTLD NEXT. Code in Listing 3 shows how rmdir has been hooked to prevent from removing the rootkit files while property the functionality of the said function intact everywhere else.Listing 3 fakermdir.cdefine GNU SOURCE include int rmdir(const char pathname) typeof(rmdir) clean rmdirclean rmdir = dlsym(RTLD NEXT, rmdir) /*return if pathname contains rootkit files */return clean rmdir(pathname)8.2 req.2Sub-task 1The function to retrieve environment variables is getenv 1. Sub-task 2The modified version in Listing 4 prevents from retrieving LD PRELOAD. However this method has not been successful in hiding the environment variable.Listing 4 fakegetenv.cdefine GNU SOURCE include char getenv(const char name) typeof(getenv) clean getenvclean getenv = dlsym(RTLD NEXT, getenv) /*return nada if name contains LD_PRELOAD */return clean getenv(name)8.3 req.3The script to install the rootkit follows the pseudocode 5.Listing 5 install.shcompile and copy rootkit.so to /lib remove sourcemodify /etc/ld.so.preload to hook rootkit.so export LD PRELOAD=$PWD/rootkit.so8.4 req.4Sub-task 1List of functions that need to be hooked are in Listing 6. More detail on hiding is providedin Section 9.Listing 6 functionsstat, fstat, lstatInformation about a file, Filter the rootkit files rmdirPrevent remo val opendir, fdopendirFilter the rootkit directory readdir, readdir rPrevent reading the rootkit directorySub-task 2We have coded the hooked functions for stat, fstat, lstat, rmdir, readdir, readdir r. More detail on how to hide the rootkit by hooking this functions in next section.9 HidingDue to their importance the hiding techniques are discussed in more detail in this section. To hide the files/folders the functions which are used to access or get information on these must be hooked. To have a bash which does not show the rootkit files the LD PRELOAD for running the bash have to be hookedLD PRELOAD=/lib/libselinux.so bash -lThe list of functions to be hooked for this purpose is listed in Listing 6, the method on hiding the file/folder is similar so one example is given in Listing 7. All the functions in Listing 6 must be hooked according to the example in Listing 7.Listing 7 Hiding the rootkitdefine GNU SOURCE include int lstat(const char file, struct stat buffer) if(to be hidden (file)) errno = ENOENT return 1return clean lstat(file,buffer)The function to be hidden returns true for each of the files(examplerootkit.so or ld.so.preload) or folders containing files related to the rootkit. Applying this hook to functions in Listing 6 will cause them to skip any file related to the rootkit.References1 Linux man page getenv. http//linux.die.net/man/3/getenv 2 Linux man page dlsym. http//linux.die.net/man/3/dlsym