EPFL/Séminaire security protocols

Un article de Le wiki de 2 noisettes - noisette.ch.

Back : EPFL

Sommaire

[modifier]

The Subject

This page is only the draft for the paper about rootkits

[modifier]

Presentation

The presentation will stand on Monday the 24th April 2006, 09h15 in INM202.

[modifier]

Definition

The word rootkit is composed of two part :

  • root, which is the highest privileged user in a *nix system
  • kit, which refers to a set of tools

A rootkit is thus a set of tools (programms) that helps an attacker to keep a root acces after having compromised a system. It moreover hides the presence and traces of the attacker.

[modifier]
History
  • The term rootkit is very old and is dated back to the days when UNIX ruled the world. It is believed that rootkits originated around 1994, of course the first Operating System that rootkits focused on primarily was Unix, SunOS 4 to be exact. The way the rootkit became unique in that day and age was to simply replace the login binary (they didnt have SSH at that time) and so rootkits began. Rootkits for the UNIX operating system were typically used to elevate the privileges of a user to the root level (=administrator). This explains the name of this category of tools.
  • Stealth viruses on MS-DOS
[modifier]
Features of a rootkit

It is important to understand the distinction between rootkits and viruses/worms. The key distinction between them relates to propagation. In general, a rootkit limits itself to maintaining control of one system as viruses and worms also attempt to spread to other systems. However viruses, worms and rootkits use similar techniques to infect systems (e.g. modify core software components of the system) and hide from the administrator. Of course there are hybrids. A worm can install a rootkit, and a rootkit might include copies of one or more worms, packet sniffers or port scanners.

However rootkits are typically not malicious by themselves. They don't cause deliberate damages but are used to hide malicious code : a malware (virus, worms, backdoors, spywares, ...) could remain active and undetected in a system for a long time if it uses a rootkit, even if the computer is protected with state-of-the-art antivirus.

When talking about rootkits, we generally make the assumption that the attacker has already broken into the system (using any vulnerabilities) and has gained sufficient privileges to install a rootkit (using any local exploits).

The basic features of a rootkit are :

  • to cloak itself to not be detected by the admin, for example by hooking (patching) system call table, by cleaning log
  • to be persistant on the system, for example to be launch itself automatically after each reboot

Moreover, depending of its complexity, it can hide

  • files and directories (according to a prefix, a owner or group owner, ...)
  • processes (the childs of the running rootkit, process which has a custom groupid, ...)
  • network connexions (at a certain port, from/to a given source, ...)

The main prupose of installing a rootkit is to gain a long term remote control of a computer (using a simple tcp listener to a complex ICMP backdoor, going through connexion to an IRC channel), and then to use it to :

  • sniff and spy the network (for logins, ...)
  • launch distributed deny of service (DDos) attack
  • spam
  • ...

There are three main different types of rootkits, given below.

[modifier]
Binary rootkits

This kind of rootkits are the first generation rootkits. They present under the form of patched binaries like ls or ps, which replace the original ones. We speak from trojaned binaries because these binaries act as normally, but they also do others things in the shadow, such as hide some informations, open backdoors, connect to IRC channels, send mails, ...

There is a list of known binaries which are be modified by rootkits, here are some of them : basename biff cron date dirname echo egrep find su ifconfig killall login ls lsof netstat passwd ps pstree sendmail sshd tcpdump top w

[modifier]
Kernel rootkits

The kernel rootkits are the second generation of rootkits. They are inserted very deep into the kernel or the libraries of the operating system. They are harder to detect because they hook system calls, like sys_read(...), sys_open(...) or even sys_kill(...)

The system call table, lets say sys_call_table, is a table which stores the pointers to all the system functions of the kernel.

In Linux operating system, which system function stands at which index of the table is defined into asm/unistd.h : 

#define __NR_restart_syscall     0
#define __NR_exit                1
#define __NR_fork                2
#define __NR_read                3
#define __NR_write               4
#define __NR_open                5
...
#define __NR_inotify_rm_watch  293

The table looks like : 

sys_call_table[__NR_restart_syscall] = 0xc0128f20
sys_call_table[__NR_exit]            = 0xc011ee60
sys_call_table[__NR_fork]            = 0xc0101c00
sys_call_table[__NR_read]            = 0xf9173000
sys_call_table[__NR_write]           = 0xc0161880
...

So we can easily modify any entry of this table to make it point to a custom function of a module. This operation is called hooking. Notice that sys_read has a strange address regarding to the others, so it is very probable that this one has already been hooked.

<<< image >>>

We also find the same concept of system call table in Windows, so the idea of kernel rootkts is the same in both worlds.

Exemple of kernel rootkit for the linux kernel 2.6 :

  • eNYeLKM : it inserts salts inside system_call and sysenter_entry handlers. It does not modify directly sys_call_table, but the effect remain exactly the same, but harder to detect. It then hides files, directories, and processes, as well as chunks inside of files, remote reverse_shell access, etc.

Exemple of kernel rootkit for Windows :

  • HackDefender : registers itself as service to be lauch at each startup, hooks various API in allocating memory inside a process and injecting its own code, and then place a jump into the hooked API to its injected code (ref). It then hides files and process specified in a file called Hxdefxxx.ini, where xxx is a number between 026 and 071.
[modifier]
Virtual-machine based rootkits

This very new kind of rookits, shortly called VMBR, are hopefully only at proof-of-concept phase today. They are deduced by the fact that lower layers in a system have fundamental advantages on uppers, because upper layers depend on abstraction implemented by the lowers. Thus deeper the rootkit is hidden, the more difficult it is to find it. So what happens when the rootkit is underneath the operating system ?

To achieve this goal, one must modify the boot sequence (MRB) to ensure that the VMBR loads before the target operating system. This step is easy to detect with anti-malware system, but a technic is to write the MBR at the last step of shutdown, after most of the running services has already exited.

Once the MVBR is started, it starts the target system, which depends on the virtualization provided by the malware.

<<< VM image >>>

Avoidance : secure hardware, static mbr (Master Boot Record, 1024 first bytes of the hard disk specifying the OS to be started), lower VMM (Virtual Machine Monitor).

This kind of attacks can be detected by several advanced technic, like sidt instruction, response time analysis, cpu/memory/disk/network bandwidth perturbation analysis, non virtualisation of custom I/O

[modifier]

Actuality

  • Rootkits are already quite common in spyware programs but not as common in mass-mailing viruses. There is clear evidence that rootkits is a technique that works in practice. But the actual threat is still small compared to the potential of this technique.
  • Microsoft has publicly warned against the emergence of rootkits during the RSA conference in February 2005 "Be afraid, be very afraid". At the same occasion MS has anounced to be working on a large project called Ghostbuster to protect computers against rootkits.
[modifier]

The Sony scandal

  • In 2005, a large scandal has come up about Sony shipping CDs with special DRM protection behaving as rootkits. It appeared that millions of individual discs had been sold containing either one of the following DRM technologies: XCP, created by the British company First4Internet and shipped on around 20 titles, and MediaMax created by the US company SunnComm and shipped on around 50 titles. The XCP version has become more famous because it is the most virulent version.
  • The basic idea behind the DRM protection is the following: The CD comes with a music player limiting the number of copies to 3. The music files of the CD cannot be read with an other player than the one provided on the CD. Used for DRM purposes, the rootkit installed at the same time as the player scans the machine to check what the user is doing with the CD and sends the information to a web site. The player and thus the CD cannot be run if the rootkit is removed from the computer.
  • The rootkit RCP has been discovered and revealed by Mark Russinovich, a programmer at Sysinternals.
  • Both XCP and MediaMax target only Windows operating system by taking advantage of the autorun feature. The installation of the rootkit is automatically launched when the CD is inserted in the computer.
  • The XCP rootkit patches several kernel functions via the system call table and hides all files, directories, registery key or process whose name begins with $sys$. It creates a big security breach since any other malware can hide by using such a name. It also installs a tricky driver filter on the CD player.
  • There have been reports that multiple malwares (e.g. Troyans, viruses,…) have used the security breaches opened by Sony’s rootkit to hide.
  • Both XCP and MediaMax are installed without the user’s informed consent, are difficult or impossible to uninstall, and transmit information about the user’s activities without notice or consent.
  • The information about the user’s activities sent back to the vendor consists of the user’s IP address, the disc inserted and the times and dates it was inserted.
  • Both XCP and MediaMax were designed to resist detection and removal. No uninstallers were initially provided. Sony has later on proposed an uninstaller after the scandal. The uninstaller reveals to not delete entirely the rootkit and to be even more dangerous than the rootkit itself. The uninstaller is in the form of an ActiveX control. The web page would invoke the uninstaller control, passing it a URL from which to download the uninstaller code. Incredibly no check at all is performed on the URL of the code run, so basically the ActiveX control could be used to execute any malware. The ActiveX control is not even deleted after the deletion of the rootkit but left on the machine, leaving a serious security breach.
  • Sony has modified its uninstaller but it still seems not to delete the rootkit entirely.
  • Experience has shown that purely passive DRM protection schemes have proved useless. To have an effective protection against copying, an active protection scheme is required. This leads to the major difficulty of getting a user to install a software that he doesn’t want (since it prevents him from doing many things). This partially explains how Sony ended shipping rootkits on its CDs.
  • Sony has crossed an important line: It moved from CD provider to software/code provider, but did not take enough care to protect its customers.
[modifier]

Avoidance

Avoiding rootkits remains to the same task as preventing an attacker from gaining administrator privileges on a computer.

Thus all security principles as defense in depth, least privileges, simplicity, ... (no trivial password, using of encrypted protocols, keeping softwares uptodate, ) must be applicated to let the attacker outside of the system

Moreover under linux, it is possible to desactivate the loadable module support 

#CONFIG_MODULES is not set


--> Read-only system (written in a ROM, like xbox), which :

  • cannot be updated easily
  • if we write something wrong into the rom, we cannot boot the device again to change the content of the rom...
[modifier]

Detection

The main problem to detect a rootkit on a rooted system is that we cannot trust the answer of the system anymore, because either its binaries or its kernel have been modified.

The detection of weired activity from the compromised system could even completly failed. The only solution is to refer to external checks.

[modifier]
Methods
  • Use a port scanner (such as nmap) to find open port on the system which cannot be listed by netstat. This would reveale the presence of a TCP backdoor. If the rootkits install more complicated UPD backdoor or ICMP tunnels, the scanner is inefficient.
  • Boot the computer on a sane support, like a LiveCD (Knoppix, SystemRescueCd, Pentoo, WHAX, ...), mount the rooted disk and scan it from the sane system. Current anti-virus have into their signatures databases definitions of the most common rootkits. As the rootkits aren't activated at startup with the external system, they will not hide their footprints.
  • Use cross-view detection technic which typically compares a low level view of a system with a high level view and noting any differences between the two. (Windows, linux for exmple : diff between /proc/modules and lsmod)
  • Memory forensics --> detect hooked syscalls
  • Check integrity files by filling in a (protected) database with the hash of the main binaries and config files. Tripwire and its replacement AIDE.
[modifier]
Tools

The most commmon detections tools to find rootkits are listed below :

  • *nix
    • Rkhunter (scan the system for a list of known rootkits, use cross-view for hidden process detection)
    • Chkrootkit (check the system by finding signatures (actually string) of rootkits into some predefined binaries of the system)
  • Windows
    • Rootkit revealer : RootkitRevealer compares the results of a system scan at the highest level with that at the lowest level. The highest level is the Windows API and the lowest level is the raw contents of a file system volume or Registry hive (a hive file is the Registry's on-disk storage format)
    • F-secure Blacklight : F-Secure BlackLight Rootkit Elimination Technology detects objects that are hidden from users and security tools and offers the user an option to remove them. The main purpose is to fight rootkits and all kinds of malware that use rootkits. The F-Secure BlackLight Rootkit Elimination Technology works by examining the system at a deep level. This enables BlackLight to detect objects that are hidden from the user and security software.
      • F-Secure BlackLight can detect and eliminate active rootkits from the computer. Traditional antivirus scanners can't detect active rootkits.
      • On a normal system F-Secure BlackLight does not confront the user with a long list of suspected objects. This makes F-Secure BlackLight useful even for non-technical users.
      • F-Secure BlackLight Rootkit Elimination Technology can be used in the background during normal system operation. Other available scanners require a reboot during scan or may produce false positives if the system is used during scanning.
    • MS Strider Ghostbuster
[modifier]

Recovery

Once a system has been compromised, the time spent to a full reinstall of the system will be small compared to delete all the entries of a rootkit. Moreover, if one single rooted binary is forgotten, the day we use it the system will be rooted again (remember that the main activity of a rootkit is to keep itself on the system, so each time a rooted binary is running, it may test if the system is always compromised, and if it is not the cas, recompromise it).

[modifier]

Demonstration

[modifier]

Useroot

  • kernel module which allow to go root.

From a chroot, show how to hide process.

Modify the ls source code to hide some files.

Modify the rm source to not delete some files.


  • suid effect (c only because euid isn't set in case of suid flag)

The modification of the name is no longer trivial on 2.6, so the deploy other technics to hide process : advanced rootkits hide all their child (all the processes launched by themself) 

#include <signal.h>
strcpy(argv[0], HIDE_STRING);
signal(SIGCHLD, SIG_IGN);

sys_call_table is no more accessible into 2.6 kernels. We must use some small tricks to recover the pointer. (named system call hooking)

[modifier]

Sony BGM

rename a directory to $sys$... and feel the rootkit.

Lists of CD containing the rootkit

[modifier]

References




Kernel modules

Récupérée de « http://www.noisette.ch/wiki/index.php/EPFL/S%C3%A9minaire_security_protocols »