Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faking the TCP handshake

lgms.nl

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Faking the TCP handshake

#21

Post by jessaustin »

samfpetersen wrote: post #18
laumars wrote: post #14

Earlier quoted context omitted.

> It's dumb is what it is. Steady on there. The author has clearly done a lot of work on this and while your points are valid, that this method of attack isn't new nor practical, he has still learned a very genuine potential vector for attack. Thus it deserves a mature discussion since there will certainly be others who might learn from the author's research. I'm all for constructive criticisms, but calling his artic…

SOP for this site: 1. Read content 2. Think of a reason to disparage it 3. Disparage it in a comment 4. Suck own dick

Ouch it won't reach my mouth; If I could do it myself I'd probably never leave the house.

Re: Faking the TCP handshake

#22

Post by abpavel »

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.

Re: Faking the TCP handshake

#24

Post by AnthonyMouse »

fulafel wrote: post #17
tptacek wrote: post #13

Earlier quoted context omitted.

Since TCP spoofing is essentially an academic concept at this point --- even if you could do it in milliseconds, it wouldn't be very useful --- I'm not sure the practical baggage or refinements you're talking about are that important. Also, I think RPF filtering is a little less common than you're implying that it is.

Why not useful? In my experience setups involving IP ACLs for TCP services are pretty common in the wild. As well as risk-assesments talking about the relative rarity of on-path attackers, predicated on TCP security against off-path attackers.

Risk assessments making bad assumptions is not a new thing.

People are always advocating egress filtering because "if only everybody would do it ...", but it's a classic tragedy of the commons. Egress filtering doesn't meaningfully help the network doing it and it may cause ugly problems with asymmetric routes and the like, so the number of networks that don't do it is large enough to be meaningful. And if you get close enough to the core of the internet it's basically impossible anyway because there is no practical way to keep track of which address ranges a particular interface should legitimately be sending traffic from when the list encompasses half the address ranges on the internet and can change at any time.

The upshot being it's not at all difficult for an attacker to get hold of a connection that doesn't do egress filtering, and that isn't ever going to change.

Re: Faking the TCP handshake

#26

Post by barhun »

barhun wrote: post #25

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

the boy is 21 years old, forget it.

Re: Faking the TCP handshake

#27

Post by Smushman »

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.

Re: Faking the TCP handshake

#28

Post by zurn »

armitron wrote: post #9
tptacek wrote: post #8

Earlier quoted context omitted.

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.

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

It's different: The old was attacking weak randomness, this is showing easy brute forcing.

Re: Faking the TCP handshake

#29

Post by pg_is_a_butt »

laumars wrote: post #14
armitron wrote: post #7

Earlier quoted context omitted.

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.

> It's dumb is what it is. Steady on there. The author has clearly done a lot of work on this and while your points are valid, that this method of attack isn't new nor practical, he has still learned a very genuine potential vector for attack. Thus it deserves a mature discussion since there will certainly be others who might learn from the author's research. I'm all for constructive criticisms, but calling his artic…

i'm all for constructive criticisms, but calling his calling of the article "dumb" as "unnecessary language" doesn't contribute anything.

your ignorant hypocrisy is dumb.

Re: Faking the TCP handshake

#30

Post by suprjami »

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.
Post reply on HN