Defending Against Sequence Number Attacks
RFC 1948

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

Network Working Group                                        S. Bellovin
Request for Comments: 1948                                 AT&T Research
Category: Informational                                         May 1996

               Defending Against Sequence Number Attacks

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   IP spoofing attacks based on sequence number spoofing have become a
   serious threat on the Internet (CERT Advisory CA-95:01).  While
   ubiquitous crypgraphic authentication is the right answer, we propose
   a simple modification to TCP implementations that should be a very
   substantial block to the current wave of attacks.

Overview and Rational

   In 1985, Morris [1] described a form of attack based on guessing what
   sequence numbers TCP [2] will use for new connections.  Briefly, the
   attacker gags a host trusted by the target, impersonates the IP
   address of the trusted host when talking to the target, and completes
   the 3-way handshake based on its guess at the next initial sequence
   number to be used.  An ordinary connection to the target is used to
   gather sequence number state information.  This entire sequence,
   coupled with address-based authentication, allows the attacker to
   execute commands on the target host.

   Clearly, the proper solution is cryptographic authentication [3,4].
   But it will quite a long time before that is deployed.  It has
   therefore been necessary for many sites to restrict use of protocols
   that rely on address-based authentication, such as rlogin and rsh.
   Unfortunately, the prevalence of "sniffer attacks" -- network
   eavesdropping (CERT Advisory CA-94:01) -- has rendered ordinary
   TELNET [5] very dangerous as well.  The Internet is thus left without
   a safe, secure mechanism for remote login.

   We propose a simple change to TCP implementations that will block
   most sequence number guessing attacks.  More precisely, such attacks
   will remain possible if and only if the Bad Guy already has the
   ability to launch even more devastating attacks.

Bellovin                     Informational                      [Page 1]
RFC 1948                Sequence Number Attacks                 May 1996

Details of the Attack

   In order to understand the particular case of sequence number
   guessing, one must look at the 3-way handshake used in the TCP open
   sequence [2].  Suppose client machine A wants to talk to rsh server
   B.  It sends the following message:

           A->B: SYN, ISNa

   That is, it sends a packet with the SYN ("synchronize sequence
   number") bit set and an initial sequence number ISNa.

   B replies with

           B->A: SYN, ISNb, ACK(ISNa)

   In addition to sending its own initial sequence number, it
   acknowledges A's.  Note that the actual numeric value ISNa must
   appear in the message.

   A concludes the handshake by sending

           A->B: ACK(ISNb)

   The initial sequence numbers are intended to be more or less random.
   More precisely, RFC 793 specifies that the 32-bit counter be
   incremented by 1 in the low-order position about every 4
   microseconds.  Instead, Berkeley-derived kernels increment it by a
   constant every second, and by another constant for each new
   connection.  Thus, if you open a connection to a machine, you know to
   a very high degree of confidence what sequence number it will use for
   its next connection.  And therein lies the attack.

   The attacker X first opens a real connection to its target B -- say,
   to the mail port or the TCP echo port.  This gives ISNb.  It then
   impersonates A and sends

        Ax->B: SYN, ISNx

   where "Ax" denotes a packet sent by X pretending to be A.

   B's response to X's original SYN (so to speak)

        B->A: SYN, ISNb', ACK(ISNx)

Bellovin                     Informational                      [Page 2]
RFC 1948                Sequence Number Attacks                 May 1996

   goes to the legitimate A, about which more anon.  X never sees that
   message but can still send

        Ax->B: ACK(ISNb')

   using the predicted value for ISNb'.  If the guess is right -- and
   usually it will be -- B's rsh server thinks it has a legitimate
   connection with A, when in fact X is sending the packets.  X can't
   see the output from this session, but it can execute commands as more
   or less any user -- and in that case, the game is over and X has won.

   There is a minor difficulty here.  If A sees B's message, it will
   realize that B is acknowledging something it never sent, and will
   send a RST packet in response to tear down the connection.  There are
   a variety of ways to prevent this; the easiest is to wait until the
   real A is down (possibly as a result of enemy action, of course).  In
   actual practice, X can gag A by exploiting a very common