Faking a TCP handshake from a spoofed ip. is it possible?

Questions
,
1

Overview

Without going into the detail of my goal too much, I essentially want to fake a TCP handshake between my own test server and some spoofed ip packets that lead to no where. I made the proof of concept, where I have a server that prints out a connection if it receives one, using sockets in python3, and using the scapy import to craft a TCP segment with a SYN flag, and, never receiving the SYN ACK from the server, sends the ACK segment, completing the handshake and causing the server to print that it recieved a connection.

Dilema

While this should work in theory, I’m now realizing that I never accounted for sequence and acknowledgment numbers, which explains why my server isn’t printing.

Question

With this specific problem in mind, How does one fake sequence and ack numbers, especially when you never receive them. Adding on to this, Because I’m sending the first packet, do I have to calculate a beginning seq number?

What I’ve got so far

whether or not I need to calculate a seq number, could I use said seq number, along with knowing ahead of time what packet will be sent next (a TCP SYN ACK in this case), to calculate the future seq numbers? if so, is this the only way to calculate seq numbers?

Any help on this topic(answers, links for future reference, etc.) would be much appreciated, and thanks in advance for taking time out of your guys’ busy schedules of forum browsing to help me out!

Edit:

To clarify, I’m not trying to intercept and take control of a TCP session. I’m trying to physically catfish a computer into thinking that an ip exists. So that instead of A and B talking and C(me) intercepting, its C trying to catfish A into thinking C is B, when B never really existed in the first place. The idea is that if the spoofed IP isn’t alive, and that I know what a server is going to send, I can reply to the message even though it never reaches me, because I know what was supposed to be sent.

Take the three way handshake. we all know that if you send a SYN, you’ll get a SYN ACK, and then the server knows it wants an ACK. because you know what the server is sending, and what it wants back, you can theoretically fake a handshake. You send a SYN request with a spoofed nonexistent IP, and because you know the server is going to reply with a SYN ACK, even though you never recieve said SYN ACK, you can reply with another spoofed packet that contains the ACK, completing a handshake with a nonexistent client.

The problem I’m having is I don’t know enough about seq and ack numbers to know if this is possible.

I really hope that didn’t just confuse people more, lmao.

2

Alright so my understanding of the situation is you want A and B to talk to eachother but you wish to be C - So like

A talks to B 1
Your sequence (A talks to B - C responds and overrides B answer back)

Just wanna make sure i’m on the same wave length before I go into detail of this methodology

3

You may want to research the Mitnick attack, I think this is exactly what you are trying to do.However, I don’t believe these kind of attacks are practical anymore in general (If you can intercept the SYN/ACK and get the sequence number I think it should be possible, but if you can’t …). The Mitnick attack relied on the sequence numbers being easily guessable as the OS just used a counter. These days they are random and if you have a method to guess one you could probably get a CVE for it.

MiTM attacks are still possible in some situations and you may be able to use one to do a similar thing (again, depends what you are trying to do).

1 Like
4

Hmm this is a very interesting possible attack.

I wonder what would happen if you sent every single possible packet with the sequence numbers at the same time, could you get really lucky?

@lkw, how many possible sequence numbers are there?

5

@Narcodex My idea is that B doesn’t even exist. C(the attacker) is pretending to be B by sending packets with a spoofed IP. I figure that if I know how A responds to a packet (like in a three way handshake) then I can send a reply without ever receiving A’s packet. Essentially, I’d send a SYN with a spoofed ip, I’d never receive a SYN ACK(Because I’m not at the spoofed address), but I’d still send an ACK with the spoofed ip, to make it look like A’s packet was received, even though it went no where.

@Ikw I’ll be sure to check that out when I get home today. I should probably clarify though that instead of intercepting packets, I’m more catfishing the target into thinking that a nonexistent IP is me. sorta like making a fake identity.

I think I might have been a little confusing in my questions, so I’ll be sure to edit the original post to try and clarify what I’m doing.

6

The sequence number is 4 bytes, so you’re talking about 2^32 possibilities.

7

4294967296 possibilities is acceptable :smiley: Especially if they’re coming from different places.

8

@pry0cc actually, I think that might be a little too general, so I took a page from the mitnick attack and started a handshake 1000 times with some websites(including this one) and I noticed that a lot of them aren’t doing a random seq number, but are actually jumping up(and only up) by a range. This site takes a little traffic, so this won’t be totally accurate, but taking 1 random number on the higher side of the 999 differences I calculated for this website and subtracting it by one of the lower ones I saw, I got a range of 830,849. of course, this is only between two numbers, and still a lot of possibilities, but it shows that there is a pattern, which is definitely a start.

if you want to see the results for this website, here’s a pastebin for it: https://pastebin.com/f4eKUK4t

9

I checked the Linux kernel source code. You can find it here, the function you want is secure_tcp_sequence_number. The actual randomness is a key the kernel initialises for all connections. This is added to the source and destination addresses and ports which a md5 hash is taken of. This is then scaled using a clock. (The whole thing is probably based on the algorithm described in rfc 6528). If you are keeping the ip addresses and ports the same (and the secret is constant) the little jumps you are seeing should be due to the clock. If you change the address you are connecting from or one your ports I think there should be a larger jump. However, I think if you use default values to create a socket in most languages the source port may change a bit (or maybe you are crafting the packet yourself with scapy or something?). It would be interesting to see how many times your source port changed when testing those sequence numbers (I think even a small change in source port should look quite a bit different).

11

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.