TCP Exploits

1. TCP Exploits

2. We will discuss several exploits based on the design weaknesses of TCP. • UDP • Connectionless. • Header is simple. • Fake a UDP packet is easy. • TCP • Connection based. • More complicated header with sequence number. • Fake a TCP packet is more difficult.

3. Revision of TCP/IP Architecture • In the time that it took to develop the OSI protocol standards, the TCP/IP network architecture emerged as an alternative for OSI. • The free distribution of TCP/IP as part ensured the development of numerous applications.

4. Application Layer • Application layer programs are intended to run directly over the transport layer, • Two basic types of services are offered in the transport layer. • Transmission control protocol (TCP) • Reliable connection-oriented transfer of a byte stream • User datagram protocol (UDP) • Best-effort connectionless transfer • No error recovery or flow control. Transport Layer Internet Layer Network Interface Fig2.10(a)

5. Application Layer • The TCP/IP model does not require strict layering. • Application layer has the option of bypassing intermediate layers. Transport Layer Internet Layer Network Interface (b)

6. Application Application TCP UDP ICMP IP ARP RARP Physical network Figure 8.1

7. HTTP Request Header contains source and destination port numbers TCP Header Header contains: source and destination IP addresses; transport protocol type IP Header Header contains: source and destination physical addresses; network protocol type FCS Ethernet Header Figure 8.2

8. Application Transport Internet Internet Network Interface Network Interface Machine B Machine A Application Transport Router/Gateway Internet Network Interface Network 1 Network 2 • Internet layer handles the transfer of information across multiple networks.

9. A key aspect of the internet layer is the definition of globally unique addresses. • Provides a best-effort connectionless packet transfer. • Packets are routed independently. • IP packets are also called datagrams. • The responsibility for recovery from these losses is passed on to the transport layer.

10. User Datagram Protocol • Unreliable, connectionless transport layer protocol. • Provides only two additional services beyond IP: • Demultiplexing • IP knows how to deliver packets to a host, but does not know how to deliver them to the specific application. • UDP adds a mechanism that distinguishes among multiple applications. • Error checking • IP checks only the integrity of its header. • UDP can optionally check the integrity of the entire UDP datagram.

11. Applications that uses UDP include • Trivial File Transfer Protocol. • DNS • SNMP • RTP 0 16 31 Source Port Destination Port UDP Length UDP Checksum Data

12. 0 8 16 31 Source IP Address Destination IP Address 0 0 0 0 0 0 0 0 Protocol = 17 UDP Length UDP pseudoheader: added to the beginning of the datagram when performing checksum computation and is not transmitted. Figure 8.17

13. Transmission Control Protocol • Provides a logical full-duplex connection between two application layer processes across a datagram network. • Before data transfer, TCP establishes a connection between the two application processes by setting up variables that are used in the protocol. • The variables are stored in the Transmission control block (TCB). • TCP operates over IP and does not assume that the underlying network service is reliable.

14. TCP uses a form of Selective Repeat ARQ to implement reliability. • TCP terminates each direction of the connection independently. • TCP does not preserve message boundaries and treats the data it gets from the application layer as a byte stream. • E.g. when we send 1000 bytes in a single chunk (one write), the destination may receive the message in two chunks of 500 bytes, in three chunk of 400 bytes, 300 bytes and 300 bytes, or any other combination.

15. TCP operation Application Application byte stream byte stream segments Transmitter Receiver Send buffer Receive buffer ACKs

16. TCP was designed to deliver a connection-oriented service in an internet environment, which itself offers connectionless packet transfer server. • Different packets can traverse a different path from the same source to the same destination. • Packet can arrive out of order. • In the internet old messages from previous connections may arrive at a receiver, thus complicating the task of eliminating duplicate messages.

17. TCP uses long (32 bits) sequence numbers and by establishing randomly selected initial sequence numbers during connection setup. • Next sequence number = current sequence number + length of data. • The receiver is accepting sequence numbers from a much smaller window, so the likelihood of accepting a very old message is very low. • TCP uses a sliding-window mechanism, as shown in Fig. 8.19

18. Transmitter Receiver Send Window Receive Window Slast+Wa-1 Rlast+WR+1 Rlast ... ... ... Rnext Rnew Octets transmitted and ACKed Slast Srecent Slast+Ws-1 Slast oldest unacknowledged octet Srecent highest-numbered transmitted octet Slast+Wa-1 highest-numbered octet that can be transmitted Slast+Ws-1 highest-numbered octet that can be accepted from the application Rlast highest-numbered octet not yet read by the application Rnext next expected octet Rnew highest numbered octet received correctly Rlast+WR-1 highest-numbered octet that can be accommodated in receive buffer Figure 8.19

19. Rnew can be greater than Rnext because the receiver will accept out-of-sequence error-free bytes. • The transmitter arranges a consecutive string of bytes into a PDU that is called a segment. • The segment contains a sequence number which corresponds to the number of the first byte in the string that is being transmitted. • The transmitter decides to transmit a segment when the number of bytes in the send buffer exceeds some specified threshold or when a timer expires.

20. The sending applications can also use a push command to forces the transmitter to send a segment. • When a segment arrives • If it is error free and is not a duplicate segment, the bytes will be inserted into the appropriate locations in the receive buffer. • The receiver will accept out-of-order error-free segment. • If the segment contains the byte corresponding to Rnext the Rnext pointer will be moved forward to the location of the next byte that has not yet been received. • The ACK with sequence number Rnext is sent.

21. The flow control function is implemented through an advertised window field in the segment header. • The advertised window size is given by • The transmitter is obliged to keep the number of outstanding bytes below the advertised window size • The round-trip time is estimated continuously.

22. 0 4 10 16 24 31 Source Port Destination Port Sequence Number Acknowledgement Number U A P R S F Header R C S S Y I Reserved Window Size Length G K H T N N Checksum Urgent Pointer Options Padding Data Figure 8.20

23. 0 8 16 31 Source IP Address Destination IP Address 0 0 0 0 0 0 0 0 Protocol = 6 TCP Segment Length TCP pseudoheader: added to the beginning of the segment When performing the checksum computation. The Pseudoheader is created by the source and destination hosts during the checksum computation and is not transmitted. This mechanism ensures the receiver that the segment has Indeed reached the correct destination. Figure 8.21

24. Connection Killing • A,B have a TCP connection running • A,S are on the same subnet Host A Host B Host S

25. Using reset RST • TCP packets have flags which indicate the status of the packet. • RST: used to reset a connection • A packet is accepted only when the sequence number is correct. • Idea • Wait for packets in a connection between A and B. • Calculate the sequence number for A’s packets from B’s ACK’s • Fire a bogus packet from S (faking to be A) to B.

26. Case Study • Study the code in sniper-rst.c • In the class I will demonstrate the RST attack. • We will capture and study the packets for the attack by using Ethereal.

27. Actual attack (from the paper): • Attacker S waits for a packet to get current SEQ/ACK. Several packets, as seen by S, are shown below. S is ready to send his RST after the packets.

28. The attacker sends off to A his RST packets, with source forged as B. • In the particular attack, 2 RST packets was sent. • The first RST packet has been buffered somewhere on the system, because the Ethernet segment was busy. • The second RST packet actually kill the connection.

29. Closing a connection by FIN • FIN flag: indicate “no more data from sender”. • used when closing a connection down in a normal way. • Idea • The attacker constructs a spoofed FIN packet. • The packet must contain the correct sequence number, so that it will be accepted by one of the two hosts. • The host which accepted the packet would believe the (spoofed) sender did not have any data left. • Following (real) packets would be ignored as they are considered bogus.

30. As in the RST attack, a sniffer is used to find out the expected sequence number. • The “beauty” of FIN attack is that after a FIN is send, the other host always replies if it is accepted. • The attacker can verify that his killing is success.

31. Four-way handshaking for terminating a connectionnormally.

32. Case Study • Study the code in sniper-fin.c • In the class I will demonstrate the FIN attack. • We will capture and study the packets for the attack by using Ethereal.

33. Actual attack (from the paper) • Connection between A and B is running. • A sniper is started on host S. • Wait for a packet to take action • Plus two bytes data.

34. Sniper detected it, and sends a bogus packet (S as B  A) • Set SEQ and ACK of the above packet. • Sniper calculates his ACK as SEQ of the above packet + data length of that packet = 19C6B98B + 2 = 19C6B98D. • This packet, in fact, telling A that B received the last packet, and will not transmit further data.

35. Host A says: “Okay, you end the session, so here is my last data (A B). • Host A now has flushed its buffer and on his turn Fin’s the connection (AB). • Sniper intercepts this packet and now knows the hosts fell for the spoof and the killing success.

36. The attacker impersonated B, making A believe B had no further data. But B doesn’t know that and keep sending data

37. Host A has that connection closed, and thus thinks the real packets of B are spoofed (or at least bogus). So host A sends some RST packets. • This goes on for a couple of packets.

38. Connection Hijacking • A,B have a TCP connection running (Telnet) • A,S are on the same subnet Host A Host B Host S

39. TCP separates good and bogus packets by their SEQ/ACK numbers. • B trusts the packets from A because of its correct SEQ/ACK numbers. • If there was a way to mess up A’s SEQ/ACK, B would stop believing A’ real packets. • S could then impersonate to be A, but using correct SEQ/ACK numbers from the perspective of B. • S would now have taken over the connection, and sends “correct” data to B.

40. This is called hijacking the connection • The same technique can be applied to hijack TELNET, FTP, RLOGIN etc. • How could we mess up A’s SEQ/ACK numbers? • Simply inserting a data packet into the stream at the right time (S as A B). • B would accept this data, and update ACK number. • A would continue to send it’s old SEQ numbers, as it’s unaware of our spoofed data.

41. Case Study • Study the code in hijack.c • In the class I will demonstrate a telnet hijack. • We will capture and study the packets for the attack by using Ethereal.

42. Actual Attack (from the paper) • Attacker examines with a sniffer • Sees the port number 2035 • User is in an interactive shell via telnet • He starts hijack • The following packet from A to B is detected TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EA ACK (hex): C34A67F6 FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.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 ~~~~

43. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A67F6 ACK (hex): 5C8223EB FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.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 ~~~~ • B echoes that data bytes (“l”) • A acknowledges TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -A---- Window: 7C00 (data removed because irrelevant)

44. Hacker’s program impersonates A with further data to B. • Calculate SYN/ACK base on packet 1. • Sends a few backspaces (0x08) and some enters (0x0A) to clean up the command line. • May generate some error messages, but the program will handle it. TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F6 FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.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 .

45. Here is the echo of the spoofed data from B • ACK = 5C8223F5 = 5C8223EB + 0A • The connection belongs to the hacker now • The SEQ/ACK of A is completely messed up. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A67F7 ACK (hex): 5C8223F5 FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.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 .

46. Hijack will now try to get on track of SEQ/ACK. • Send data that the hacker wants to execute. • Note: each time a packet ‘out of number’ arrives a host, the host should answer with correct SEQ/ACK. • This provides the hacker with certainty that a lot of packets are going to be sent with correct (and not changing) SEQ/ACJ numbers. • At this point the real TELNET client’s session hangs, most people ignore this and re-login after a few secs.

47. TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -AP--- Window: 7C00 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C8223F5 FLAGS: -A---- Window: 2238 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-157.193.42.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -AP--- Window: 7C00 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C8223F5 FLAGS: -A---- Window: 2238 (data removed because irrelevant)

48. The hacker fire off the faked bash command Echo “echo HACKED” >> $HOME/.profile<ENTER> TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223F5 ACK (hex): C34A680B FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1-111.11.11.11.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 .

49. Now wait for this data to be confirmed • ACK = 5C8223F5 + 025 (37 bytes) • The connection runs on. • Now the hacker can execute more command • Or finish the connection. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C82241A FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 157.193.42.11.23-157.193.69.63.1040 (data removed because irrelevant)

50. SYN Flooding • When the TCP was designed, there was no limit set on the wait after receiving the SYN. • Once a TCP session begins (I.e., after the next 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. • Because of the way the state transition diagrams were specified so may years ago, in this particular state of opening the connection, there are no timeouts.