iphijack, ebooks, ebooks komputerowe, Hackers Black Book, Hackers Black Book, text
[ Pobierz całość w formacie PDF ]
Simple Active Attack Against TCP
Laurent Joncheray
Merit Network, Inc.
4251 Plymouth Road, Suite C
Ann Arbor, MI 48105, USA
Phone: +1 (313) 936 2065
Fax: +1 (313) 747 3185
E-mail: lpj@merit.edu
Abstract
This paper describes an active attack against the Transport
Control Protocol (TCP) which allows a cracker to redirect the TCP
stream through his machine thereby permitting him to bypass the protection
offered by such a system as a one-time password [skey] or
ticketing authentication [kerberos]. The TCP connection is
vulnerable to anyone with a TCP packet sniffer and generator located on
the path followed by the connection. Some schemes to detect this
attack are presented as well as some methods of prevention and some
interesting details of the TCP protocol behaviors.
1. Introduction
Passive attacks using sniffers are becoming more and more
frequent on the Internet. The attacker obtains a user id and password
that allows him to logon as that user. In order to prevent such attacks
people have been using identification schemes such as one-time password
[skey] or ticketing identification [kerberos]. Though
they prevent password sniffing on an unsecure network these methods
are still vulnerable to an active attack as long as they neither
encrypt nor sign the data stream. [Kerberos also provides an
encrypted TCP stream option.] Still many people are complacent believing
that active attacks are very difficult and hence a lesser risk.
The following paper describes an extremely simple active attack
which has been successfully used to break into Unix hosts and
which can be done with the same resources as for a passive sniffing
attack. [The attacks have been performed with a test software
and the users were aware of the attack. Although we do not have any
knowledge of such an attack being used on the Internet, it may
be possible.] Some uncommon behaviors of the TCP protocol are also
presented as well as some real examples and statistical studies of the
attack's impact on the network. Finally some detection and prevention
schemes are explained. In order to help any reader unfamiliar with the
subtleties of the TCP protocol the article starts with a short
description of TCP.
The reader can also refers to another attack by R. Morris
presented in [morris85]. Though the following attack is related
to Morris' one, it is more widely usable on any TCP connection.
In section 7 we present and compare this attack with
the present one.
The presentation of the attack will be divided into three parts:
the ``Established State'' which is the state where the session is open
and data is exchanged; the set up (or opening) of such a session; and
finally some real examples.
2. Established State
2.1 The TCP protocol
This section offers a short description of the TCP protocol.
For more details the reader can refer to [rfc793]. TCP provides a
full duplex reliable stream connection between two end points. A
connection is uniquely defined by the quadruple (IP address of sender,
TCP port number of the sender, IP address of the receiver, TCP port
number of the receiver). Every byte that is sent by a host is marked with a
sequence number (32 bits integer) and is acknowledged by the receiver
using this sequence number. The sequence number for the first byte sent
is computed during the connection opening. It changes for any new
connection based on rules designed to avoid reuse of the same sequence
number for two different sessions of a TCP connection.
We shall assume in this document that one point of the
connection acts as a server (for instance a telnet server) and the
other as the client. The following terms will be used:
SVR_SEQ: sequence number of the next byte to be sent
by the server;
SVR_ACK: next byte to be received by the server
(the sequence number of the last byte received plus one);
SVR_WIND: server's receive window;
CLT_SEQ: sequence number of the next byte to be sent by
the client;
CLT_ACK: next byte to be received by the client;
CLT_WIND: client's receive window;
At the beginning when no data has been exchanged we have
SVR_SEQ = CLT_ACK and CLT_SEQ = SVR_ACK. These equations
are also true when the connection is in a 'quiet' state (no data being
sent on each side). They are not true during transitory states when
data is sent. The more general equations are:
CLT_ACK <= SVR_SEQ <= CLT_ACK + CLT_WIND
SVR_ACK <= CLT_SEQ <= SVR_ACK + SVR_WIND
The TCP packet header fields are:
Source Port: The source port number;
Destination Port: The destination port number;
Sequence number: The sequence number of the first
byte in this packet;
Acknowledgment Number: The expected sequence number
of the next byte to be received;
Data Offset: Offset of the data in the packet;
Control Bits:
URG: Urgent Pointer;
ACK: Acknowledgment;
PSH: Push Function;
RST: Reset the connection;
SYN: Synchronize sequence numbers;
FIN: No more data from sender;
Window: Window size of the sender;
Checksum: TCP checksum of the header and data;
Urgent Pointer: TCP urgent pointer;
Options: TCP options;
- SEG_SEQ will refer to the packet sequence number (as
seen in the header).
- SEG_ACK will refer to the packet acknowledgment number.
- SEG_FLAG will refer to the control bits.
On a typical packet sent by the client (no retransmission) SEG_SEQ is set
to CLT_SEQ, SEG_ACK to CLT_ACK.
TCP uses a ``three-way handshake'' to establish a new
connection. If we suppose that the client initiates the connection to
the server and that no data is exchanged, the normal packet exchange
is (C.f. Figure 1):
- The connection on the client side is on the CLOSED state.
The one on the server side is on the LISTEN state.
- The client first sends its initial sequence number and sets the SYN bit:
SEG_SEQ = CLT_SEQ_0,
SEG_FLAG = SYN
Its state is now SYN-SENT
- On receipt of this packet the server acknowledges the client sequence
number, sends its own initial sequence number and sets the SYN bit:
SEG_SEQ = SVR_SEQ_0,
SEQ_ACK = CLT_SEQ_0+1,
SEG_FLAG = SYN
and set
SVR_ACK=CLT_SEQ_0+1
Its state is now SYN-RECEIVED
- On receipt of this packet the client acknowledges the server
sequence number:
SEG_SEQ = CLT_SEQ_0+1,
SEQ_ACK = SVR_SEQ_0+1
and sets CLT_ACK=SVR_SEQ_0+1
Its state is now ESTABLISHED
- On receipt of this packet the server enters the ESTABLISHED state. We now
have:
CLT_SEQ = CLT_SEQ_0+1
CLT_ACK = SVR_SEQ_0+1
SVR_SEQ = SVR_SEQ_0+1
SVR_ACK = CLT_SEQ_0+1
Server Client
LISTEN CLOSED
<- SYN,
CLT_SEQ_0
LISTEN SYN-SENT
SYN, ->
SVR_SEQ_0,
CLT_SEQ_0+1
SYN-RECEIVED ESTABLISHED
SVR_SEQ = CLT_SEQ_0 + 1
CLT_ACK = SVR_SEQ_0 + 1
<- ACK,
CLT_SEQ_0 + 1
SVR_SEQ_0+1
ESTABLISHED
SVR_SEQ = SVR_SEQ_0 + 1
SVR_ACK = CLT_SEQ_0 + 1
figure 1: Example of a connection opening
Closing a connection can be done by using the FIN or the RST
flag. If the RST flag of a packet is set the receiving host enters the
CLOSED state and frees any resource associated with this instance of
the connection. The packet is not acknowledged. Any new incoming
packet for that connection will be dropped.
If the FIN flag of a packet is set the receiving host enters the
CLOSE-WAIT state and starts the process of gracefully closing the
connection. The detail of that procces is beyond the scope of this
document. The reader can refer to [rfc793] for further details.
In the preceding example we specifically avoided any unusual cases
such as out-of-band packets, retransmission, loss of packet, concurrent
opening, etc... These can be ignored in this simple study of the
attack.
When in ESTABLISHED state, a packet is acceptable if its
sequence number falls within the expected segment
[SVR_ACK, SVR_ACK + SVR_WIND]
(for the server) or
[CLT_ACK, CLT_ACK + CLT_WIND]
(for the client). If the sequence number is beyond those limits the
packet is dropped and a acknowledged packet will be sent using the
expected sequence number. For example if
SEG_SEQ = 200,
SVR_ACK = 100,
SVR_WIND = 50
Then SEG_SEQ > SVR_ACK + SVR_WIND. The server
forms a ACK packet with
SEG_SEQ = SVR_SEQ
SEG_ACK = SVR_ACK
which is what the server expects to see in the packet.
2.2 A desynchronized state
The term ``desynchronized state'' will refer to the connection
when both sides are in the ESTABLISHED state, no data is being sent
(stable state), and
SVR_SEQ != CLT_ACK
CLT_SEQ != SVR_ACK
This state is stable as long as no data is sent. If some data
is sent two cases can occur:
- If CLT_SEQ < SVR_ACK + SVR_WIND and
CLT_SEQ > SVR_ACK the packet is acceptable, the data may be stored
for later use (depending on the implementation) but not sent to the
user since the beginning of the stream (sequence number SVR_ACK) is
missing.
- If CLT_SEQ > SVR_ACK + SVR_WIND or CLT_SEQ <
SVR_ACK the packet is not acceptable and will be dropped. The data is
lost.
In both case data exchange is not possible even if the state
exists.
2.3 The attack
The proposed attack consists of creating a desynchronized state
on both ends of the TCP connection so that the two points cannot exchange data
any longer. A third party host is then used to create acceptable packets
for both ends which mimics the real packets.
Assume that the TCP session is in a desynchronized state and that
the client sends a packet with
SEG_SEQ = CLT_SEQ
SEG_ACK = CLT_ACK
Since CLT_SEQ != SVR_ACK the data will not be accepted and the
packet is dropped. The third party then sends the same packet but
changes the SEG_SEQ and SEG_ACK (and the checksum) such that
SEG_SEQ = SVR_ACK,
SEG_ACK = SVR_SEQ
which is acceptable by the server. The data is processed by the server.
If CLT_TO_SVR_OFFSET refers to SVR_ACK - CLT_SEQ and
SVR_TO_CLT_OFFSET refers to CLT_ACK - SVR_SEQ then the first party
attacker has to rewrite the TCP packet from the client to the server as:
SEG_SEQ <- SEG_SEQ + CLT_TO_SVR_OFFSET
SEG_ACK <- SEG_ACK - SVR_TO_CLT_OFFSET
Considering that the attacker can listen to any packet exchanged between
the two points and can forge any kind of IP packet (therefore masquerading as
either the client or the server) then everything acts as if the connection
goes through the attacker machine. This one can add or remove any data to
the stream. For instance if the connection is a remote login using telnet
the attacker can include any command on behalf of the user
("echo merit.edu lpj > ~/.rhosts" is an example of such a command)
and filter out any unwanted echo so that the user will not
be aware of the intruder.
Of course in this case CLT_TO_SVR_OFFSET and SVR_TO_CLT_OFFSET
have to change. The new values are let as an exercise for the
reader. [One can turn off
the echo in the telnet connection in order to avoid the burden of filtering
the output. The test we did showed up a bug in the current telnet
implementation (or maybe in the telnet protocol itself). If a TCP packet
contains both
IAC DONT ECHO and IAC DO ECHO the telnet processor will answer with
IAC WONT ECHO and IAC WILL ECHO. The other end point will acknowledge
IAC DONT ECHO and IAC DO ECHO etc... creating an endless loop.]
2.4 ``TCP Ack storm''
A flaw of the attack is the generation of a lot of TCP ACK
packets. When receiving an unacceptable packet the host acknowledges it
by sending the expected sequence number (As the Acknolegement number.
[ Pobierz całość w formacie PDF ]