Setting up the attack

Setting up the attack

Step 1: Probing the network
As with any successful attack, the first step was for Mitnick to probe the
network looking for vulnerabilities. The IP spoofing attack started at
about 14:09:32 PST on 12/25/94. The first probes (Figure 53) were from
toad.com (this info is derived from packet logs):


14:09:32 toad.com# finger -l @target
14:10:21 toad.com# finger -l @server
14:10:50 toad.com# finger -l root@server
14:11:07 toad.com# finger -l @x-terminal
14:11:38 toad.com# showmount -e x-terminal
14:11:49 toad.com# rpcinfo -p x-terminal
14:12:05 toad.com# finger -l root@x-terminal


The purpose of the probe was to look for systems that exhibited a trust
relationship that could potentially be exploited using an IP Spoofing
attack. When analyzing the trace it was evident to Shimomura that the
attacker had root access because of the source port numbers for the
showmount and rpcinfo.
Step 2: Silence the trusted server
Having identified the trust relationship between two servers, Mitnick
then proceeded to silence one member of the trusted pair using a
typical SYN flood denial of service to port 513 (login) using a random
unused IP address.
As port 513 is also a “privileged” port, the trusted server could then be
safely used as the putative source for an address spoofing attack on the
UNIX “r-services” (rsh, rlogin).




Step 3: Determine the TCP number generation sequence
To adequately impersonate the remote machine and thus take over the
trust relationship, it was important to determine the TCP number
generation for the service. This was attained by sending multiple
connection attempts from the silenced system (apollo.it.luc.edu) to the
x-terminal.shell. Looking at each returned SYN/ACK response, listed
below in Figure 54, it was possible to determine the sequence stepping
function.
The following extract was recorded by Shimomura:


14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R
1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > x-terminal.shell: S
1382726993:1382726993(0) win 4096
14:18:27.714932 x-terminal.shell > apollo.it.luc.edu.997: S
2022208000:2022208000(0) ack 1382726994 win 4096
14:18:27.794456 apollo.it.luc.edu.997 > x-terminal.shell: R
1382726994:1382726994(0) win 0
14:18:28.054114 apollo.it.luc.edu.996 > x-terminal.shell: S
1382726994:1382726994(0) win 4096
14:18:28.224935 x-terminal.shell > apollo.it.luc.edu.996: S
2022336000:2022336000(0) ack 1382726995 win 4096
14:18:28.305578 apollo.it.luc.edu.996 > x-terminal.shell: R
1382726995:1382726995(0) win 0
14:18:28.564333 apollo.it.luc.edu.995 > x-terminal.shell: S
1382726995:1382726995(0) win 4096
14:18:28.734953 x-terminal.shell > apollo.it.luc.edu.995: S
2022464000:2022464000(0) ack 1382726996 win 4096



From this information Kevin Mitnick was able to deduce the TCP
number generation sequence incremental of 128,000. Note that the
initial sequence numbers increment by one for each connection,
indicating that the SYN packets are not being generated by the system’s
TCP implementation. This results in RSTs conveniently being generated
in response to each unexpected SYN-ACK, so the connection queue on
x-terminal does not fill up.


Step 4: Compromise the Trust Relationship
Once the sequence number generator has been found, Mitnick was able
to send a forged SYN packet (pretending to be the silenced
apollo.it.luc.edu). Assuming the X-terminal terminal normally trusts
the silenced server, it should do whatever the server tells it to do.
The X-terminal, upon receiving the SYN packet, will try and send the
corresponding SYN/ACK, which must then be ACKed for the
connection to be established. This ACK must also be forged from the
attacking machine and is dependent upon knowing the X-terminal’s
TCP number generation sequence to send the appropriate ACK to the
unseen SYN/ACK response.
Why did the server not recognize the IP address to be forged or spoofed
during the connection? The Internet address is in the IP header and the
sequence number is in the TCP header. Only the TCP application keeps
track of the sequence number. If a packet is sent with the wrong
sequence number, the other side will send a RESET and break off the
connection.
Step 5: Setup the Backdoor
With the connection compromised, in a one-way connection, it was
then possible to establish a backdoor to the X-terminal terminal.
Sending the following did this:


14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win
4096
14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win
4096
14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win
4096



Step 6: Clearing-up
With the backdoor in place, all the systems had to be put back to how
they were originally. This included closing spoofed connection to the
X-terminal shell and sending the RST’s to the silenced server
apollo.it.luc.edu to empty the connection queue.
Step 7: System Compromise
Figure 57 is from Shimomura’s newsgroup posting:
After root access had been gained via IP address spoofing, a kernel
module named "tap-2.01" was compiled and installed on x-terminal:


x-terminal% modstat
Id Type Loadaddr Size B-major C-major Sysnum Mod Name
1 Pdrv ff050000 1000 59. tap/tap-2.01 alpha
x-terminal% ls -l /dev/tap
crwxrwxrwx 1 root 37, 59 Dec 25 14:40 /dev/tap


This appears to be a kernel STREAMS module which can be pushed onto an
existing STREAMS stack and used to take control of a tty device. It was used
to take control of an already authenticated login session to target at about
14:51 PST.