³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij
+-+-+-+-+-+-+-+-+
ÛÛÛÛÛÛÛÛÛ²²²²²±±±±±°°°ð|O|u|t|b|r|e|a|k|ð°°°±±±±±²²²²²ÛÛÛÛÛÛÛ
+-+-+-+-+-+-+-+-+
Issue #5 - Page 9 of 13
³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij
######################################################################
## a sign of weakness. -dropcode ##
######################################################################
----------------------------------------------------------------------
"a firm handshake shows strength in character.
a feeble handshake is a sign of weakness."
----------------------------------------------------------------------
the connection initiation process most commonly associated with
internet communication channeling is known as the threeway handshake
and is a standard of the transmition control protocol [TCP].
in this article we will look at a mock threeway handshake in detail,
explain the different types of data exchanged during the process and
discuss potential weaknesses in the protocol.
----------------------------------------------------------------------
the operative mechanism of the tcp protocol is a means of transmitting
data over a communication channel between two machines without any
physical connection.
the means instated by the tcp standard is a complex system of parsing
data into packets of a fixed size and routing them through a long
string of systems to there destination.
each packet has 'flag bits' which can be set or unset. set bits
express the function of the packet. for instance, the purpose of a
packet with the synchronize [SYN] bit set is to initiate a connection,
whereas the purpose of a packet with the finish [FIN] bit set is to
terminate an existing connection.
the threeway handshake is a simple exchange of three packets between
the client and the server.
there are three basic steps to the handshake. figure 1.0 below
illustrates a basic representation of the three steps in sequence.
Step 1: the client begins the handshake by sending a packet with the
SYN bit set to the server signifying that it wants to initiate
a connection.
Step 2: the server recieves the SYN packet and returns a packet with
both the SYN and ACK bits set signifying that it accepts the
connection request.
Step 3: the client completes the handshake by sending an ACK packet,
a packet with the ACK bit set.
client applications are assigned a port to use in connecting to a
server. generally client ports are between 1024 and 65535. this is
called the ephemeral or client range.
servers (or daemons for *nix/*nux'ers) are also assigned a port. where
clients use there port to connect to a remote server, a server uses
its assigned port to listen for connection requests. servers listen on
ports in the service range, between 1 and 1023.
lets say the client in figure 1.0 is a web browser and is attempting
to view a webpage hosted by the server. a more elaborate diagram will
give a better representation of the process.
the SYN packet leaves the client system from a port in the ephemeral
range and reaches the server system on the standard service port for
http, 80. the serving system is running an http server (httpd)
that is listening on port 80 so, it recieves the connection request
and responds with a SYN/ACK. the client recieves that and returns an
ACK to finish the handshake. blamo.
----------------------------------------------------------------------
an important aspect of the threeway handshake was left out in the
examples above for simplicities sake. when the server recieves a SYN
packet and returns a SYN/ACK it also allocates memory reserved for
connections called connection resources. this is a cause for concern
because an attacker with access to raw sockets on his local machine
can manipulate the source address of the SYN packet which would
result in the following.
Step 1: the attacker sends a 'spoofed' SYN packet. this means the
source address of the packet has been altered, usually to a
random address. the 'source address' is the address of the
client machine and the only way the serving machine knows
where to send the SYN/ACK.
Step 2: the server recieves the SYN packet. it allocates connection
resources for buffers and other connection management purposes
and sends a SYN/ACK to the spoofed address. the connection is
now 'half-open' and will remain in this state until it
recieves an ACK packet, the connection terminates, or the
servers waiting state times out.
Step 3: if the spoofed address is an existing address with a working
machine, that machine will reply with an RST signifying that
it never requested a connection. But if there is no machine at
the spoofed address the packet will be discarded. after a
short time the server will assume that the SYN/ACK got lost
or dropped on the way and resend it.
Step 4: back to step 1. the second SYN packet will cause the server to
allocate more connection resources.
if the attacker sends enough SYN's to force the server to allocate all
available connection resources before the first half-open connection
times out, the server will have no way to accept any more connections.
even the valid ones.
it is also possible to bombard multiple machines with SYN packets all
spoofed to the same address. this will result in the machine at the
fraudulent address getting flooded with SYN/ACKS from multiple
machines of your choice. often the vicims logs will show them being
flooded by government or big corporation networks. *smirk*
when a SYN packet is sent it contains, in its header, an ISN or
initial sequence number. the SYN/ACK packet the server responds with
conntains the servers ISN. every packet thereafter contains psuedo-
randomly generated sequence numbers determined by the two ISN's
exchanged.
if the connection between the client and server can be sniffed it is
possible for an attacker to 'highjack' a tcp session by injecting
spoofed packets with the expected sequence numbers. Mitnick used
this attack, intermingled with the SYN flood explained earlier in his
well known attacks on Shimomura.
also, if a tcp session between a server and a trusted client is
sniffed by an attacker, the attacker can often 'replay' the initiation
part of the session to create a trusted connection between himself
and the server.
----------------------------------------------------------------------
well, thats about all the formalized bitching i can do in one phile.
if you have any questions email me at uberego@hotmail.com
greets: lexi, jenniebean, ramb0x, gr3p, kleptic, ex3mecut3 an digi.
thats it. thats all. bleh. if you're not on this list, you
obviously havn't shown me enough love. *taps toes* i'm waiting