Understanding rootkits is important, as they’re a common feature of cases where an attacker has successfully gained root/administrator access to a system, and because the effects can be damaging. I also expect all ‘Advanced Persistent Threats’ will involve this. The basic method is simple – hack the target, get root access, install some form of backdoor to maintain that access, and hide the activity from the system administrators. A very skilled attacker could have access to a backdoored system indefinitely.
I once shared the commonly-held belief several years ago that Linux was immune to malware. Many tech-heads still believe that today, and it’s used as a major selling point against Microsoft Windows. While there’s some truth to that, it’s largely because most of today’s malware’s used for data mining and facilitating some economic crime, so it makes more sense to target an OS with the largest attack vector, which happens to be Microsoft Windows.
The process for installing programs on a Linux machine is also more convoluted than Windows’ ‘click-and-run’ method, so it’s harder to get malware installed through social engineering.
But it’s still a cause for concern – somewhere between 70% and 90% of web servers are said to run a variant of UNIX or Linux, and the Android-based mobile devices have already provided a large enough attack vector for the CarrierIQ rootkit. This post is also highly relevant to current speculation over whether Anonymous OS is a Trojan for some kind of backdoor.
Introducing the Rootkit
In itself, deploying a user-level rootkit is a very straightforward process on a UNIX/Linux for someone with administrator/root access, whether it’s the system’s owner or an attacker. This is primarily because Linux allows executables to be created, modified and swapped to automate whatever system-level tasks.
A rootkit would have the following:
* The main executable, or more usually several performing different functions.
* Modified startup script.
* A Command and Control (C&C) server.
The executable(s) are planted somewhere on the system, probably /usr/bin, and the entries are added to whatever script defines which services are called when the system is booted. Of course, one alternative is to plant an installation script that automates all this. Usually the rootkit is hidden by replacing existing executables with malicious ones. For example, the top and ls binaries can be replaced with versions that hide certain files and processes. Not even remote access to the infected machine would be logged.
Because the IP addresses of both target machine and the attacker will change regularly, and because the attacker must somehow locate the target across the Internet each time, they must both establish connections to something with a fixed domain/IP address – the C&C server. With the rootkit telling the server which IP address and port number it’s listening on, the server can relay stuff between the two endpoints. This also provides a proxy for the attacker, and therefore a layer of anonymity to hide behind.
The way to detect this is have another device on the network intercepting traffic, and logging all the IP addresses the hosts are connecting to. With so many binaries on the system, it seems finding the infected ones would be like searching for needles in a haystack, but we only need to look for the ones the attacker must modify, and check those against binaries we know are clean.
The Linux Rootkit (LRC) Backdoor
The Linux Rootkit, introduced in Malware: Fighting Malicious Code, by Ed Skoudis, includes a substitute login executable, which provides a backdoor login separate to the standard one, with its own username and password stored within the executable itself. This means the attacker’s login details won’t appear in the system’s password file, and if the system administrator does reset all the passwords, this won’t affect the backdoor.
A Word About Prevention
We know generally how the user-level rootkit works, which is all well and good, but installing it requires administrator/root access to the target system. Hopefully readers see the connection with the stuff I posted the other week on network penetration – a rootkit is used for maintaining access to the system after it’s been compromised. To prevent this happening, we must think like an old-school hacker, and not some ‘certified ethical expert’ or whatever with 20-odd letters after his name. If a network’s become a prize target, it will be targetted by numerous highly skilled, motivated hackers capable of thinking outside the box. My blog concentrates on the technical side of information security for this very reason.
What I’ve been describing so far is a ‘user-mode’ rootkit, which runs at the user-level just like any program, and it’s relatively easy to determine its presence. We know roughly which executables the attacker will replace, and they can be compared with versions known to be clean. A system administrator could also check the kernel’s output more directly by viewing the contents of the /proc directory instead of running those executables. It’s even possible to automate much of the checking with a relatively simple shell script, and there’s a good chance a targeted organisation would already do this, so something more covert would be used – a kernel-level rootkit.
The kernel is the core of the operating system. It’s essentially the interface between software applications and the hardware, converting between system calls and hardware signals. If we wanted to check the network interface, the number of processes in memory, or which filesystems are mounted, the kernel reads the raw signals from the relevant hardware devices and passes the information to whatever user-level application. The kernel has many other functions, but that’s the long and short of it.
If we wanted to add extra functions and support for certain non-generic hardware, we can add Loadable Kernel Modules using the insmod command, and those modules get loaded into the memory space of the kernel. They become part of the operating system’s core, and this is where kernel-mode rootkits come in. It’s possible to undermine the whole operating system by modifying the kernel, either by changing its source or by making it load a malicious kernel module.
Such a rootkit would provide the attacker with similar functionality to a user-level rootkit, but goes further by preventing system calls that reveal the malicious activity reaching the application layer.
As luck would have it, I stumbled on one example of a kernel-level rootkit known as Adore, which appears to feature in a case study I’m currently doing. The source code for this can also be downloaded from Packet Storm Security.
How a Rootkit Could Improve Security
A rootkit, or something very similar that allows remote access and control while remaining hidden, could be used to our advantage as a security measure. It’s possible for an organisation to install a custom rootkit on all the devices it owns, while establishing a C&C server accessible over a VPN link. If any of the devices are reported mislaid or stolen, the organisation could use this system to trace those devices, disable them and erase any sensitive information they might store.