Re: Statistical (Birthday?) attack against TCP ISNs?

["Granquist, Lamont" <lamont () SCRIPTKIDDIE ORG>]

Another great idea dashed against the rocks of actually trying to code the
damn thing...

So, what I'm suggesting is that you'd flood the host with SYN packets with
idential ip_src, ip_dst, src_port, dst_port and seq and that ideally the
victim host would send back as many SYN|ACKs with different ISNs and
create table entries for all N connections you just tried to initiate.  I
doubt this actually works in practice, I expect you get the same ISN from
the victim host in the SYN|ACK every time.  However, perhaps not for SYN
cookies?  I don't recall much about SYN cookies other than the fact that
the target host does not build up any state in response to the SYN
request.  That would seem to imply that it would "forget" about SYNs and
transmit different ISNs in the SYN|ACKs in response to a SYN flood.  I
haven't sat down to figure out what would be involved in blind spoofing a
host that was implimenting SYN cookies.

On Sun, 18 Mar 2001, Granquist, Lamont wrote:
> Here's a thought on how to attack TCP ISNs irregardless of the strength of
> the PRNG being used:
>
> 1.  fill the listen() backlog of 32768 connections completely with
>     connections that have the same ISN (SYN flooding with the same
>     ISN)
>
> 2.  keep guessing reply ISNs and sending ACKs until statistically you
>     succeed
>
> The success of this would come after 2^32 / 2^15 = 2^17 (131,072) guesses
> of ACK packets.  You'd need to make sure the listen() backlog was kept
> full during this whole time.
>
> Problems:
>
> 1.  I'm not sure what happens when you SYN flood with packets that
>     have the same ISN -- you may not generate 32768 table entries.
>
> 2.  Do you even need to worry about the ISN that you sent in the SYN
>     packet?  I can't remember if we need to remember this or not, its been
>     a year or two since I've torn apart TCP connections at this level...
>
> 3.  SYN cookies?
>
> 4.  Anything that can take entries out of the listen() queue.
>
> I need hit Stevens a bit more to refresh my memory and answer these
> questions, but I thought I'd throw this out there.
>
> (And obviously this is all inspired by trying to figure out what Newsham's
> attack against TCP ISNs is...)
>
> I rolled up a little bit of perl to monte carlo simulate this and confirm
> that it would take about 2^17 tries to succeed.  I haven't actually tried
> this against a target TCP/IP stack though...