Download Document

TCP Exploits
• 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.
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.
Application
Layer
Transport
Layer
Internet
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)
Network
Interface
Fig2.10(a)
– Reliable connection-oriented transfer of a
byte stream
• User datagram protocol (UDP)
– Best-effort connectionless transfer
– No error recovery or flow control.
Application
Layer
Transport
Layer
Internet
Layer
Network
Interface
(b)
– The TCP/IP model does not
require strict layering.
– Application layer has the
option of bypassing
intermediate layers.
Application
Application
TCP
UDP
ICMP
IP
ARP
RARP
Physical
network
Figure 8.1
HTTP Request
Header contains source and
destination port numbers
Header contains:
source and destination
IP addresses; transport
protocol type
Header contains:
source and destination
Ethernet
physical addresses;
network protocol type Header
TCP
Header
IP
Header
FCS
Figure 8.2
Machine B
Machine A
Application
Application
Transport
Router/Gateway
Transport
Internet
Internet
Internet
Network Interface
Network Interface
Network 1
Network Interface
Network 2
Internet layer handles the transfer of information
across multiple networks.
– 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.
• 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.
– Applications that uses UDP include
•
•
•
•
Trivial File Transfer Protocol.
DNS
SNMP
RTP
0
16
31
Source Port
Destination Port
UDP Length
UDP Checksum
Data
0
8
16
31
Source IP Address
Destination IP Address
00000000
Protocol = 17
UDP Length
UDP pseudoheader: added to the beginning of the datagram
when performing checksum computation and is not transmitted.
Figure 8.17
• 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.
– 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.
• TCP operation
Application
Application
byte stream
byte stream
segments
Transmitter
Receiver
Send buffer
Receive buffer
ACKs
– TCP was designed to deliver a connectionoriented 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.
– 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
Transmitter
Receiver
Send Window
Receive Window
Slast+Wa-1
...
Octets
transmitted Slast
and ACKed
...
Srecent
Rlast
Rlast+WR+1
...
Rnext Rnew
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
– 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.
– 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.
– The flow control function is implemented
through an advertised window field in the
segment header.
– The advertised window size is given by
WA  WR  ( Rnew  Rlast )
– The transmitter is obliged to keep the number
of outstanding bytes below the advertised
window size
S recent  Slast  WA
– The round-trip time is estimated continuously.
0
4
10
16
Source Port
24
31
Destination Port
Sequence Number
Acknowledgement Number
Header
Length
Reserved
UAP R S F
R C S S Y I
GKH T NN
Checksum
Window Size
Urgent Pointer
Options
Padding
Data
Figure 8.20
0
8
16
31
Source IP Address
Destination IP Address
00000000
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
Connection Killing
Host A
Host B
Host S
• A,B have a TCP connection running
• A,S are on the same subnet
• 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.
• 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.
• 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.
From
To
SEQ
ACK
Flags
Window
A
B
57E1F2A6
B8BD7679
AP
3400
B
A
B8BD7679
57E1F2A8
AP
2238
A
B
57E1F2A8
B8BD767B
A
3400
B
A
B8BD767B
57E1F2A8
AP
2238
A
B
57E1F2A8
B8BD7691
A
3400
– 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.
From
To
SEQ
ACK
Flags
B
A
B8BD7679
R
B
A
B8BD7691
R
Window
• 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.
• 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.
Four-way handshaking for terminating
a connection normally.
• 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.
• 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
From
To
SEQ
ACK
Flags
Window
A
B
19C6B98B
69C5473E
AP
3400
– Plus two bytes data.
– 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.
From
To
SEQ
ACK
Flags
Window
B
A
69C5473E
19C6B98D
AF
7C00
– This packet, in fact, telling A that B received
the last packet, and will not transmit further
data.
– Host A says: “Okay, you end the session, so
here is my last data (A B).
From
To
SEQ
ACK
Flags
Window
A
B
19C6B98D
69C5473E
AP
3400
A
B
19C6B998
69C5473F
A
3400
– 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.
From
To
SEQ
ACK
Flags
Window
A
B
19C6B998
69C5473F
AF
3400
– The attacker impersonated B, making A believe
B had no further data. But B doesn’t know that
and keep sending data
From
To
SEQ
ACK
Flags
Window
B
A
69C5473E
19C6B98D
A
3750
– 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.
From
To
SEQ
A
B
19C6B98D
ACK
Flags
R
– This goes on for a couple of packets.
Window
• Connection Hijacking
Host A
Host B
Host S
• A,B have a TCP connection running
(Telnet)
• A,S are on the same subnet
– 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.
– 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.
• 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.
• 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
~~~~
– B echoes that data bytes (“l”)
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
~~~~
– 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)
• 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 .
– 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 .
– 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.
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)
– 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
9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A J 68
50 P 18 . 7C | 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20
22 " 65
68 h 6F o 20
48 H 41 A 43 C 4B K 45 E 44 D 22 " 20
3E > 3E > 24 $ 48
4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 .
E
h
e
H
3F
0B
63
4F
?
.
c
O
– Now wait for this data to be confirmed
• ACK = 5C8223F5 + 025 (37 bytes)
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)
– The connection runs on.
– Now the hacker can execute more command
– Or finish the connection.
• 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.
Connection Establishment
Host A
Host B
Figure 8.22
Figure 12-24
– If during a connection establishment phase, one
of the hosts decides to refuse a connection
request, it will send a reset segment by setting
the RST bit.
– The three-way handshake procedure ensures
that both endpoints agree on their initial
sequence numbers.
– Suppose S initiates a connection to B but
impersonates as though the packet is from A.
– This is the first packet (SYN connection init) of
the three-way TCP handshake.
– B replies with the 2nd packet of the handshake,
and will not wait for response from host A.
– If host A is reachable, there is no easy way for
S to prevent the packet from reaching A.
• This real client does not know what to do with this
ACK.
• Properly, A will tell B (with a RST) that it did not
initiate a connection.
• B concludes it received a bogus packet, and will
ignore the SYN, and normally nothing more will
happen with A.
• Some spoofers may try to flood the real client A
with dummy packets at such a rate that its buffers
will overflow, and the ACK from the server will be
lost.
– Now suppose host A is turned off or the
spoofed source IP address that S used looks
legitimate but is not assigned to any real host.
• If A is unreachable, B has a rather long wait for the
3rd 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 with the SYN bit set to port 80,say.
• Spoofing the source address so that each packet has
a different source host number.
– After receiving these 1024 packets, the target
system will stop listening to that port.
– Note that such a packet is about 40 bytes long,
so the total amount of traffic is only 40960
bytes.
• A few seconds on a modem.
• 1/20 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 uncompleted TCP
sessions.
– As of June 2000, we do know of such OS fixes
for all major OS including Linux and Windows
NT.
Prevention
• Not allow hackers to access your network
system.
• Encryption
– E.g. use SSH, SFTP, etc
– Even if a hacker hijacked your session, he/she
cannot execute any command easily.
Reference
• Brecht Claerhout, “A short overview of IP
spoofing: Part I”. This paper can be found
in many web archives, but does not seem to
be published formally.
• The three programs, namely, sniper-rst.c,
sniper-fin.c, and hijack.c are extracted from
this paper.