Faking the TCP handshake(lgms.nl)
lgms.nl
Faking the TCP handshake
http://lgms.nl/blog-2
11 comments
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.
I think it depends on how you read the article. The most charitable reading is that the authors couldn't find a source for probing the whole ISN space, and believe that variant of the attack is novel. I think you have to be a bit uncharitable to assume they're claiming the whole concept of blind TCP spoofing.
I would cut them a lot more slack if they mentioned that their method doesn't work in the vast majority of networks today (assuming one wants to cross networks with it), due to egress filtering. If one is already present locally, and can send spoofed packets, there are far better attacks to try than sending tens to hundreds of gigabytes of data for a single spoofed connection (that will be immediately terminated).
Their method doesn't even attempt to keep the connection going.
Anyone with network experience would see the bruteforcing method as elementary and common knowledge really, it's nothing new.
In short, amateur hour.
Their method doesn't even attempt to keep the connection going.
Anyone with network experience would see the bruteforcing method as elementary and common knowledge really, it's nothing new.
In short, amateur hour.
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.
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.
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.
[deleted]
It's different: The old was attacking weak randomness, this is showing easy brute forcing.
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
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
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
Also see:
http://phrack.org/issues/64/13.html
Perhaps what's new is that it is so easily exploitable?
I remember when 32 bits seemed huuuge, and now … not so much.
I remember when 32 bits seemed huuuge, and now … not so much.
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.
Counting on the attacker's own network to have egress filtering stopping his attacks, isn't that a bit like discounting spam because most networks filter outbound SMTP?
If your defenses are predicated on the assumption that you aren't going to encounter bad stuff due to filtering at the source, you are in for a bad time.
If your defenses are predicated on the assumption that you aren't going to encounter bad stuff due to filtering at the source, you are in for a bad time.
> 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 article "dumb" is just unnecessary language. It doesn't contribute anything and yet could discourage authors from publishing future work.
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 article "dumb" is just unnecessary language. It doesn't contribute anything and yet could discourage authors from publishing future work.
Anti-spoof measures are really only effective close to the edge, further in packets are routed with abandon because of overhead and difficulty in verifying the origin.
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:
A fun look at sequence number PNRGs of various (old) OSes: http://lcamtuf.coredump.cx/newtcp/
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].
A fun look at sequence number PNRGs of various (old) OSes: http://lcamtuf.coredump.cx/newtcp/
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.
"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.
> 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! :)
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! :)
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...
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...
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
http://www.citi.umich.edu/u/provos/papers/secnet-spoof.txt
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.
the boy is 21 years old, forget it.
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.
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.
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.
See also http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-con...
> 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.
See also http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-con...
To add to the older evidence: http://www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf
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.
https://en.wikipedia.org/wiki/TCP_reset_attack
So I doubt this is a new finding.
who remember Mitnick and rsh?
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.
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