IP-spoofing Demystified

The purpose of this paper is to explain IP-spoofing to the masses.  It assumes little more than a working knowledge of Unix and TCP/IP.  Oh, and that yur not a moron…

IP-spoofing is complex technical attack that is made up of several components.  (In actuality, IP-spoofing is not the attack, but a step in the attack.  The attack is actually trust-relationship exploitation.  However, in this paper,  IP-spoofing will refer to the whole attack.)  In this paper, I will explain the attack in detail, including the relevant operating system and networking information.


–[ The Players ]–

A:      Target host
B:      Trusted host
X:      Unreachable host
Z:      Attacking host
(1)2:   Host 1 masquerading as host 2

–[ The Figures ]–

There are several figures in the paper and they are to be interpreted as per the following example:

ick   host a      control     host b
1       A       —SYN—>      B

tick:   A tick of time.  There is no distinction made as to *how* much time passes between ticks, just that time passes.  It’s generally not a great deal.

host a: A machine particpating in a TCP-based conversation.

control: This field shows any relevant control bits set in the TCP header and the direction the data is flowing

host b: A machine particpating in a TCP-based conversation.

In this case, at the first refrenced point in time host a is sending a TCP segment to host b with the SYN bit on.  Unless stated, we are generally not concerned with the data portion of the TCP segment.

–[ Trust Relationships ]–

In the Unix world, trust can be given all too easily.  Say you have an account on machine A, and on machine B.  To facilitate going betwixt the two with a minimum amount of hassle, you want to setup a
full-duplex trust relationship between them.  In your home directory at A you create a .rhosts file: `echo “B username” > ~/.rhosts` In your home directory at B you create a .rhosts file: `echo “A username”> ~/.rhosts` (Alternately, root can setup similar rules in /etc/hosts.equiv, the difference being that the rules are hostwide, rather than just on an individual basis.)  Now, you can use any of the r* commands without that annoying hassle of password authentication. These commands will allow address-based authentication, which will grant or deny access based off of the IP address of the service requestor.

–[ Rlogin ]–

Rlogin is a simple client-server based protocol that uses TCP as it’s transport.  Rlogin allows a user to login remotely from one host to another, and, if the target machine trusts the other, rlogin will allow the convienience of not prompting for a password.  It will instead have authenticated the client via the source IP address.  So, from our example above, we can use rlogin to remotely login to A from B (or vice-versa) and not be prompted for a password.

–[ Internet Protocol ]–

IP is the connectionless, unreliable network protocol in the TCP/IP suite.  It has two 32-bit header fields to hold address information.  IP is also the busiest of all the TCP/IP protocols as almost all TCP/IP traffic is encapsulated in IP datagrams. IP’s job is to route packets around the network.  It provides no mechanism for reliability or accountability, for that, it relies on the upper layers.  IP simply sends out datagrams and hopes they make it intact. If they don’t, IP can try to send an ICMP error message back to the source, however this packet can get lost as well.  (ICMP is Internet Control Message Protocol and it is used to relay network conditions and different errors to IP and the other layers.)  IP has no means to guarantee delivery.  Since IP is connectionless, it does not maintain any connection state information.  Each IP datagram is sent out without regard to the last one or the next one.  This, along with the fact that it is trivial to modify the IP stack to allow an arbitrarily choosen IP address in the source (and destination) fields make IP easily subvertable.

–[ Transmission Control Protocol ]–

TCP is the connection-oriented, reliable transport protocol in the TCP/IP suite.  Connection-oriented simply means that the two hosts participating in a discussion must first establish a connection before data may change hands.  Reliability is provided in a number of ways but the only two we are concerned with are data sequencing and acknowledgement.  TCP assigns sequence numbers to every segment and acknowledges any and all data segments recieved from the other end. (ACK’s consume a sequence number, but are not themselves ACK’d.) This reliability makes TCP harder to fool than IP.

–[ Sequence Numbers, Acknowledgements and other flags ]–

Since TCP is reliable, it must be able to recover from lost, duplicated, or out-of-order data.  By assigning a sequence number to every byte transfered, and requiring an acknowledgement from the other end upon receipt, TCP can guarantee reliable delivery.  The receiving end uses the sequence numbers to ensure proper ordering of the data and to eliminate duplicate data bytes.

TCP sequence numbers can simply be thought of as 32-bit counters.  They range from 0 to 4,294,967,295.  Every byte of
data exchanged across a TCP connection (along with certain flags) is sequenced.  The sequence number field in the TCP header will contain the sequence number of the *first* byte of data in the TCP segment.  The acknowledgement number field in the TCP header holds the value of next *expected* sequence number, and also acknowledges *all* data up through this ACK number minus one.

TCP uses the concept of window advertisement for flow control.  It uses a sliding window to tell the other end how much data it can buffer.  Since the window size is 16-bits a receiving TCP can advertise up to a maximum of 65535 bytes.  Window advertisement can be thought of an advertisment from one TCP to the other of how high acceptable sequence numbers can be.

Other TCP header flags of note are RST (reset), PSH (push) and FIN (finish).  If a RST is received, the connection is immediately torn down.  RSTs are normally sent when one end receives a segment that just doesn’t jive with current connection (we will encounter an example below).  The PSH flag tells the reciever to pass all the data is has queued to the aplication, as soon as possible.  The FIN flag is the way an application begins a graceful close of a connection (connection termination is a 4-way process). When one end recieves a FIN, it ACKs it, and does not expect to receive any more data (sending is still possible, however).

–[ TCP Connection Establishment ]–

In order to exchange data using TCP, hosts must establish a a connection.  TCP establishes a connection in a 3 step process called the 3-way handshake.  If machine A is running an rlogin client and wishes to conect to an rlogin daemon on machine B, the process is as follows:


1       A       —SYN—>      B

2       A    <—SYN/ACK—     B

3       A       —ACK—>      B

At (1) the client is telling the server that it wants a connection. This is the SYN flag’s only purpose.  The client is telling the server that the sequence number field is valid, and should be checked. The client will set the sequence number field in the TCP header to it’s ISN (initial sequence number).  The server, upon receiving this segment (2) will respond with it’s own ISN (therefore the SYN flag is on) and an ACKnowledgement of the clients first segment (which is the client’s ISN+1). The client then ACK’s the server’s ISN (3).  Now, data transfer may take place.

–[ The ISN and Sequence Number Incrementation ]–

It is important to understand how sequence numbers are initially choosen, and how they change with respect to time.  The initial sequence number when a host is bootstraped is initialized to 1. (TCP actually calls this variable ‘tcp_iss’ as it is the initial *send* sequence number.  The other sequence number variable, ‘tcp_irs’ is the initial *receive* sequence number and is learned during the 3-way connection establishment.  We are not going to worry about the distinction.)  This practice is wrong, and is acknowledged as so in a comment the tcp_init() function where it appears.  The ISN is incremented by 128,000 every second, which causes the 32-bit ISN counter to wrap every 9.32 hours if no connections occur.  However, each time a connect() is issued, the counter is incremented by64,000.

One important reason behind this predictibility is to minimize the chance that data from an older stale incarnation (that is, from the same 4-tuple of the local and remote IP-addresses TCP ports) of the current connection could arrive and foul things up.  The concept of the 2MSL wait time applies
here, but is beyond the scope of this paper.  If sequence numbers were choosen at random when a connection arrived, no guarantees could be made that the sequence numbers would be different
from a previous incarnation.  If some data that was stuck in a routing loop somewhere finally freed itself and wandered into the new incarnation of it’s old connection, it could really foul things up.

–[ Ports ]–

To grant simultaneous access to the TCP module, TCP provides a user interface called a port.  Ports are used by the kernel to identify network processes.  These are strictly transport layer entities (that is to say that IP could care less about them). Together with an IP address, a TCP port provides provides an endpoint for network communications.  In fact, at any given moment *all* Internet connections can be described by 4 numbers: the source IP address and source port and the destination IP address and destination port.  Servers are bound to ‘well-known’ ports so that they may be located on a standard port on different systems.  For example, the rlogin daemon sits on TCP port 513.


…The devil finds work for idle hands….

–[ Briefly… ]–

IP-spoofing consists of several steps, which I will briefly outline here, then explain in detail.  First, the target host is choosen.  Next, a pattern of trust is discovered, along with a trusted host.  The trusted host is then disabled, and the target’s TCP sequence numbers are sampled.  The trusted host is impersonated, the sequence numbers guessed, and a connection attempt is made to a service that only requires address-based authentication.  If successful, the attacker executes a simple command to leave abackdoor.

–[ Needful Things ]–

There are a couple of things one needs to wage this attack:


About Sharing Data
Kami hanya ingin berbagi ilmu dan informasi

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: