Faking the TCP handshake

http://lgms.nl/blog-2

by citizenk • 11 years ago

104 30 11 years ago

lgms.nl

arpa• 11 years ago

well AFAIR TCP RST attack works exactly like that...

https://en.wikipedia.org/wiki/TCP_reset_attack

So I doubt this is a new finding.

tptacek4• 11 years ago

I'm not sure this is new. The technique of suppressing responses from the spoof source is as old as TCP sequencing, and was a prerequisite for Laurent Joncheray's "Simple Active Attack Against TCP" that introduced session hijacking.

Also see:

http://phrack.org/issues/64/13.html

wtbob• 11 years ago

Perhaps what's new is that it is so easily exploitable?

I remember when 32 bits seemed huuuge, and now … not so much.

armitron4• 11 years ago

No it's not, the author "failed" to mention that the vast majority of networks drop spoofed packets. It may be exploitable inside a target network, locally, but one usually has a lot better options if he has a foothold there, than bruteforcing sequence numbers with gigabytes of traffic for a single connection.

It's dumb is what it is.

armitron4• 11 years ago

This attack has been around forever and ever, I don't see anything new. In fact, it's the opposite, his method is naive (dumb bruteforcing). Moreover, a lot (the vast majority) of networks these days drop spoofed packets (egress).

The phrack article describes a lot more sophisticated attack.

Mitnick used it to hack Shimomura.

http://wiki.cas.mcmaster.ca/index.php/The_Mitnick_attack

More recent but still 9 years old: http://phrack.com/issues/64/13.html#article

tptacek4• 11 years ago

I don't think probing the whole ISN space is new, but that's not how the tool Mitnick was given worked. At the time of the Mitnick attack, TCP ISNs were trivially predictable; you could connect to a host, note its ISN, and then know within a very tight range what the next ISN on the next connection --- from any host --- would be.

armitron4• 11 years ago

The sequence number prediction specifics are different, but the attack is the same, blind TCP spoofing.

SFjulie1• 11 years ago

And it was easy because the PRNG had a small volume in the space phase

http://lcamtuf.coredump.cx/newtcp/

What I don't understand is why the use of Taken's series are still not a standard for the analysis of the randomness...

It resulted in this CVE http://www.cert.org/historical/advisories/CA-2001-09.cfm

And almost all the industry either switching to linux or as the licence authorized it they could have used BSD TCP stack since then, I guess.

Here is an horrible implementation of Taken's visualization.

https://gist.github.com/jul/0f16782ed01f18c2c72a

ikeboy• 11 years ago

http://lcamtuf.coredump.cx/oldtcp/tcpseq.html

However, guessing the right ISN from the entire 32-bit space (4,294,967,296 possibilities) is not feasible due to the excessive amount of bandwidth and time required. That is why a good TCP sequence number generator implementation currently provides enough security to protect against spoofing attacks, at least for the present time and in typical conditions. But increasing bandwidth and processor speed will eventually make brute force guessing of 32-bit ISNs feasible for the average attacker.

peterwwillis• 11 years ago

Everything old is new again. Here's how Nmap helps you identify hosts that are easy to attack so you don't have to brute force them:

  TCP Sequence Prediction
  
  Systems with poor TCP initial sequence number generation are vulnerable to 
  blind TCP spoofing attacks. In other words, you can make a full connection to 
  those systems and send (but not receive) data while spoofing a different
  IP address. The target's logs will show the spoofed IP, and you can take 
  advantage of any trust relationship between them. This attack was all the
  rage in the mid-nineties when people commonly used rlogin to allow logins 
  to their account without any password from trusted IP addresses. 
  Kevin Mitnick is alleged to have used this attack to break into Tsutomu Shimomura's 
  computers in December 1994.
  
  The good news is that hardly anyone uses rlogin anymore, and many operating 
  systems have been fixed to use unpredictable initial sequence numbers 
  as proposed by RFC 1948. For these reasons, this line is only printed in 
  verbose mode. Sadly, many vendors still ship vulnerable operating systems 
  and devices. Even the fixed ones often vary in implementation, which 
  leaves them valuable for OS detection purposes.
  [..]
  Further details about sequence tests are provided in the section called 
  “TCP ISN greatest common divisor (GCD)” [1].

https://nmap.org/book/osdetect-usage.html [1] https://nmap.org/book/osdetect-methods.html#osdetect-gcd

A fun look at sequence number PNRGs of various (old) OSes: http://lcamtuf.coredump.cx/newtcp/

fabioyy• 11 years ago

who remember Mitnick and rsh?

abpavel• 11 years ago

This is not an attack vector, because: 1. TCP SNs are usually moving. By default they don't need to, as that's part of the core ideology (thanks Postel!) but today they are usually moving. 2. Since connection has to be live before hand, servers request will be received by the client who will close the connection. 3. SNs provide only basic level of security, and this research proves, yet again for 35th straight year, that it's pretty good for what it is. 100+gigs of data just to be able to send a single packet over cleartext TCP is not bad at all. Universities and DCs may have this BW, but it isn't widespread. 4. This is just a bruteforce.

biot• 11 years ago

To add to the older evidence: http://www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf

barhun2• 11 years ago

i've been aware of this attack for about 10 years, how can it be a new finding? the following article was written in 1997.

http://www.citi.umich.edu/u/provos/papers/secnet-spoof.txt

barhun2• 11 years ago

the boy is 21 years old, forget it.

lgommans2• 11 years ago

Then again, I did read (parts of) the RFC from '81, some paper (from Morris iirc) about predicting the ISN from '85, lots of research in the 90's and early 00's regarding predictions and preventing it... but nothing actually just guessed the number, and people seemed to agree that "if the ISN is unpredictable then yeah it's secure right?" That's why I considered this a new thing.

lucb1e• 11 years ago

That involves "source routing" though (from what I get, that means controlling the route a packet will take, at least partially). I only see one ACK being returned, not multiple, so apparently the attacker is able to receive the SYN+ACK here. This means it's a different attack.

Smushman2• 11 years ago

Unfortunately for the author, this analysis is rooted in a faulty conclusion:

"Asking around, people assume the TCP handshake verifies the IP addresses on both sides."

Not true - in firewall and security circles this was long ago observed and addressed in many different ways - it is now standard in at least the major Enterprise Firewall Vendors.

Still though; the analysis is good, and clearly determined through work, observation, and sound logic. I would work alongside a person like this anytime.

If the author can find a venue to assert his findings he/she should, but I wouldn't expend too much time on it.

lgommans2• 11 years ago

Not true - in firewall and security circles this was long ago observed and addressed in many different ways - it is now standard in at least the major Enterprise Firewall Vendors.

Hmm, what kind of measures are taken against this, then? Because aside from ingress filtering for RFC1918 addresses and the like, I don't see how you could prevent this attack effectively. You could make it more difficult by rejecting wildly incorrect acknowledgement numbers, but I don't see how to really prevent it.

Still though; the analysis is good, and clearly determined through work, observation, and sound logic. I would work alongside a person like this anytime.

Thank you! :)

Smushman2• 11 years ago

I am most familiar with are in Checkpoint Firewall. They include several features that would limit this through session verification that tracks every packet, the sequence numbers associated (uses prediction), TCP flag states, etc.

When the attacker submitted sequence numbers that were not correct for the connection, it would send a TCP reset to both the client and the server; forcing the attacker to begin the attack sequence again with the first SYN. If it recognized a replay (sequence numbers used twice) like would happen here too, it would also reset the session. There are others as well such as packet data enforcement (if the packet data portions did not match up to a valid session) and session proxying too.

Lastly, it would lock out that attacker as a DDOS based on the traffic patterns (TCP sliding windows have been exceeded, or too much data in one direction and nothing returned).

The idea during design was that there are insecurities the TCP protocol inherently permits (like this one), how can we limit those. The answer basically is that if a session displays 'errant but technically permitted by RFC' behaviors, the firewall should force a reset on the connection.

If your conclusion at this point is can't this block valid traffic, the answer is yes it can, and these features are often turned off or limited for that reason.

Be aware that I have not pieced this together completely - it would take more detailed research and time to provide valid evidence - this is just off the top of my head over few minutes.

HTH...

suprjami• 11 years ago

Regardless of how new/old this is, shouldn't TCP Timestamps provide some degree of protection against this too? If the spoofing host's TSval is less than the real host's TSval, the spoofed traffic will just be dropped as being "from the past". I'm not immediately sure if there's a limit to how much "into the future" the next TSval can be.

Faking the TCP handshake

Related Stories