RFC 1948 | Defending Against Sequence Number Attacks

RFC Link

RFC 1948

Overview

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.

Initial Idea

• Method a: Ryptographic Authentication
• Disadvantages: It will quite a long time before that is deployed.
• Method 2: Many sites to restrict use of protocols
  that rely on address-based authentication, such as rlogin and rsh.
• Disadvantages: The prevalence of “sniffer attacks” – network
  eavesdropping (CERT Advisory CA-94:01) – has rendered ordinary
  TELNET [5] very dangerous as well.

Details of the Attack

1、 Under Normal Circumstances

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)

2、Sequence Number Attacks

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)

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.

PS-> A minor difficulty： 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.

The Fix

We can prevent sequence number guessing attacks by giving each connection – that is, each 4-tuple of <localhost, localport, remotehost, remoteport> – a separate sequence number space. Within each space, the initial sequence number is incremented according to [2]; however, there is no obvious relationship between the numbering in different spaces.

The obvious way to do this is to maintain state for dead connections, and the easiest way to do that is to change the TCP state transition diagram so that both ends of all connections go to TIMEWAIT state. That would work, but it’s inelegant and consumes storage space. Instead, we use the current 4 microsecond timer M and set

       ISN = M + F(localhost, localport, remotehost, remoteport).

It is vital that F not be computable from the outside, or an attacker could still guess at sequence numbers from the initial sequence number used for some other connection.

Suggest: F be a cryptographic hash function of the connection-id and some secret data.

Note that the secret cannot easily be changed on a live machine. Doing so would change the initial sequence numbers used for reincarnated connections; to maintain safety, either dead connection state must be kept or a quiet time observed for two maximum segment lifetimes after such a change.

Security Considerations

Good sequence numbers are not a replacement for cryptographic authentication. At best, they’re a palliative measure.

An eavesdropper who can observe the initial messages for a connection can determine its sequence number state, and may still be able to launch sequence number guessing attacks by impersonating that connection. However, such an eavesdropper can also hijack existing connections [11], so the incremental threat isn’t that high. Still, since the offset between a fake connection and a given real connection will be more or less constant for the lifetime of the secret, it is important to ensure that attackers can never capture such packets. Typical attacks that could disclose them include both eavesdropping and the variety of routing attacks discussed in [8]. If random numbers are used as the sole source of the secret, they MUST be chosen in accordance with the recommendations given in [10].

//References
http://www.faqs.org/rfcs/rfc1948.html