Blog01: BFTP — Mitnick’s Blind IP Spoofing

7 min readNov 5, 2022

Hi folks!

I would like to make it clear that my beginning in the security world was quite the coincidence. But before that I really liked networking.
One day I was reading a course “Maîtrisez vos applications et réseaux TCP/IP” by Eric Lalitte that I recommend to everyone starting up in network security. One chapter in the course was about a network attack by Kevin Mitnick, whom I think doesn’t need introductions.

In this article I will tell you about this attack, which allowed me to go deeper into the world of security. But before that we will go through some basic notions in networking which will allow a better understanding of the attack.

The OSI model:

The OSI (Open Systems Interconnection) model is a standard that recommends how computers should communicate with each other. That is by defining and describing seven layers that computer systems should use when communicating over a network.

But what are these “layers”?

OSI is a layered model, meaning that it is divided into several pieces called layers, each of which has a defined role.

Each layer has a specific role, for example the second layer (Datalink Layer) helps machines communicate in a local network, the third layer (Network Layer) helps machines communicate between different networks and the role of fourth layer is to enable sequencing of data so that it can be easily transferred and organized.
The OSI model enables us to use a standardized way of communicating over the network, and that is mostly thanks to the use of protocols, for example the TCP protocol of the fourth layer.

The TCP protocol:

TCP is a transport layer protocol also called Transmission Control Protocol, it is considered very reliable and works in a connection-oriented mode.

But what does “connection-oriented” mean?

Before communication, we ensure a session.

Let’s take the example of a phone conversation. Before telling his story, the interlocutor will first make sure that his partner is present at the end of the line. This looks something like:

A calls B: Tut… tut…
B responds: Hello!
A begins his conversation: Hey, wassup dude!

We see very clearly here that it’s important to establish a session with the contact before talking about the subject. The same thing happens over TCP.

How is connection established over TCP?

Establishing the TCP session is called the “Three Way Handshake”.

The first packet will be a synchronization request, like the tut…tut… on the phone call, the corresponding flag is the SYN flag (SYN for synchronization, who would’ve thought?)
A server receiving a SYN request should normally reply that it is willing to communicate with the client. For this it will send an ACK in response (acknowledgment), it’s the equivalent of the Hello! on our call . It will also notify the client that it’s ready to communicate by also sending a SYN flag in its response. There will therefore be the SYN and ACK flags set in its response.
The client sends an ACK and a reliable connection is established

Three steps, for a Three Way Handshake. But that’s just the simple explanation, let’s dive a bit deeper into what is actually happening.

We see here that the client sends a first segment with the SYN flag set. Its sequence number is set to 0 and its acknowledgment number is also set to 0. The sequence number represents the first data byte of the current segment, but since it does not contain any, this number is 0. But the acknowledgment number is a bit different, since this depends on the data sent by the server, and that it has not yet spoken to us, we automatically set it to 0.
Then, the server responds to the client, confirming that it wants to communicate (ACK) and that it also wants to open a communication channel to the client (SYN). Its sequence number is 0, for the same reason as the client. On the other hand, its acknowledgment number is 1. The acknowledgment number is increased by 1 for any response to a segment where the SYN flag is set.
The client acknowledges the response of the server and the connection is established in both ways.

In real life, the first sequence number is not really 0, it is a random value, it has a name, ISN or Initial Sequence Number.

Now that we have everything we need to understand the attack. Let’s get to it, shall we ?

Blind IP spoofing:

The idea is that Kevin Mitnick must find a way to convince the server that he is the machine with the IP address A in order to be able to connect to it (this supposes that the machine having the IP address A is authorized to access the server),

For Mitnick to initialize his session with the server, he must manage to send a SYN pretending to be A.
Supposing that happens, the server will then respond with a SYN+ACK segment since it recognizes the IP address A.
At this point, all Mitnick has to do is to send an ACK segment to achieve a three-way handshake. Bingo!

But it’s unfortunately not that simple. There are a few issues that we haven’t taken into consideration so far. Let’s take a look at them.

First issue: The server responds to A by putting its own sequence number, and that, Mitnick cannot know, since the segment went to machine A, this is in particular why the attack is called blind spoofing, we do not know the sequence number sent by the server, we are blind.
Second issue: If Mitnick sends his first SYN to the server. A will be receiving an unsolicited SYN+ACK segment from nowhere. A will then respond wit an RST segment to close the connection with the server

So how can we fix these two issues and manage a successful attack ?

Solution to the first issue: The ISN vulnerability

Back in the day, ISN depended on a counter continuously calculated by computers. Basically, when the computer started, a counter started at 0 and the RFC 793 (that defines TCP) said that this counter should be incremented by 1 every 4 microseconds. Many manufacturers that wanted a simpler solution incremented this counter by 128,000 every second, which is not quite equivalent, but of the same order of magnitude.
In addition, this counter was also increased by 64,000 or 128,000 for each TCP connection that was created.
Thus, when a TCP connection started or a machine received a first SYN and had to respond to it by indicating its ISN, it would look at the value of the counter at that instant and take its value as the said ISN.

So that means that the ISN was not entirely random…

Solution to the second issue: SYN flooding

If we just content ourselves with sending a SYN, the server will allocate resources to wait for our response until a timeout is exceeded. If we then send a multitude of SYN packets, the server will allocate a lot of resources on standby to respond to us. Meanwhile, we will never respond.

So, in theory if we send enough SYN to saturate the server’s resources the flooding would be successful and server will no longer respond to new connection requests.

So that means we don’t need to worry about the connection closing

Execution of the attack:

Mitnick launches his SYN flooding attack towards A in order to make it unreachable to the network and prevent it from responding while moving forward.
Mitnick also sends a few SYN segments to the server to see how much the counter is increased across each example. He will use in the SYN+ACK response segments the values of the sequence number at the time when the server will have sent them.
Mitnick will realize for example that the increase in the server’s ISN value is 128,000 between each connection.
Mitnick then repeats the operation at set intervals to know the difference between the sequence numbers on the server. He will respond with a SYN+ACK segment to machine A.
All that remains now is to send back the ACK segment with the correct sequence number, still pretending to be A.
The server having received a segment with a valid and correct acknowledgment number will establish the connection.

Et voilà! the connection is achieved.

Mitnick can only send one command, because he won’t be able to predict further acknowledgement numbers. But what he has done wa enough to enable him to send the following command:

echo ++ > /.rhosts

This adds ++ to the .rhosts file, which will amount to granting any machine the right to connect to the server no matter it’s IP address.

So basically Mitnick gave himself full access to the server from any IP address.

This is definitely a beautiful and out-of-the-box attack. But, there is unfortunately no way for you to put it into practice in real life. Unless you manage to go back in time to the 90s.

Links:

Facebook: INSEC Ensias

Instagram: INSEC Ensias

Linkedin: INSEC Ensias

Youtube: INSEC Club

Don’t forget to drop us a follow on social media to stay up to date with everything the club is doing. Looking forward to sharing our knowledge with all the readers and we welcome your feedback at insecblog@gmail.com

Writer: akna

Editors: berradAtay, F3nn3C