balenson@TIS.COM (David M. Balenson) (05/08/89)
I have read with interest Bellovin's article on "Security problems in the TCP/IP protocol suite". However, my interest diminished while reading the first section on "TCP sequence number prediction". I don't see the relevance of this attack to authentication. My understanding of TCP sequence numbers is that they are used during connection establishment to guarantee (1) that both the client and server are ready to transfer data and (2) that they agree on initial sequence numbers. Since when are initial sequence numbers supposed to be used for authenticating the identity of either the client (or server), anc hence prevent an intruder from impersonating a trusted host? The entire point of the discussion (and I presume Morris' original article, which I am trying to track down a copy of) is moot unless one assumes the ISNs are used for authentication. Furthurmore, even if I could not guess the servers ISN, couldn't I still spoof a trusted host by simply (e.g, on a Sun workstation) configuring my machine to look like (i.e., same name, perhaps same IP address) the trusted host? The key to preventing (or detecting) spoof attacks is the proper authentication of unique identities, yet this is not discussed (or mentioned). So, either I am missing something or the article is missing something (e.g., a simple statement of assumptions, up front). I'd appreciate any clarification anyone can offer. Thanks. -David M. Balenson Trusted Information Systems, Inc. (301) 854-5358
hedrick@geneva.rutgers.edu (Charles Hedrick) (05/09/89)
Being able to predict TCP sequence numbers is relevant because it allows one to be able to give commands over a one-way link. This means that gateways (routers) don't provide as much security as they seem to. We've known for a long time that it is easy to fake IP source addresses. So at first glance security based on source address doesn't look very useful. The counterargument was always "well, sure they can fake a source address, but the other direction will go back to the real machine, not the imposter, so the imposter can't get a real connection going". If the imposter can guess the sequence number that the other end is going to use, then it can probably dummy up an ACK field that will let the connection stay open long enough to send a command. I now believe that if you're going to depend upon IP source addresses (and from a practical point of view that may still be the only tool some of us have), you should set up your gateways to compare the claimed IP source address with the actual packet source. E.g. Rutgers might set up all exterior gateways to reject packets coming from the outside with source addresses of 128.6.x.x (our class B address). Similarly, the CS department might reject all packets physically from outside our department with a source address on one of our departmental networks.
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (05/09/89)
The point of a sequence number attack is to spoof a host *if you can't hear the return packets*. For example, suppose we have hosts A and B on a local net, along with gateway G. I'm off on attacker host X, also connected to G but on another LAN: A-------G---------B----------C | | | | X | | | Suppose I want to talk to A, and impersonate B. Normally, I can't do that, since I can't complete the 3-way handshake -- A's replies will go to the real B. That is, without a routing attack, I can't persuade A to route packets to B through G. With a sequence number attack, though, X doesn't have to hear A's reply. It can be predicted; thus, the third message of the open sequence can be sent blind. Once that's done, A thinks that the connection is open, and from B. X can't receive any output from the connection -- but with the ability to use rsh to execute commands, that hardly matters. Just rebooting C with B's IP address works on some networks, i.e., Ethernet cables and the like. But there are networks where the IP address is bound to the switching harware -- such as the ARPANET itself. There's no way (at the IP level or above) to make the ARPANET IMPs deliver addressed to B to C instead -- it just isn't wired that way. But a sequence number attack, where C claims to be B, will still work. --Steve Bellovin
hal@GATEWAY.MITRE.ORG (Hal Feinstein) (05/09/89)
Although your point on "proper" authentication is well taken, you must be aware that many networks use a variety of ad hoc mechanisms to provide security. The Morris TCP number attack described by Bellovin is real and takes advantage a near deterministic nature of TCP serial numbers. Sequence numbers in TCP is part of its reliable mechanism but in addition provide a poor man's data origin authentication. The point is that you can't trust (what ever that means) the TCP sequence numbers to resist an attack; however, in low threat environments it can be OK. In a high threat environment with an attacker willing to do the work it takes to subvert TCP sequence numbers, then it's not appropriate and you'd want something cryptographically protected.
zweig@p.cs.uiuc.edu (05/10/89)
Since presumably if someone at node Foo is trying to impersonate someone from node Bar in establishing a TCP connection with node Dog, the replies will all actually be sent to Bar (and Foo may never see them), Foo needs to be able to guess the initial sequence number node Dog will issue in order to impersonate Bar. The article is talking about faking a TCP connection establishment handshake when all you're able to do is send packets that look like they originated elsewhere -- if you can intercept all packets destined for the person you are impersonating, authentication becomes much trickier. -Johnny Zweig University of Illinois at Urbana-Champaign Department of Computer Science --------------------------------Disclaimer:------------------------------------ Rule 1: Don't believe everything you read. Rule 2: Don't believe anything you read. Rule 3: There is no Rule 3. -------------------------------------------------------------------------------
CERF@A.ISI.EDU (05/14/89)
David, The sequence numbers on TCP are intended to support sequenced, non-duplicative data delivery from source to sink. The 3-way handshake is supposed to help filter out accidental spoofing caused by old duplicate connection initiation sequences or other old data packets. This is a sort of suthentication, but by no means proof against active spoof attacks of the sort envisioned by Bellovin. Authentication in the sense of source/sink identity is surely not the province of the sequence number/IP address mechanisms since they are obviously penetrable in the absence of cryptographic mechanisms. I think Bellovin was focusing more on data integrity and on the ease with which one might fool an innocent TCP implementation, not so much to argue that the TCP sequence number and 3-way handshake were bad but that something in addition was needed to deal with authentication of origin. Vint