Finux's Guide To Rootkits

Hi Linux Basement listeners, and welcome to finux's student hackers guide to Linux, and today's topic rootkit's.

My name is Arron, but you guys can all me finux

Well in today's segment I'm going talk about rootkit's in some detail, now there isn't going to be a practical aspect like last week but more of a discussion. The idea of this guide is to make you aware of rootkit's, what they can do, their history, the varying different type of rootkit's.

I'm also going to discuss couple of possible countermeasures and steps that you can take to defend your self against rootkit's

So i'll start off by describing what a rootkit is and a little bit about their history

well a rootkit can be best described as a piece of software that functions at the lowest level of the Operating System infiltrating the kernel. Rootkitting is a technique that is often used by hackers and virus creators to hide files and and processes that their intrusion creates. This technology has also been used by manufacturers to hide digital right management software, and one of the best known cases of this was Sony.

I can't really talk about rootkit's without talking about this first, it's one of the best known cases of a manufacture using rootkit's to hide DRM technology, however due to many issues within their rootkit and DRM software it was soon discovered, and Sony where left with a lot of egg on their face, and some would say lucky to avoid prosecution.

In 2005 Sony BMG in an attempt to prevent people from copying CD's started to bundle CD's with two pieces of software that where installed without warning and without mention in any EULA, these packages where called Extended Copyright Protection or XCP and MediaMaz CD-3. Further more to this there lack of any uninstallers some argued made them liable for both civil and criminal court actions. This incident was to shock the world, but did it shock the world because a music label had taken extreme steps, or did it bring the general public closer to the truth, that your machine can be hacked with something as simple as the purchase of a new album.

The reality of what the purpose of a rootkit's is to maintain access, attack and compromise other systems, and to gather or destroy information, whilst covering and deleting any tracks of their ever being there. However the truth of it is rootkit's have been around from at least the mid-nineties, and the tools that went into making the first rootkit's, like file cleaning software which was found back in 1989 on a hacked system have been around for awhile. As far back as 1994 when the first rootkit's where becoming apparent on the Sun OS, then in 1996 they where discovered on Linux systems. Rootkit's or as their also known by the term kit's which i think in respect is a very good description for them, due mostly to them being a collection of different tools to make a culmination of process to gain their desired stealthy freedom. It is in fact Unix where the concept was born, and long before Window's had their dominance of today's time. It's to Unix where the term Rootkit comes from, a kit to have full privileges of a system, and as we all know root being the account with full or super user privileges.

If a cooperate company can employ software which at the very heart of it's design, is to gain full and unsolicited access to a system, to stop you from copying a CD, what do you think a hacker would do with this technology. I have personally meet victims of rootkit's who's personal data has been stolen, across multiple accounts, and had their credit cards, and email addresses being used without their permission, these are just not your average weekend computer user, but seasoned, experienced, computing professionals.

Everyone can fall foul to rootkit's, however step's can betaken to protect yourself. Some can be employed by using plain and simple common sense, some by the community, and some by think about security when installing and preparing your base install.

Imagine your self as a sysadmin, you have two weeks holiday planned, before you go you unlock all the filling cabinets. Write the passwords to every computer on a postit note and stick it on them. Open every port on your firewall, pick your suitcase and forget the office for two weeks. What do you think the damage would be when you got back? The reality of rootkit's is all of the above can be done without the knowledge of the sysadmin.

However a very key point to remember that rootkit's are not exploits in them self, they are only deployed in an already compromised system.

These threats are as real for Windows as they are for Linux. Rootkit's can be broken down into a number of different categories, and as technology has grown so has the number of differing kit types.

Firmware Rootkits

firmware rootkit's infect systems by creating a persistent malware image within the driver or platform firmware. It's easy for the rootkit to hide here as the code is rarely inspected for integrity.

Virtualised Rootkits

These are one of the most nastiest rootkit's that you can imagine and work by modifying the boot sequences so that the rootkit is loaded rather than the OS and then from there they are able to load the original OS as a virtual machine, this enables the rootkit to intercept all of the hardware calls that an OS makes. The worrying aspect is twinned with a a growing numbers of CPU that are supporting virtualisation technology within their actual chip-set. In my personal belief this rootkit technology will grow and grow.

Kernel level

A kernel level rootkit works by actual replacement of the the kernel code or adding extra code to the OS, either in the Kernel or by device drivers. Most OS tend to not distinguish the difference between kernel and device drivers, and in so Kernel rootkit's tend to come in the form of Loadable Kernel Modules, in Linux and Device Drivers in Windows. The massive issue here as with unfettered access to the code, these rootkit's have a tendency to make to OS unstable, they also known for being very hard to detect as they work at the same layer as the OS.

Library level

Library rootkit's patch or hook system call function with code that hides the attacker, i theory they should be easy to find, by examining the code libraries for changes (DLL's in Windows) for changes against the originals, however due to up-dates and service pack upgrades this isn't so easy.

Application level

Application level rootkit's work by replacing actual binaries with trojanized ones or they can patch or hook existing binaries.

Detecting rootkit's can be a bit of a mixed bag, rootkit binaries can mostly be detected by holistic measures, or signature based detection, in the similar way as virus scanners detect virus, as long as they haven't been ran by a user and they try to conceal themselves.

Rootkits are many different tools in one kit that can be replace many important and critical programs and tools within an OS, the problem lays here that you can't trust the results of what the OS is telling you, from as simple case of listing running processes. The reality of it is the OS now doesn't operate in the way it designers intended. Due to the replacement of critical tools and libraries, it's also very unwise if you do detect a rootkit, due to it not being developed well enough to hide, just attempting to completely remove it, in most cases this could lead to your system being completely unstable and permanently damaged, some would argue that this is the case since infection.

One of the more reliable methods of detecting rootkit's is to use a liveCD, as that OS isn't effected, and it will be able to boot your system in to a Read-Only, the way to think of this is a non running rootkit cannot hide it's self. Rootkit's tend to hide themselves during scans by suspending their services until any scans are completed, as you can imagine it's extremely difficult for a rootkit to hide itself if it isn't allowed to run.

There are many products in both Linux and Windows for detecting Rootkit's but the reality holds clear that prevention is far better than cure. It's a fact that most sysadmin and experienced administrators would rather than attempt to remove the rootkit, would save data files, format and reinstall, with imaging software it makes the installation of a clean OS a simple procedure compared to the time, effort and cost of a suitably experienced admin locating, removing, and check system integrity.

Now that i have scared you about the damage an implications of rootkit's, i think i should tell you about the many countermeasures you can employ to protect yourself against these threats. The good news for Linux users is there are a number of tools available, and for most parts they employ quite simple intelligent in their design. One of the key methods is fingerprinting the OS, so that if any critical files have been altered as in the case of many rootkit's then these changes can be marked up against hash, and changes can be easily notified to the system admin. What i think the best way of doing this is to talk about the packages that can be installed on your system.

The first i would like to talk about is a patch you can put in between chair and keyboard, namely you. I've said this before but i really want to reiterate this point, rootkit's are not exploits. They are only used when a system has been compromised, by ensuring your system is up-to-date, and checking that your system is not vulnerable to attack and penetration. Making sure that you use trusted sources for your software. One of the key defense strategies is to defend your self from 0day, and map behavior of applications. Two packages spring to mind and the choice of using either one is up-to-you.

SELinux (Security Enhanced Linux) and AppArmor both utilize the Linux Security Module (LSM). The criticism of SELinux is that for an average desktop user installing a number of packages on weekly basis, which in my opinion a high number of people using Linux like to experiment with new open source programs the constant configuration on the security policies may be a hindrance. I have often been told that this defensive strategies is best suited for large IT networks, that will have installed all the packages they need, and then use SELinux more as a Lock-Down tool. In short and this is by no means an in depth explanation, SELinux uses the NSA's MAC's (Mandatory Access Control), which cannot be by-passed by a user as DAC (Discretionary Access Control).

Discretionary Access Control, is when a system restricts access to a object dependent on password or to a group that that object belongs to, users with a certain privileges can either bypass or grant access to that object.

Mandatory Access Control is when a system restricts access to a object based on it sensitivity and necessary clearance, normally by the virtue of flag's. This can not be by-passed and this is what makes it a mandatory control mechanism.

When i'm referring to objects, try to think of these as a passive entities that contain or receives information, access to these objects gives you access to the information that they hold, some examples are, records, blocks, pages, segments, files, directories, directory trees, and programs as well as bits, bytes, words, fields, processors, video display, keyboard, clocks, printers, network nodes.

In the case of SELinux not only is there objects, but services are also known as domain. Within the construct domain are not allowed to access other parts of the system that they would not generally be in the nature of that domain. So as an example Firefox wouldn't need to gain access to anything SSH keys. In this approach it limits the chances greatly of third party application

This is not for the faint hearted and as i said there is debate is this is truly a user friendly enough for most of the desktop user market. My feelings and by no way base your opinions on this, but if you are opening your system up to the Internet and offering services such as a web server or a jabber server then you should consider some for of intrusion prevention system. You have a door for everyone to access on the Internet with, a services that can be exploited, and execution of arbitrary code for privilege escalation.

AppArmor was heavily developed by novel and it what is known as a name-based access control and it too utilizes the LSM.

One of AppArmor's main goals is to be easy to understand and implement. One of the key features of AppArmor is it's learning mode, and at the heart of this mode is to help users maintain and manage policies.

Learning mode is sometimes referred to as 'Complain Mode', and during this mode it will allow process to run that it would have normally denied, and log this. Allowing the users to go back and check what processes are being ran when an program is being run.

The key here is it is easy to deploy in a production environment. However the big key is we profile programs rather than a sysetm, we could profile the whole system but this good take a while. The idea is we profile programs that are likely targets for exploit, such as web browsers, PDF readers, and so on, the concept is based on the network threat model.

Seems as what we in reality are protecting our self from is what programs can be access from or outside the network. It would also be wise to protect yourself from the keyboard threat model as well, this is concept used is protecting kiosks. In reality the goal here is your making a firewall of sorts around any applications.

I'm going to get a little technical for a second but i think it will help to clarify some points. They are two security concept models to think about, one is misuse prevention which works with a blacklist of things that cannot be done, blacklists, and anomaly prevention which works by whitelists of things that can be done. Blacklists are the kinda think virus killers employ, so it basically says, you can't do this, you can't do that, you can't do this, and it's basically signature based protection.

70 odd thousand signatures later, and their still updating shows the flaws in misuse prevention, because attackers can always think of new ways doing things. In polar opposite anomaly protection lists what can be done and everything else is blocked, this is by far a more secure model, because it doesn't matter what if an attacker things of a new way to do something, it's always going to be blocked. A example of this would be say that you have installed NTPD (Network Time Protocol Daemon), which is a protocol that has root privileges, as it is going to change something on your system namely the time, and it needs a network port open so it can communicate with server to clarify the time. If someone finds an exploit in NTPD, then they could spawn a root shell.

Well with AppArmor we can lockdown what access NTPD has to what files,

so much so that we can make sure that NTPD doesn't have access to a shell,

doesn't have access to any other files like the password files.

So if it is exploited then all that can really happen is they can change you time.

It's very quick to make policies and i think the learning curve is quite small, with built in policies for much of typical user stuff, and a syntax that is pretty easy to understand, and implement without too much hard work.

You will need to do your own research on the subject, as within the context of this segment i'm not really going to have time to walk you through configuring it.

However both of these tools are in essence ways of stopping you from being hacked, and would give an almost superior level of control if malicious code enters your OS.

By defining not only how applications function, but at a level beyond Layer security, right at the heart of the kernel I have supplied many links with the documentation to support this segment, and my advice is to go and take some time and investigate your own specific requirements.

The documentation will be available on both the Linux Basement web site, and www.thelinuxsociety.org.uk

Chkrootkit & rkhunter and a LiveCD

A more traditional method for is to look for rootkit on the system, but in my opinion this approach is far to late, and it's something i wouldn't do, but there are two scanning products available for linux called chkrootkit and rkhunter both are signature based, and both have extreme limitations.

Due to them being signature based, they are only going to find rootkits that are well known and have not been modified, when you think that rootkits are predominately written in C it's easy for them to be modified and become undetectable. You could run them against you rlive machine or you could load an alternative OS such as a liveCD and mount your drives and run them against the mounted drives. The later would be my suggestion however, this is ony going to pick up the most lame of rootkits, that a script kiddie that has taken no time in preparing that rootkit would detect.

As i have said once you find a rootkit it's also unwise just to rip it out, it's very easy for hacker to make sure that their rootkits are undetected by these programs. It's a case of installing them their self's and running it to see if it is picked up, if it is then modify the source code and start again.

Tripwire

Tripwire is designed to detect changes made to files and directories and notifiy of these changes, there is a lot of work to set this up.

Tripwire stores information about critical files and there paticulars in a database, such as date, time, file size, and checksum, then tripwire can match this information about what it knows about the files to what it finds when it looks at these files.

Tripwire needs to update it's records very regular so running it as a cron job should be much advisable. Then tripwire can send out an email when any files have been changed, tripwire encrypts it own files so it can't be tampered with.

The true power with Tripwire is the easy detection of trojanized binaries, this is works by taking a checksum of the files, once a hacker tries to replace binaries with their own or tampers with other files, the checksum will change. The concept is pretty simple in design however the power that this hold is massive.

My advice is that if you set Tripwire up on a clean OS your laughing, however if you don't then installing later will only tell you about threats after the point of install.

You maybe already rootkitted and in essence all your doing is giving your self a sense of security that you may not have, this is not to say not to use it, and certainly seems as many of the Ubuntu users will be doing upgrade, it maybe worth taking the time to learn tripwire and deploy it when you upgrade. What i actually mean here is a fresh install and save all your data files, you know you have a clean system and then research and deploy tripwire. As i've said earlier i don't want to get into howto do it in the context of this segment and i have supplied a lot of links for research with in the support documentation

Finux

http://www.thelinuxsociety.org.uk

--------------------------------------------

Links

http://en.opensuse.org/Apparmor

http://en.opensuse.org/AppArmor_Detail

http://www.linuxjournal.com/article/9036 - article on AppArmor Vs SELinux

http://outflux.net/blog/archives/2007/04/02/apparmor-now-in-feisty/ - Guide on installing AppArmor on Fiesty

http://www.novell.com/documentation/apparmor/index.html - Novell's documentation on AppArmor

http://developer.novell.com/wiki/index.php/Apparmor_FAQ

http://en.wikipedia.org/wiki/Rootkit

http://en.wikipedia.org/wiki/Linux_Security_Modules

http://en.wikipedia.org/wiki/Mandatory_access_control

http://en.wikipedia.org/wiki/SELinux

http://en.wikipedia.org/wiki/AppArmor

http://en.wikipedia.org/wiki/Open_Source_Tripwire

https://help.ubuntu.com/community/AppArmor

http://www.linuxjournal.com/article/9972 - article on security features in Ubuntu

https://help.ubuntu.com/7.10/keeping-safe/C/index.html - Keeping 7.10 safe

https://help.ubuntu.com/community/Security - Security at Ubuntu Security Doc's

http://kevinuxtips.blogspot.com/2006/07/turn-your-linux-web-server-into-... - Article on turning your web server into fort knox

http://blogs.techrepublic.com.com/security/?p=264 - Article on Linux/Unix rootkits

http://www.ubuntu-unleashed.com/2007/08/protecting-your-ubuntu-machine.h... - Setting up tripwire on your Ubuntu system

http://tuxtraining.com/2008/04/10/secure-your-system-with-tripwire/ - Securing your system with Tripwire

http://www.linuxhaxor.net/2007/11/27/intrusion-detection-with-tripwire/ - Tripwire as an IDS (Intrusion Detection System)

http://www.kernel.org/pub/linux/libs/security/Orange-Linux/refs/Orange/O... - Nice Glossary to some security/computer terms

http://www.thelinuxsoceity.org.uk - The Linux Group Finux is From Full of Cool dude's and dudette's