Abstract: In these lectures, we go over the exploits that are possible on the Internet using design weaknesses of TCP rather than software errors. The lab experiments are Connection Killing by RST, Closing a Connection by FIN, The SYN Flooding, and Connection Hijacking.
There are security weaknesses at each layer of the network model and attackers have exploited every one of them. Security at the physical and data link layers is concerned with access to the physical transmission medium. This is accomplished with techniques similar to how you may protect your valuable jewelry.
The phrase TCP/IP typically refers to both TCP and UDP on top of IP. Faking a UDP packet is relatively simple. The header of a UDP packet is very simple due to its connectionless nature. So, it is not much more than IP address forgery (spoofing). Faking a TCP connection is much harder. In this article, we focus on TCP. For a discussion of weaknesses in IP, read [Mateti 2000, IP weaknesses].
TCP and IP were designed at a time when security concerns were almost non-existing and trust was assumed. This section summarizes design weaknesses in TCP from a security point of view. It is important to remember that many implementations have "fixed" these weaknesses, but are not described in RFCs. We assume that the reader is fluent in TCP and IP details (see the References).
The diagram [from the web] enclosed here consists of three separate figures: (a) a TCP state diagram, (b) the three way and (c) four-way handshakes.
The TCP software layer constructs a finite state machine (FSM) at both ends for every (attempted) connection. An FSM consumes memory, and there are possibly thousands of FSMs, one each for a connection, at any given moment. Each connection logically starts in the Closed state, and makes transitions. After the connection is terminated, the TCP FSM returns to the Closed state again, and releases all resources allocated to this connection.
The FSM depends on many timers, coupled to certain states. We discuss a few timers below. TCP RFCs suggest values for some timers, leaving other timers open to individual implementations.
An example of a state without an associated timer is the CLOSE_WAIT state. With a default value of the keep-alive timer of 2 hours, the state-machine can be frozen for that long.
TCP exploits are typically based on (i) IP spoofing and (ii) sequence number prediction. In establishing a TCP connection, both the server and the client generate an initial sequence number from which they will start counting the bytes transmitted. This sequence number is (should be) generated at random, and should be hard to predict. However, some implementations of the TCP/IP protocol make it rather easy to predict this sequence number. The attacker either sniffs the current SEQ/ACK of the connection, or can algorithmically predict them. For more on this, read [CERT CA-2001-09].
The TCP protocol uses a 3-way handshake between the two parties to start a connection. The client starts the process by sending a SYN packet to synchronize communication. The server host then sends one of two answers, using the its initial sequence number, back to the client: (i) a RST packet resets the connection, thus refusing the request for service, (ii) while an ACK packet acknowledges the request and awaits the client's first packet.
A connection is typically ended as follows. The TCP flag FIN indicates "no more data from sender". This flag is used when closing a connection down the normal way. The receiving host enters the CLOSEWAIT state and starts the process of gracefully closing the connection. Each end of the connection sends a packet with the FIN flag. The receiver is expected to acknowledge a received FIN packet by sending a FIN packet. So four packets are used to close a TCP connection.
Closing a connection can also be done by using the RST flag. The RST flag of a TCP packet of a sender indicates to the receiver that a reset should occur. The receiving host enters the CLOSED state and frees resources associated with this instance of the connection. The RST packet is not acknowledged. Any new incoming packets for that connection will be dropped. The receiver accepts the RST packet provided the sequence number is correct.
When the TCP protocol was initially released, there was no limit set on the wait after receiving the SYN. Once a TCP session begins (i.e., after the ACK packet comes in) each TCP packet has a timeout. If a packet takes too long, it times out, and eventually, the connection itself will time out, but because of the way the state transition diagrams were specified so many years ago, in this particular state of opening the connection, there are no timeouts.
SYN flooding takes advantage of a flaw in how most hosts implement the three-way handshake. When a host YY receives the SYN request from XX, it must keep track of the partially opened connection in a "listen queue" for several (e.g., 75) seconds. This is to allow for successful connections even with long network delays. On the other hand, implementations can only keep track of a limited number of connections. An attacker may initiate many connection requests with spoofed source addresses to the victim machine. That causes victim machine to allocate resources to handle these requests. The SYN+ACK packet replies of the victim host are ignored by the attacker. Once a set limit of such half-open connections is reached, the victim host will refuse all successive connection establishment attempts regardless of whether they are originating from genuinely addressed hosts, until a partially opened connection in the queue is completed or times out. This ability to effectively remove a host from the network for at least 75 seconds can be used solely as a denial-of-service attack, or it can be used as a tool to implement other attacks. Note that neither outgoing connection attempts nor connections that are already established are affected by this attack.
Suppose ZZ initiates a connection to YY but spoofs as though the packet is from XX. This is the first packet (SYN connection init) of the three-way TCP handshake. YY replies with the second packet of the handshake, and will now wait for response from host XX. If the spoofer sends a packet to the server, the server will send an acknowledgement back to the "real" client. If host XX is reachable, there is no easy way for ZZ to prevent the packet from reaching XX. This real client does not know what to do with this ACK. XX will tell host YY (with a RST) that it did not initiate a connection. YY concludes it received a bogus packet, and will ignore the SYN, and normally nothing more will happen with XX. Remember that YY is wholly unaware of ZZ. So, the spoofer may try to flood the real client XX with dummy packets at such a rate that its buffers will overflow, and the ACK from the server YY will be lost.
But suppose host XX is turned off, ZZ some how observed this, and chose to impersonate XX. Or that the spoofed source IP address that ZZ used looks legitimate but is not assigned to any real host. So if XX is unreachable, YY has a rather long wait for the third packet of the handshake.
Also there is no explicit specification in TCP for the number of simultaneous channels permitted on a given port. The vast majority of systems in the Internet allow upto 1024 simultaneous sessions. Suppose an attacker sends 1024 packets to such a computer at port 80, say, with the SYN bit set, and spoofing the source address so that each packet has a different source host number. After receving these 1024 packets, the target system will stop listening to that port. Note that such a packet is only about 40 bytes long, so the total amount of traffic is only 40,960 bytes, taking a few seconds on a modem, or about 1/20 of a second on T1. That is, one second's worth of packets results in a system hang. Many systems probably run out of internal space to store the uncompleted connections before the second passes and crash.
This TCP design bug cannot be fixed at the router or using some add-on product. The only real fix is to modify operating systems so that it times out on incomplete TCP sessions.
Occasionally, it is possible that hosts XX and YY both wish to establish a connection and both of them simultaneously initiate the handshake. This is called simultaneous connection establishment. Both hosts XX and YY send out SYN's to each other. When the SYN's are received, each receiver sends out a SYN+ACK. Both hosts XX and YY must detect that the SYN and SYN+ACK actually refer to the same connection. If both hosts XX and YY detect that the SYN+ACK belongs to the SYN that was recently sent, they switch off the connection establishment timer and move directly to the SYN_RECVD state. This flaw could be used to stall a port on a host, using protocols such as FTP where the server initiates a connection to the client.
As an example, consider (malicious) host XX which has started an (active) FTP connection to a server YY. XX and YY are connected using the control-port 21 on YY. YY initiates the connection establishment procedure to initiate data transfer with XX.
XX was able to create a denial-of-service attack.
The TCP specification does not specify clearly certain transitions. As an example, suppose an attacker sends a TCP segment with both the SYN and the FIN bit set. Depending on the TCP implementation, victim host processes the SYN flag first, generates a reply packet with the corresponding ACK flag set, and perform a state-transition to the state SYN_RCVD. Victim host then processes the FIN flag, performs a transition to the state CLOSE_WAIT, and sends the ACK packet back to attacker. The attacking host does not send any other packet to victim. TCP state machine in the victim for this connection is in CLOSE_WAIT state. The victim connection gets stuck in this state until the expiry of the keep-alive timer.
In TCP/IP, there are a number of methods through which data can be surreptitiously passed between hosts. That is, the "real data payload" is not located in the data field (following the first 24 bytes of the TCP header).
A number of fields in the TCP/IP header are unused or optional, and these can be used for covert data transmission. However, it is likely that various filters along the way strip or modify this data. So, for reliable covert operation an attacker uses the mandatory fields: The IP packet identification field, SYN, and ACK. The basis of the exploitation relies in encoding ASCII values of the range 0-255 into these areas. Using this method it is possible to pass data between hosts in packets that appear to be initial connection requests, established data streams, or other intermediate steps. These packets either contain no actual data, or contain data designed to look innocent. Typically they can also contain forged source and destination IP addresses as well as forged source and destination ports. This can be useful for tunneling information past some types of packet filters. Additionally, forged packets can be used to initiate an anonymous TCP/IP "bounced packet network" whereby packets between systems can be relayed off legitimate sites to thwart tracking by sniffers and other network monitoring devices. These techniques will be described below.
IP packets can get fragmented along the route from the source to the destination because of different MTRs of different segments. All fragments that originally belonged to an IP packet are given the same IP id field number so that all the fragments can be identified and assembled back into a whole packet. As long as this purpose is served, the specific choice made for the value does not matter.
*The first encoding method simply replaces the IP identification field with the numerical ASCII representation of the character to be encoded. This allows for easy transmission to a remote host which simply reads the IP identification field and translates the encoded ASCII value to its printable counterpart. The lines below show a tcpdump(8) representation of the packets on a network between two hosts "nemesis.psionic.com" and "blast.psionic.com." A coded message consisting of the letters "HELLO" was sent between the two hosts in packets appearing to be destined for the WWW server on blast.psionic.com. The actual packet data does not matter.
The field in question is the IP portion of the packet called the "id" field located in the parenthesis. Note that the ID field is represented by an unsigned integer during the packet generation process of the included program. This program does not perform any type of byte ordering functions normally used in this process, therefore packet data is converted to the ASCII equivalent by dividing by 256.
Packet One:
18:50:13.551117 nemesis.psionic.com.7180 > blast.psionic.com.www: S 537657344:537657344(0) win 512 (ttl 64, id 18432)
Decoding:...(ttl 64, id 18432/256) [ASCII: 72(H)]
Packet Two:
18:50:14.551117 nemesis.psionic.com.51727 > blast.psionic.com.www: S1393295360:1393295360(0) win 512 (ttl 64, id 17664)
Decoding:...(ttl 64, id 17664/256) [ASCII: 69(E)]
Packet Three:
18:50:15.551117 nemesis.psionic.com.9473 > blast.psionic.com.www: S 3994419200:3994419200(0) win 512 (ttl 64, id 19456)
Decoding:...(ttl 64, id 19456/256) [ASCII: 76(L)]
Packet Four:
18:50:16.551117 nemesis.psionic.com.56855 > blast.psionic.com.www: S3676635136:3676635136(0) win 512 (ttl 64, id 19456)
Decoding:...(ttl 64, id 19456/256) [ASCII: 76(L)]
Packet Five:
18:50:17.551117 nemesis.psionic.com.1280 > blast.psionic.com.www: S 774242304:774242304(0) win 512 (ttl 64, id 20224)
Decoding:...(ttl 64, id 20224/256) [ASCII: 79(O)]
Packet Six:
18:50:18.551117 nemesis.psionic.com.21004 > blast.psionic.com.www: S3843751936:3843751936(0) win 512 (ttl 64, id 2560)
Decoding:...(ttl 64, id 2560/256) [ASCII: 10(Carriage Return)]
This method is used by having the client host construct a packet with the appropriate destination host and source host information and encoded IP ID field. This packet is sent to the remote host which is listening on a passive socket which decodes the data.
This method is relatively straightforward and easy to implement as shown in the included program: covert_tcp. The reader should note that this method relies on manipulation of the IP header information, and may be more susceptible to packet filtering and network address translation where the header information may re-written in transit especially if located behind a firewall. If this happens, loss of the encoded data may occur.
The sequence number field is a 32-bit number, bytes 4-7, of the TCP header. One can generate the initial sequence number from the characters we wish to covertly send.
This is the method used by covert_tcp as shown in the following packets (The "S" indicates a synchronize packet with the 10 digit number following being the sequence number being sent). Again, no byte ordering functions are used by covert_tcp to generate the sequence numbers. This enables a more "realistic" looking sequence number. Therefore in our example the sequence numbers are converted to ASCII by dividing by 16777216 which is a representation of 65536*256.
Again our message of HELLO is being sent:
Packet One:
18:50:29.071117 nemesis.psionic.com.45321 > blast.psionic.com.www: S 1207959552:1207959552(0) win 512 (ttl 64, id 49408)
Decoding:... S 1207959552/16777216 [ASCII: 72(H)]
Packet Two:
18:50:30.071117 nemesis.psionic.com.65292 > blast.psionic.com.www: S 1157627904:1157627904(0) win 512 (ttl 64, id 47616)
Decoding:... S 1157627904/16777216 [ASCII: 69(E)]
Packet Three:
18:50:31.071117 nemesis.psionic.com.25120 > blast.psionic.com.www: S 1275068416:1275068416(0) win 512 (ttl 64, id 41984)
Decoding:... S 1275068416/16777216 [ASCII: 76(L)]
Packet Four:
18:50:32.071117 nemesis.psionic.com.13603 > blast.psionic.com.www: S 1275068416:1275068416(0) win 512 (ttl 64, id 7936)
Decoding:... S 1275068416/16777216 [ASCII: 76(L)]
Packet Five:
18:50:33.071117 nemesis.psionic.com.45830 > blast.psionic.com.www: S 1325400064:1325400064(0) win 512 (ttl 64, id 3072)
Decoding:... S 1325400064/16777216 [ASCII: 79(O)]
Packet Six:
18:50:34.071117 nemesis.psionic.com.64535 > blast.psionic.com.www: S 167772160:167772160(0) win 512 (ttl 64, id 54528)
Decoding:... S 167772160/16777216 [ASCII: 10(Carriage Return)]
Because of the sheer amount of information one can represent in a 32 bit address space (4,294,967,296 numbers), the sequence number makes an ideal location for storing data. Aside from the obvious example given above, one can use a number of other techniques to store information in either a byte fashion, or as bits of information represented through careful manipulation of the sequence number. The simple algorithm of the covert_tcp program takes the ASCII value of our data and converts it to a usable sequence number (which is actually done by the packet generation functions and is converted back to ASCII in a symmetrical manner). Note that this method (as well as the other methods in this paper) are similar to a "substitution cipher" whereby packets containing the same information will display the same sequence number (note packets three and four which contain the letter "L" in the encoding and their sequence numbers). Methods that incorporate a random number generation of the sequence number with a subsequent inclusion of the data to be encoded through an XOR or similar operation may yield a more random result. Inclusion of encrypted data to perform the same function is a logical extension to this idea.
This method relies upon basic spoofing of IP addresses to enable a sending machine to "bounce" a packet of information off of a remote site and have that site return the packet to the real destination address. This has the benefit of concealing the sender of the packet as it appears to come from the "bounce" host. This method could be used to set up an anonymous one-way communication network that would be difficult to detect especially if the bounce server is very busy.
This method relies on the characteristic of TCP/IP where the destination server responds to an initial connect request (SYN packet) with a SYN/ACK packet containing the original initial sequence number plus one (ISN+1). In this method, the sender constructs a packet that contains the following information:
- Forged SOURCE IP address.
- Forged SOURCE port.
- Forged DESTINATION IP address.
- Forged DESTINATION port.
- TCP SYN number with encoded data.
The source and destination ports chosen do not matter (except if you want to conceal the traffic as a well known service such as HTTP and/or you are having the receiving server listening for data on a pre-determined port, in which case you will want to forge the source port as well). The DESTINATION IP address should be the server you wish to BOUNCE information off of and the SOURCE IP should be the address of the server you wish to communicate WITH.
The packet is sent from the client's computer system and routed to the forged destination IP address in the header ("bounce server"). The bounce server receives the packet and sends either a SYN/ACK or a SYN/RST depending on the state of the port the packet was destined for on the bounce server. The return packet is sent to the forged source address with the ISN number plus one. The listening destination server takes this incoming packet and decodes the information by transforming the returned sequence number minus one back into the ASCII equivalent. It should be noted that the low order bits are dropped in the translation process of covert_tcp because of the method used to "encode" and "decode" information, so the program does not need to adjust for the incremented SYN packet number.
A step-by-step representation of the bounce method:
- Sending Client: A
- Bounce Server: B
- Receiving Server: C
Step One: Client A sends a forged packet with encoded information to bounce server B. This packet has the address of receiving server C.
Step Two: Bounce server B receives the packet and returns an appropriate SYN/ACK or SYN/RST packet based on the status of the port. Since bounce server B thinks the packet came from receiving server C, the packet is sent to address of receiving server C. The acknowledgment sequence number (which is the encoded sequence number plus one) is sent to server C as well.
Step Three: Server C, expecting to receive a packet from the bounce server B (or a pre-determined port) decodes the data and writes it out to disk.
This method is essentially tricking the remote server into sending the packet and encapsulated data back to the forged source IP address, which it rightfully thinks is legitimate. From the receiving end, the packet appears to originate from the bounced server, and indeed it does. As a side note, if the receiving system is behind a packet filter that only allows communication to certain sites, this method can be used to bounce packets off of the trusted sites which will then relay them to the system behind the packet filter with a legitimate source address. This could be vital in communicating with receiving servers in heavily protected or scrutinized networks.
Bouncing a packet off of a well known Internet site (.mil, .gov, .com, etc.) is also a useful technique for concealing operations in ordinary traffic. Be sure the bounce site is not using round-robin DNS (stable IP address) or if it is, that the receiving server is passively listening on a pre-determined port to decode the transmissions from multiple sites (i.e. send out a forged source address and source port of 1234 so the bounce server returns the packet to the listening server on port 1234). Using this technique, the sending client can bounce packets off of hundreds of Internet hosts while the receiving server listens and writes out any data destined for the pre-defined port number regardless of IP address.
If your network site has a correctly configured router, it may not allow a forged packet with a network number that is not from it's network to traverse outbound. Alas, many routers are not configured with this protection in mind and will happily pass the data so you can generally expect this technique to work.
The covert_tcp program is a simple proof of concept utility written (by Craig H. Rowland). It uses raw sockets to construct forged packets and encapsulate data from a filename given on the command line. The program itself is straightforward and very slow in transmitting of data (about one packet per second). Because covert_tcp is subjugating the TCP/IP protocol for a purpose not designed, the normal reliability modes are non- existent and in essence functions much like UDP. This program does not attempt to provide for any type of flow control or error detection, although these things can be added.
Covert channels could be incorporated into an operating system kernel, or daemon that is set to receive the name of a file and send it.
This section describes a few exploits while they are in progress. The source code of these exploits is downloadable (see the References).
Below, we show the relevant contents of packets sniffed from an attack in progress. XX, YY and ZZ are IP addresses, whose actual byte values are irrelevant here. Assume that the "sniper program" S (on host ZZ) is on the same subnet as XX. YY need not be on the same subnet. The data portion of the packets is often irrelevant, so it is not shown. The SEQ and ACK numbers are in hex. These were obtained by running a sniffer while the attack was in progress.
The attacker (on host ZZ) is sniffing packets in a connection between XX and YY. He (i.e., his sniper program) will calculate, from YY's ACK packets to XX, the sequence number for XX's packets, and fire off a bogus RST packet from ZZ (faking to be XX) to YY.
Here is an actual attack. XX on port 1810 and YY on port 23 are connected for a while.
The attacker constructs a spoofed FIN packet. It will have the correct SEQ number so that it is accepted by the host. This host would believe the (spoofed) sender did not have any data left. Any packets that may follow would be ignored as bogus. Here is an actual attack
YY.1072-XX.23 SEQ: 69C5473E ACK: 19C6B98D FLAGS: -A---- Window: 3750
Host XX has that connection closed by now, and thus thinks the (real) packets of (real) YY are spoofed (or at least bogus)! So host XX sends some RST packets.
XX.23-YY.1072 SEQ: 19C6B98D FLAGS: ---R--
YY trusts the packets from XX because of its correct SEQ/ACK numbers. So if there was a way to mess up XX's SEQ/ACK, YY would ignore XX's real packets. Attacker could then impersonate to be XX, but using correct SEQ/ACK numbers from the perspective of YY. The attacker can confuse XX's SEQ/ACK numbers as seen by YY by simply inserting a data packet into the stream at the right moment (ZZ as XX->YY). YY would accept this data, and update ACK numbers. XX would continue to send it's old SEQ numbers, as it's unaware of our spoofed data. This results in ZZ hijacking the connection: host XX is confused, YY thinks nothing is wrong as ZZ sends 'correct' packets to YY. Each time a packet arrives at YY out of sequence from the real XX, the YY answers it with 'correct' SEQ/ACK.
Here is an actual attack. Not all packets that transpire after step 1 are shown.
hijack XX 1040 YY
The following packet from XX->YY is detected. The data portion of the packets is relevant, so it is shown.
XX.1040-YY.23 SEQ: 5C8223EA ACK: C34A67F6 FLAGS: -AP--- Window: 7C00
XX.1040-YY.23 45 E 00 . 00 . 29 ) CA . F3 . 40 @ 00 . 40 @ 06 . C5 . 0E . 9D .
C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EA . C3
. 4A J 67 g F6 . 50 P 18 . 7C | 00 . 6D m 29 ) 00 . 00 . 6C l
YY.23-XX.1040 SEQ: C34A67F6 ACK: 5C8223EB FLAGS: -AP--- Window: 2238
YY.23-XX.1040; 45 E 00 . 00 . 29 ) B5 . BD . 40 @ 00 . FC . 06 . 1E . 44 D 9D
. C1 . 2A * 0B .; 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F6 .
5C \ 82 . 23 # EB .; 50 P 18 . 22 " 38 8 C6 . F0 . 00 . 00 . 6C l
XX.1040-YY.23 SEQ: 5C8223EB ACK: C34A67F6 FLAGS: -AP--- Window: 7C00
XX.1040-YY.23 45 E 00 . 00 . 32 2 31 1 01 . 00 . 00 . 45 E 06 . 99 . F8 . 9D .
C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EB . C3
. 4A J 67 g F6 . 50 P 18 . 7C | 00 . AE . F5 . 00 . 00 . 08 . 08 . 08 . 08 .
08 . 08 . 08 . 08 . 0A . 0A .
YY.23-XX.1040 SEQ: C34A67F7 ACK: 5C8223F5 FLAGS: -AP--- Window: 2238
YY.23-XX.1040 45 E 00 . 00 . 3C < B5 . BE . 40 @ 00 . FC . 06 . 1E . 30 0 9D .
C1 . 2A * 0B . 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F7 . 5C
\ 82 . 23 # F5 . 50 P 18 . 22 " 38 8 26 & 7C | 00 . 00 . 5E ^ 48 H 5E ^ 48 H
5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 0D . 0A . 0D . 0A
.
Note that ACK = 5C8223F5 = 5C8223EB + 0A. This is how the hijacker detects
success. At this point the connection is controlled by the hijacker, and
the real XX's SEQ/ACK numbers are out of sync with YY. At this
point the real telnet client's session on XX hangs. Most people ignore this as a
network problem and re-login after a while, accepting the disconnection as
Murphy's law. Indeed, connection hangs do happen without any spoofing involved
because of other reasons.
XX.1040-YY.23 SEQ: 5C8223EB ACK: C34A67F7 FLAGS: -AP--- Window: 7C00
YY.23-XX.1040 SEQ: C34A680B ACK: 5C8223F5 FLAGS: -A---- Window: 2238
XX.1040-YY.23 SEQ: 5C8223F5 ACK: C34A680B FLAGS: -AP--- Window: 7C00
XX-YY.23 45 E 00 . 00 . 4D M 31 1 01 . 00 . 00 . 45 E 06 . 99 . DD . 9D . C1 .
45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A
J 68 h 0B . 50 P 18 . 7C | 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20 22
" 65 e 63 c 68 h 6F o 20 48 H 41 A 43 C 4B K 45 E 44 D 22 " 20 3E > 3E > 24 $
48 H 4F O 4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 .
Juggernaut ( http://www.phrack.org/ issue 50) is a network sniffer that can also be used to hijack TCP sessions. Juggernaut can be configured to wait for the login prompt, and then record the network traffic that follows (usually capturing the password). It can maintain a connection database of all the TCP connections made, and possibly "hijack" the session. After a connection is made, the attacker can watch the entire live session. As the session is watched, the attacker can reset, or hijack the connection.
Hunt (search http://packetstormsecurity.org ) is a program for intruding into a TCP connection, watching it and resetting it. It can detect an ongoing connection (not only when SYN started), hijack, detect an ACK storm, ARP spoof, and synchronize the true client with the server after hijacking.
[The following is based on RFC 1948.] The choice of initial sequence numbers for a connection should not be random. Rather, it must be chosen so as to minimize the probability of old stale packets being accepted by new incarnations of the same connection. Furthermore, most implementations of TCP contain special code to deal with such reincarnations when the server end of the original connection is still in TIME-WAIT state. Accordingly, simple randomization will not work well. But duplicate packets, and hence the restrictions on the initial sequence number for reincarnations, are peculiar to individual connections. That is, there is no relationship, syntactic or semantic, between the sequence numbers used for two different connections.
We can prevent sequence number guessing attacks by giving each connection -- that is, each 4-tuple of <local host, local port, remote host, remote port> -- a separate sequence number space. Within each space, the initial sequence number is incremented as usual; however, there is no obvious relationship between the numbering in different spaces.
The obvious way to do this is to maintain state for dead connections, and the easiest way to do that is to change the TCP state transition diagram so that both ends of all connections go to TIME-WAIT state. That would work, but it is inelegant and consumes storage space. Instead, we use the current four-microsecond timer M and set
ISN = M + F(local host, local port, remote host, remote port).
It is vital that F not be computable from the outside, or an attacker could still guess at sequence numbers from the initial sequence number used for some other connection. We therefore suggest that F be a cryptographic hash function of the connection-id and some secret data. MD5 [9] is a good choice, since the code is widely available. The secret data can either be a true random number [10], or it can be the combination of some per-host secret and the boot time of the machine. The boot time is included to ensure that the secret is changed on occasion. Other data, such as the host's IP address and name, may be included in the hash as well; this eases administration by permitting a network of workstations to share the same secret data while still giving them separate sequence number spaces. Our recommendation, in fact, is to use all three of these items: as random a number as the hardware can generate, an administratively- installed pass phrase, and the machine's IP address. This allows for local choice on how secure the secret is. Note that the secret cannot easily be changed on a live machine. Doing so would change the initial sequence numbers used for reincarnated connections; to maintain safety, either dead connection state must be kept or a quiet time observed for two maximum segment lifetimes after such a change.
The IP that is widely in use currently is IPv4 even though IPsec and IPv6 implementations are available for all popular OS. IPv6 improves the security of IP substantially compared to IPv4. However, there are no such widely agreed upon extensions for TCP. There exist only experimental suggestions from researchers.
The Secure-TCP protocol was proposed in 1995 as an extension to the current TCP. It provides secure service negotiation, the key exchange for encryption and TCP segment encryption.
All work should be carried out in Operating Systems and Internet Security (OSIS) Lab, 429 Russ. Use any of the PCs numbered 19 to 30. No other WSU facilities are allowed.
Objective: Run the TCP exploit programs (sniper-fin, sniper-rst, and hijack) based on the above with a goal of learning how the attack actually works in detail. Observe the details of the packets being transmitted using a sniffer. Capture sequences of packets to and fro and explain how the specific attack worked. Examine the source code of sniper-fin, sniper-rst, and hijackprograms both because you need to learn to invoke them, and because a later assignment may/ will use the source code.
Recent distributions of Linux are not installing the telnet service by default. Rather than trying to install the binary packages that will have specific library dependencies, it is better to to compile and install telnetd, et al. The following is a link to a local copy of the source that Debian (and its derivatives Ubuntu, Knoppix and BackTrack) uses: inetutils_1.8.orig.tar.gz. Build it as usual; that is: untar, configure, and make. This tar ball provides telnet ifconfig ping telnetd ftp libinetutils/ talk whois ftpd talkd.
Most of the material in this lecture is based on articles by Brecht Claerhout and Craig H. Rowland.
This work was supported in part by NSF DUE-9951380.