分享
 
 
 

RFC1948 - Defending Against Sequence Number Attacks

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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.

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, RFC793 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)

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

implementation bug; this is described below.

The Fix

The choice of initial sequence numbers for a connection is not

random. Rather, it must be chosen so as to minimize the probability

of old stale packets being accepted by new incarnations of the same

connection [6, Appendix A]. Furthermore, implementations of TCP

derived from 4.2BSD contain special code to deal with such

reincarnations when the server end of the original connection is

still in TIMEWAIT state [7, pp. 945]. Accordingly, simple

randomization, as suggested in [8], will not work well.

But duplicate packets, and hence the restrictions on the initial

sequence number for reincarnations, are peculiar to individual

connections. That is, there is no connection, syntactic or semantic,

between the sequence numbers used for two different connections. 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. We therefore suggest that F

be a cryptographic hash function of the connection-id and some secret

data. MD5 [9] is a good choice, since the code is widely available.

The secret data can either be a true random number [10], or it can be

the combination of some per-host secret and the boot time of the

machine. The boot time is included to ensure that the secret is

changed on occasion. Other data, such as the host's IP address and

name, may be included in the hash as well; this eases administration

by permitting a network of workstations to share the same secret data

while still giving them separate sequence number spaces. Our

recommendation, in fact, is to use all three of these items: as

random a number as the hardware can generate, an administratively-

installed pass phrase, and the machine's IP address. This allows for

local choice on how secure the secret is.

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.

A Common TCP Bug

As mentioned earlier, attackers using sequence number guessing have

to "gag" the trusted machine first. While a number of strategies are

possible, most of the attacks detected thus far rely on an

implementation bug.

When SYN packets are received for a connection, the receiving system

creates a new TCB in SYN-RCVD state. To avoid overconsumption of

resources, 4.2BSD-derived systems permit only a limited number of

TCBs in this state per connection. Once this limit is reached,

future SYN packets for new connections are discarded; it is assumed

that the client will retransmit them as needed.

When a packet is received, the first thing that must be done is a

search for the TCB for that connection. If no TCB is found, the

kernel searches for a "wild card" TCB used by servers to accept

connections from all clients. Unfortunately, in many kernels this

code is invoked for any incoming packets, not just for initial SYN

packets. If the SYN-RCVD queue is full for the wildcard TCB, any new

packets specifying just that host and port number will be discarded,

even if they aren't SYN packets.

To gag a host, then, the attacker sends a few dozen SYN packets to

the rlogin port from different port numbers on some non-existent

machine. This fills up the SYN-RCVD queue, while the SYN+ACK packets

go off to the bit bucket. The attack on the target machine then

appears to come from the rlogin port on the trusted machine. The

replies -- the SYN+ACKs from the target -- will be perceived as

packets belonging to a full queue, and will be dropped silently.

This could be avoided if the full queue code checked for the ACK bit,

which cannot legally be on for legitimate open requests. If it is

on, RST should be sent in reply.

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].

Acknowledgments

Matt Blaze and Jim Ellis contributed some crucial ideas to this RFC.

Frank Kastenholz contributed constructive comments to this memo.

References

[1] R.T. Morris, "A Weakness in the 4.2BSD UNIX TCP/IP Software",

CSTR 117, 1985, AT&T Bell Laboratories, Murray Hill, NJ.

[2] Postel, J., "Transmission Control Protocol", STD 7, RFC793,

September 1981.

[3] Kohl, J., and C. Neuman, "The Kerberos Network Authentication

Service (V5)", RFC1510, September 1993.

[4] Atkinson, R., "Security Architecture for the Internet

Protocol", RFC1825, August 1995.

[5] Postel, J., and J. Reynolds, "Telnet Protocol Specification",

STD 8, RFC854, May 1983.

[6] Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for

High-Speed Paths", RFC1885, October 1990.

[7] G.R. Wright, W. R. Stevens, "TCP/IP Illustrated, Volume 2",

1995. Addison-Wesley.

[8] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",

April 1989, Computer Communications Review, vol. 19, no. 2, pp.

32-48.

[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321,

April 1992.

[10] Eastlake, D., Crocker, S., and J. Schiller, "Randomness

Recommendations for Security", RFC1750, December 1994.

[11] L. Joncheray, "A Simple Active Attack Against TCP, 1995, Proc.

Fifth Usenix UNIX Security Symposium.

Author's Address

Steven M. Bellovin

AT&T Research

600 Mountain Avenue

Murray Hill, NJ 07974

Phone: (908) 582-5886

EMail: smb@research.att.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有