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

11–20 of 35 posts

Re: Faking the TCP handshake

#11

Post by armitron »

tptacek wrote: post #10
armitron wrote: post #9

Earlier quoted context omitted.

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.

Re: Faking the TCP handshake

#12

Post by peterwwillis »

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/

Re: Faking the TCP handshake

#13

Post by tptacek »

armitron wrote: post #11
tptacek wrote: post #10

Earlier quoted context omitted.

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). Th…

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.

Re: Faking the TCP handshake

#14

Post by laumars »

armitron wrote: post #7
wtbob wrote: post #6

Earlier quoted context omitted.

Perhaps what's new is that it is so easily exploitable? 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.

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.

Re: Faking the TCP handshake

#15

Post by jacquesm »

armitron wrote: post #7
wtbob wrote: post #6

Earlier quoted context omitted.

Perhaps what's new is that it is so easily exploitable? 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.

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.

Re: Faking the TCP handshake

#17

Post by fulafel »

tptacek wrote: post #13
armitron wrote: post #11

Earlier quoted context omitted.

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). Th…

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.

Re: Faking the TCP handshake

#18

Post by samfpetersen »

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…

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

Re: Faking the TCP handshake

#19

Post by [deleted] »

armitron wrote: post #11
tptacek wrote: post #10

Earlier quoted context omitted.

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). Th…

[deleted]

Re: Faking the TCP handshake

#20

Post by SFjulie1 »

armitron wrote: post #4

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:…

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

Post reply on HN