hpr-knowledge-base/hpr_transcripts/hpr0082.txt

Episode: 82
Title: HPR0082: Root kits
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0082/hpr0082.mp3
Transcribed: 2025-10-07 11:11:11

---

u
u
u
And hi Linux Basement listeners and welcome to Finix's Student Huckers Guide to Linux
and today's topic, Root Kits. My name is Anne but you guys can call me Finix.
One in today's segment I'm going to talk about Root Kits 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 Root Kits, what they can do, their history,
the varying different types of Root Kits. I'm also going to discuss a couple of possible
countermeasures and steps that you can take to defend yourself against Root Kits.
So I'll start off by describing what a Root Kits is and a little bit about their history.
Well a Root Kits can be best described as a piece of software that functions at the
lowest level in operating system, infiltrating the kernel. Root Kits is a technique that is often
used by hackers and virus creators to hide files and their processes that they're intrusion
traits. This technology has also been used by manufacturers to hide digital rights management
software and one of the best known cases of this was Sony. I can't really talk about Root Kits
without talking about this first. It's one of the best known cases in manufacturers using
Root Kits to hide DRM technology. However due to many issues within their Root Kits and the DRM
software was soon discovered and Sony was left with a lot of egg on their face and some would
say lucky to avoid prosecution. In 2005, Sony BMG, in attempt to prevent people from copying CDs,
started to bundle with its albums two pieces of software that were installed without notice
and without warning in the unit. These packages were called Extended Copyright Protection
or XCP and MediaMars CD-3. Furthermore to this, their lack of any uninstallation software
some argued make them liable for both civil and criminal actions. This incident was the
shock of the world but did it shock the world because the 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 a purchase of a new album. In real terms, the purpose of a Root Kits
to maintain access, attack and compromise other systems and to gather or destroy information
was covering deleting any tracks of them ever being there. However the truth of it is,
Root Kits have been around from at least the mid-90s and tools that went into making the first
Root Kits like file cleaning software which was found back in 1989 on a hack system have been
around for a while. As far back as 1994 when the first Root Kits were becoming apparent on the
Sony OS, then in 1996 when they were discovered on the Linux system. Root Kits all as they are also
known by the term Kits, which I think is an in respect to very good description for them.
You mostly see them being a collection of different tools making a combination of processors
to gain the desired stealthy freedom. It is in unix where the term Root Kits comes from,
a kit to have full privileges of a system and as we all know Root being the account with full
super user privileges. If a corporate company can employ software which are the very heart of it
and its design is to gain full unsolicited access to a system to stop you from copying CDs,
what do you think a hacker could do with this technology? I've personally met victims of Root Kits
whose personal data has been stolen across multiple accounts and had the credit cards and
email addresses being used without their permission. These are not just average weekend computer
users but seasoned experienced computer professionals. Anyone can fall foul to Root Kits. However,
steps can be taken to protect yourself from this. Some can be employed by using plain and simple
common sense, some by the community and some by thinking about security when installing and
preparing your base install. Imagine yourself as a system admin. You have two weeks holiday
planned before you go you unlock all the filing cabinets, write the password to every computer
on a post at note and stick it to the computer. Open every port on your firewall, pick your suitcase,
up and forget the office for two weeks. What do you think the damage would be when you get back?
The reality of a Root Kits is all of the above can be done without the knowledge of the system
However, a key point to remember here is Root Kits are not exploits in themselves. They are only
deployed in an already compromised system. Those threats are as real and windows as they are in Linux.
Root Kits can be broken down into a number of different categories, virtualized Root Kits. These
are the one and the most nasty Root Kits that I can imagine and will be modified and they work
by modifying the boot sequence so that the Root Kits is loaded rather than the OS and from there
they are able to load the original OS as a virtual machine. This enables the Root Kits to intercept
all of the hardware costs that the OS makes. The worrying aspect is twind with the grown number
CPUs that are supporting virtualization technology within their actual chipset and my personal
belief this Root Kits technology will grow and grow. Kernel level. A kernel level Root Kits
works by actually replacing the kernel code or adding extra code to the OS, either in the kernel
or by device drivers. Marge OS is to knock to distinguish the difference between kernel
and device drivers and then so kernel Root Kits tend to come in the form of the loadable kernel
modules in Linux and device drivers in windows. The massive issue here is when on a
fetid access to the code these Root Kits have a tendency to make the OS unstable. They also
know for being very hard to detect as they work at the same layer as the OS. Library level.
Library Root Kits patch or hook system core functions with code that hides the attacker.
In theory they should be easy to find by examining the code libraries for changes
DLLs in windows for changes against the originals however due to updates and service pack upgrades
this isn't so easy in practice. Application level. Application level Root Kits work by replacing
actual binaries of Trojanized ones or they can patch or hook existing binaries.
Firmware Root Kits. Firmware Root Kits infect systems by creating a persistent malware
image within the driver or platform firmware. It is easy for Root Kits to hide here as the code
is really inspected for integrity. Detecting Root Kits can be a bit of a mixback. Root Kits
binaries can mostly be detected by elistic messes or signature base detection in the similar ways
of virus scan or detects viruses as long as they haven't been run by the user and they haven't
concealed themselves. Root Kits have many different tools than one kit that can replace many
important and critical programs and tools within an OS. The problem lies here that you can't
trust the results of what the OS is telling you from a simple case of listing run and processes.
The reality is the OS now doesn't operate in the way it was its design is intended to.
Due to the replacement of critical tools and libraries it is also very unwise if you detected a
Root Kits just to attempt to completely remove it. In most cases this could lead to your system
being completely unstable and permanently damaged. One of the most reliable methods of detecting
a Root Kits is to use a live CD as the OS isn't affected and I'll be able to boot your system
and read on me mana. Non-warning Root Kits cannot hide itself. Root Kits tend to hide themselves
during scan by suspending their services until any scans are completed as you can imagine
it's extremely difficult for a Root Kits to hide itself if it's not allowed to run.
There are many products in both Linux and Windows for detecting Root Kits but the reality holds
clear that prevention is far better than cure. It's a fact that most system admins and experienced
administrators would rather than attempt to remove a Root Kits would save data files, format and
reinstall. Within the imaging software it makes the installation of Kino as a simple procedure
compared to the time effort and cost of a suitably experienced admin to locate, remove and check
system integrity. Now that I have scared you about the damage and implications of Root Kits
I think I should tell you about the many countermeasures you can employ to protect yourself against
these threats. The good news for Linux uses is there are a number of tools available
and for most parts they employ quite simple intelligence in their design. One of the key methods
is fingerprinting the OS so that any critical files have been altered or changed by the Root Kits
can be marked up against the hash and easily notice. The first thing I would like to talk about
is the patch that you could put in between the chair and the keyboard, namely you. I've said this
before but I really wanted to reiterate this point Root Kits are not exploits. They are only used
when a system has been compromised by ensuring that your system is up to date and checking your
system security, trying to prevent it from attacking penetration, make sure that you are using
trusted sources for your software. One of the key defensive strategies to defending yourself
from zero days is mapping the behavior of applications. Two applications spring to mind and a choice
for using them is completely up to you. SC Linux or security enhance Linux and Apple are both
utilised Linux security module or known as LSAN. The criticism of SC Linux is that for an
average desktop user installing a number of packages on a weekly basis, which in my opinion
in a high number of people using Linux are likely to experiment with the open source packages.
The constant configuration of security policies may be a hindrance. I've often been told that
this defensive strategy is best suited for large IT networks that will have installed all the
packages that they need and then use SC Linux more as they lock down to them. In short, and this is
by no means an in-depth explanation of SC Linux uses NSA's MAC which in this context stands for
mandatory access control which cannot be bypassed by a user. I think what I should do here is maybe
explain a couple of terms that I'm going to use here. I'm going to mention what discretionary
access control it's known as DAX. Discussion access control is when a system restricts access
to an object dependent on password or to a group that that object belongs to. User with certain
privileges can either bypass or grant access to that object. You heard me refer to MAC earlier on
which stands for mandatory access control. Munchary access control is when a system restricts
access to an object based on its sensitivity and needing necessary clearance to view it.
Normally by the virtue of flaps this cannot be bypassed and this is what makes it a mandatory
access. When I'm referring to objects try to think of these as a passive entities that control
or receive information. Access to these objects gives you access to those informations that they hold.
Some examples of this would be records, blocks, pages, segments, files, directories,
directories and programs as well as bits, bytes, words, fields, processors, video displays,
keyboards, clocks, printers, network nodes. In the case of SC Linux not only is their objects
but services are also known as domains. Within the construct of domains are not allowed to
access other parts of the system that they one wouldn't generally be in the nature of that
domain to do. So example Firefox wouldn't be able to gain access to any SSH keys.
In this approach it limits the chance of greatly of third party applications being able to have
what we would terms buffer overflows. This is not for the faint hearted and as I've said
there is debate if this is truly a user-friendly enough approach for desktop user market.
Mifelings and by no way base your opinion on this but if you're opening your system up to the
internet and offering services such as a web server or Java server then you should consider some
form of intrusion prevention system. You have a door for everyone to access on the internet
with a service that can be exploited. Another package that I'd like to talk about is a package
called Appama. Now Appama was heavily developed by Naval and what's known as a named based access
control and it also utilizes the Linux security module. One of Appama's main goals is to be easy
to understand and implement. One of the key features of Appama is what's known as 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 logged that down. This allows the user to go back and check
what process is being run when a program was being run. The key feature here is easy deployment
in production how environment however the big keys we profile programs rather than the systems.
We could profile the whole system but this could take a while. The idea we profile a program that
likely be to be targets for exploits such as web prowls, browsers, PDF readers, SSH demons and so on.
The concept is based on a network threat model. Seems as one reality we really are protecting
ourselves against is attacks from outside or within the network. The reality of it is we're making
a firewall of sorts around any application. I'm going to get a little technical here for a second
but I think it will help to clarify some points. There are two security concept models to think about.
One is misuse prevention which works with black lists or the way to think of black lists
are things that we are not allowed to do or anonymally prevention which works by whitelists or things
that we are allowed to do. Black lists are the kind of things that virus killers employ. So it basically
says you can't do this, you can't do that, you can't do this and you can't do that. It's basically
a signature based protection. Well 70 or 1000 signatures later and they are still updating
shows that there's flaws in the misuse prevention because the attackers can always think of new ways
to do things. In a polar opposite, anonymally protection lists what can be done and everything else
is blocked by default. This is by a far more secure model because it doesn't matter what the
attacker thinks of a new way to do something or not. It's still going to be blocked. A good
example of how our partner can defend an application and how we put a firewall around a program
such is NTPD or now at time protocol demon. Now this is a demon that has root privileges and is
going to change something on your system namely the time and it needs a network port open so it
can communicate with the time server to clarify the time. If someone finds an exploit in NTPD
then they could spawn a root shell. Well with app armor we can lock down 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 password files. So if it is exploited then all that
can really be done is that the time view system can be changed. It's very quick to make policies
and I think the learning curve is quite small. We've built in policies for much typical user
stuff and syntax that's pretty easy to understand and implement without too much hard work.
You will need to do your own research on this subject as in the context of this segment
I'm not really going to have time to talk you through configuring it. However both of these tools
are an essence a way of stopping you from being hacked and would give you almost a superior
level of control if someone inserts malicious code into your OS by defining not only how applications
function but at a level well beyond layer security right at the heart of the kernel. I have
supplied many links with many links within this documentation to support this segment and my
advice is to go and take some time and investigate for your own specific requirements. Documentation
will be available on both the Linux Basement website and www.TheLinuxsociety.org.uk.
A more traditional method is to look for a ruckus on the system but in my opinion this is
far too late and it's something I wouldn't do but there are two scanning tools available for
Linux called check root kit and archae hunter. Both are signature based and both have extreme
limitations. Choosing them being signature based they are only going to find root kits that are
well known and not been modified. When you think that root kits are predominantly written and c
it's easy for them to be modified and become undetectable. Now you could run them against the
life your life system it's not recommended or you could run them against an alternate of
media such as a live CD. You could load a live CD, mount your drives and then scan those drives.
That would be the latter would be my suggestion however this is only going to pick up the
much lame root kits and as I've already said if you do find a root kit then it's very very unrise
for you to rip that root kit straight out. Another package that I'd like to talk to you today about
is the package called tripwire. Tripwire is designed to detect any changes that are made to
files and directress and then notify via via via email. There is a lot of work to set this up.
Tripwire stores the information about critical files and the particulars and the database such as
date and time file size and checks on. Then tripwire can match this information about what it knows
about those files against what it finds out about those files. Tripwire needs to update its
records very regular so running it as a cron job is much advised. Then tripwire can send that
in the email when any file that has been changed. Tripwire encrypts its own database as well
to save it from being tampered. The true power of tripwire is its easy detection of
Trojanized biners. This works by checking the checksum of the files. Once a hacker tries to replace
the biners with their own or tamper with other files the checksum will be changed. The concept
is pretty simple in design however the power that it holds is massive. My advice is that if you
set up tripwire you should do it on a clean OS. The added problem if you set it up and you're
already sitting on your system or that you've been running for a while you don't actually know
if you've been root-cuttered or not so you may be giving yourself a full sense of security
and I suppose with the good news that Ubuntu, Harin or becoming out soon I imagine a lot of people
would be doing upgrades. It may be worth while you're doing that to spend some time investigating tripwire
backing up all your data files having a clean OS and installing tripwire. I don't really have
the time to go into a detailed explanation on how to guide but what I can tell you is there's a lot
of links in my support documentation to go along with this segment and there is a lot of
documentation out on the internet. So any of the things that I've talked to you about today's
such as SE Linux app on a tripwire with a day's worth of research you're going to be able to
give yourself a very secure system indeed. Well I suppose that brings us to the end of Finix
the student hackers guide to Linux and this segment to do with root kits. I hope I've not
scared you too much about the dangers of root kits. This is to make you aware that they are there
and they are a real threat. However there are steps that you can't take to defend yourself.
I've said this a couple of times during this segment but it is a point that I'd like to make
very very very clear. Root kits not exploits in their own right. They are only deployed on an
already hacked system. If you take steps to defend yourself against this you take great steps
on defending yourself against being root kid. Once again I'd like to apologise if I've ummed
and erred and sounded a little bit rushed. This is only my second time now of doing anything like this.
Well this has been Finix. I'd like to thank you all for listening. Do go over to either the Linux
basement website or www.thelinuxsociety.org.uk for any support documentation with this segment.
And thank you for listening.