Vulnerability Development mailing list archives
Re: Statistical (Birthday?) attack against TCP ISNs?
From: "Granquist, Lamont" <lamont () SCRIPTKIDDIE ORG>
Date: Mon, 19 Mar 2001 00:26:32 -0800
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...
Current thread:
- Statistical (Birthday?) attack against TCP ISNs? Granquist, Lamont (Mar 18)
- Re: Statistical (Birthday?) attack against TCP ISNs? Granquist, Lamont (Mar 20)