FLAMING RETORT: Linux rootkit news “provides some comic relief”

About two weeks ago, a posting on the Full Disclosure Mailing List announced a new Linux rootkit.

Indeed, the posting didn’t just announce the malware, but included a fully-working sample.

(If you’re interested in the details of this malware, you can read a step-by-step analysis published by a moderately mysterious US company called Crowdstrike.)

So: what is a rootkit? Is this something new to Linux?

Not at all.

Julian Assange, for example, now better known for being holed up in the Ecuador embassy in London, worked on a transparent and deniable disk encryption system at the end of the 1990s. This system ran on Linux, amongst others, and made use of rootkit techniques.

Indeed, the term rootkit originally came from the UNIX world. It described the set of software tools a hacker might use to break into a system, acquire administrative access (known as getting root, after the superuser account, called root), and then hide his presence.

These days, however, rootkits are most commonly associated with Windows. The key “feature” of any modern rootkit is not that it acquires administrative access – which isn’t necessary for malware, though it is certainly very handy – but that it provides a layer of stealth. A smokescreen, if you like, against detection.

This new rootkit, detected by Sophos products as Troj/SrvInjRk-A, uses a whole variety of hiding techniques, and reminds us that the same sort of malware trickery that can be wrought against Windows can be wrought against Linux, too.

Windows and Linux (and OS X, for that matter) are, from a high-level architectural perspective, much more similar than they are different.

Loosely speaking, the operating system is split in two.

There’s a userland part, where programs run such as your web server, your photo editor, and Emacs vi.

And there’s a kernel part, which you can think of as a the “administrator’s administrator”, to manage everything else: memory, use of the CPU, access to disks and other hardware devices, as well as which programs get to run, and what they are allowed to do.

So malware that loads inside the kernel – as this rootkit does – has a number of advantages. Firstly, it’s running on an equal footing to the other kernel code that manages the security of the higher-level, less-privileged userland. Secondly, it gets to see, and, by design, to tweak and modify, everything that comes from userland or is returned to it.

For example, after Troj/SrvInjRk-A loads, it patches a number of kernel system functions. You can see the patches here:

The functions vfs_read and vfs_readdir deal with access to files and directories (vfs stands for virtual file system). Casually modifying those kernel functions like this is horrendously risky, of course, but for a malware author, it’s good enough.

And by hooking tcp_sendmsg, the malware is able to inspect network packets after they’ve been transmitted by your web server, and modify them “in flight” to include malicious content. This means the malicious content never even exists in userland – neither on disk nor in memory.

Interestingly, the malware contains a list of 854 IP numbers and ranges to which it refuses to send modified content. The list is an eclectic mix, including as it does both Google servers and what look like mobile phones, but it reminds us how easy it is for cybercriminals to present a two-faced appearance to the world.

If search engines don’t spot your malware while they’re spidering, and if system administrators or web designers don’t see the altered content even when they’re looking out for changes, your malware will probably survive unnoticed for longer.

Could you be infected with this malware and not know about it?

The good news is, that’s unlikely.

You’d need to be running the Linux kernel labelled 2.6.32-5-amd64 – that pretty much means the 64-bit version of Debian Squeeze 6.0.0. And you’ll have an unexpected kernel module called /lib/modules/2.6.32-5-amd64/kernel/sound/module_init.ko.

We don’t know where this thing came from. Crowdstrike suggests that, “[b]ased on the Tools, Techniques, and Procedures employed and some background information we cannot publicly disclose, a Russia-based attacker is likely,” but that sort of unsubstantiated suggestion doesn’t really help.

In short, we shall probably never know who wrote this thing. But it is one more existence proof for those who deny the very possibility of Linux malware.