Attack Class: Address Spoofing

Today I will talk about a paper I read I found very interesting. It can be "old", but I consider it "young" antway. The paper is called "Attack Class: Address Spoofing", by Heberlein, and Bishop. It was published at the Proceedings of the 19th. National Information Systems Security Conference, pp. 371-377, Oct. 1996. So it is 10 years old.
It describes a general attack called "Addres Spoofing", and it is based on a real case. It is interesting that this case was the attack launched against Tsutomu Shimomura's computers by Kevin Mitnick.
The paper starts talking about a feature of computer networks. It is the presence of some services that use host names, or its addresses, for IDENTIFICATION, and even for AUTHENTICATION (it can mean that even passwords are not necessary!). A server will answer if the message comes from a "trusted" host. The only thing an adversary needs to do is to forge a valid message to the server, as it came from one of its "trusted" hosts.

Let's try to understand the attack.
1st. we need to remember the kind of communication we can have in a computer network.
Connectionless communications are done by a protocol like UDP. It does not keep state information from a message to another. Any message must be a completed request to the destination server. Here is extremelly easy to attack the server. The adversary needs only to construct the message, and gives it to the UDP protocol to deliver. There is no guarantees that the messages will arrive at the destination. The messages can also arrive at the destination in a different order from the transmission. Besides these problems, the advantages of UDP are interesting for the applications developpers. The UDP protocol is fast, and very efficient.

If the application needs more reliable communication, even if it loses some efficiency, the developpers can choose a connection-oriented protocol like TCP protocol. It "guarantees" that the packets will arrive at the destination process, and in the same order they were sent. If not (e.g., the destination host is down) the sending process will be notified.

A connection-oriented protocol has three phases: the connection set-up, the conversation, and the connection tear-down.
The TCP connection set-up is a handshake in three steps where each host tells to the other what is its beginning sequence number. Let's see this Figure took from the paper:


An interesting consequence of this procedure is that the connection is not considered established before each host acknowledges the sequence number of its partner.
You have to verify in the picture that the ack of the sequence number is incremented by one comparing to the value informed by the source host. Other interesting point in the handshake is that the host B's sequence number has to be acknowledged only in the step #3. Host A must show to host B that it knows its sequence number. Otherwise the connection will be terminated.

The adversary has a good tool to help in the attack. It is the routing system of the internetwork. This system is very efficient, and unfortunally it can be used to attack us in the same way we use it to send our authentical messages. It is not necessary to know the undelying architecture of the internetwork. The packets travel across the internetwork based only in the address of the destination. It means that the source host can be anything, even a down host, or a fake one. This is the principal reason to use some rules in the firewalls (e.g. discard packets from the outside that came with inside addresses).

The paper uses a simple model to explore all the possibilities of relative positions between all the players (Host A - Alice; Host B - Bob; and Host E - Eve, the adversary). We can see the model in the next figure:


We consider that Bob grants Alice some privileges. In some Unix system, it is performed with the inclusion of Alice's name (or address) in some configuration file like .rhosts. It means that Alice is able to ask Bob to do some actions, and he is about to do them just because Alice is who she says she is. So Eve's goal is to make Bob to do a specific action that he would do for Alice, but not for Eve.

The model shows four positions for Eve related to the Alice, and Bob' positions.
E1 means that Eve is in the same Bob's network. E3 looks like this one, but this time for Alice.
E2 is the position where Eve is in the path of the communication between Alice and Bob.
E4 means that Eve has no direct access to the Alice and Bob' Networks.

The model showed is a more general one where Alice, and Bob are not in the same network. If it happens, we have a special case where the positions E1 and E3 are the same, and there is no position E2.

The Eve's 1st. problem is to turn her communication with Bob indistinguishable from Alice's communication with Bob (at least from Bob's point of view).
When the communication is done by a connectionless oriented protocol, Alice just sends a message to Bob, he processes the request, and he just sends back the answer. It's something like the HTTP protocol.

The real problem is the possibility to use a connection oriented protocol like TCP. In this case, Alice and Bob will exchange a lot of messages just before Bob processes any request. If this dialogue does not make sense to Bob, he will just close the connection. Even in the case that Eve's communication with Bob is correct, Bob will be talking to Alice (not to Eve, who will be pretending to be Alice). In the case that Alice receives some message from Bob, she will tell him that she is not talking to him. So he will close the connection. Eve maybe needs some more time using the dialogue, or she will not have success.

The Eve's 1st. task is to divide her goal in subgoals.
1) establish and keep a fake communcication with Bob;
2) preventing Alice from tell him about the deceive.

The 1st. one is easy when Bob is accepting a connectionless oriented protocol like UDP. Eve will just construct a packet and send it. The internetwork will do all the job. In this case, the communication subgoal (1) is done.

However, if Bob only accepts TCP Eve has a great problem to solve. She needs to send multiple packets to Bob. Some of them must have a content based on Bob's replies (e.g. Bob's TCP sequence number). The positions E1, E2, and E3 are perfect to observe Bob's replies. In the position E4 Eve must be able to modify the reply path from Bob to Alice (this can be done easily through source routing). If not maybe Eve is able to modify the router settings.

If not, but Eve can predict Bob's replies (e.g. Bob's sequence number) she also can keep a communication with Bob. According to the authors, predicting sequence numbers (a technique used in some IP spoofing attacks) is discussed in two papers:

Bellovin, S., "Security Problems in the TCP/IP Protocol Suite," Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989.

Morris, R.T., "A Weakness in the 4.2BSD Unix TCP/IP Spftware," Computing Science Technical Report No. 117, AT&T Bell Laboratories, Murray Hill, New Jersey, 1985.

Eve's 2nd. goal is to prevent interference from Alice. The paper discuss three ways:

(1) block Bob's packets in the path to Alice (or Alice's packets in the path to Bob). This is possible if Alice is able to modify the router system of the network (she is a router, or she is using source routing to make the flow passes through her). She simply does not forward the packets to Alice. If she is not on the path between Alice and Bob, she can attack one of the routers to misroute the packets addressed to Alice. The last resource is to test the internetwork between Alice and Bob until it fails and so she can launch the attack.

(2) destroy the Alice's capacity to reply. It can be very easy for Eve to do. e.g. (a) Eve can attack Alice, trying to crash her (not very difficult), (b) Eve can wait until Alice goes down (e.g. maintenance), (c) block the Alice's TCP/IP suite don't allowing her to process any packet. The later one is very interesting. A discussion about it can be seen in the Morris's paper.

(3) the communication between Eve and Bob can be much faster than between Alice and Bob. In this case, Eve could complete the attack before Alice's reaction. Eve can produce this one with a simple DoS attack to Alice or some router on the path between Alice and Bob.

The techniques presented here are not exaustive. Someone can find other methods so effective than the methods cited by the authors.

Kevin Mitnick attacked the Tsutomu Shimomura's computers with a method that can be described with the generic model presented here. A description of his attack can be seen in the Morris's paper.
Mitnick pretended to be a Shimomura's server (Alice) communicating with an X-client. The Mitnick's computer was in the position E4.

1st. Mitnick launched a DoS attack to the server sending multiple SYN requests to rlogin port #513 from a fake host (in fact, a non-existent one). Alice answers each one, but as the host does not exist the 3th. message never comes. The partial connections block real new ones. The architecture of the communication system is designed to support only eight partial connections.

The reason why Eve uses a non-existent host to launch the DoS attack is that her own host would have sent a RST command after Alice's reply. A real one will try to follow all the protocol steps. Eve wants to start a connection dialogue without finish it. So a non-existent host is the only solution.

2nd. Prediction of Bob's sequence number. It is done by sending 20 SYN requests to Bob's host, each one with a starting sequence number incremented by 128,000. Eve must use a legitimate host address in the process to observe Bob's replies.

3th. Stablish a dialogue with Bob pretending to be Alice. Probably Eve could not see Bob's replies, but she can predict Bob's starting sequence number (2,024,384,000 - it means 128,000 more than the last request i step #2). An open session with the shell server allows Eve to send a shell command like "echo '+ +' >> /.rhosts", which will place a "+ +" in the /.rhosts file. Eve can do it using an inpersonation of Alice. After the attack, anyone from anywhere could rlogin to Bob.

The authors finish the paper with some popular questions probably they had heared before. Let's see a resume of the ideas.

(a) configuring routers to not forward forged packets can be used in limited situations. If Alice and Bob are not on the same network it does not work.

(b) limiting all trusted hosts to the same phisical network restricts the applications. Remember we are living the age of distributed systems. Using lower level addresses such MAC adresses is not a solution as it's possible to forge Ethernet source addresses.

(c) a better algorithm to choose initial sequence numbers (meaning a less predictable one) only works if Eve is in position E4, and she is unable to alter routing information.

(d) an extension of this attack is the session hijacking, where Eve can place a forged request into an existing TCP connection. If it is possible, even password protected services are vulnerable as the partners consider secure everything after the handshake. Even one-time passwords are not protections to this attack.