Re: [PEN-TEST] Exploiting sequence number predictability

["Todd, George" <gtodd () COREMETRICS COM>]

My two cents on blind tcp spoofing:

        There are several factors that lead to the impracticality of blind
tcp spoofing now days.  The first, and by far the most difficult, is that
most operatings systems pull entries from the entropy pool for the ISN.
Thus making it all but impossible to predict with any certainty the next
ISN.  A possible work-around to this (aside from targeting weak OS's) is to
attempt to deplete the entropy pool with multiple connections in hope of
getting the ISN to default to a pseudo-random number generator.  However, by
this time you should either have successfully dos'd the machine, or much
more likely been block by this machine.  Even so, pseudo-random number
generators still use internal timing mechanisms and such to generate it's
numbers.  Although I have heard recently of an article that talked on the
dual procession of these numbers before they are pulled (anybody ?).
        Also, on practical services to hit if/when you can predict ISN's is
rough.  While the r services and telnet-hijacking are likely choices, you
have to think.  If you are in a position to exploit trusted systems with the
r services, or to hijack an unsuspecting users telnet session, is there an
easier way in from here?
        Don't get me wrong, blind tcp spoofing can still be of viable use in
some cases.  In fact, a good majority of small office routers and older OS's
use the 64k rule or some trivial time-dependent method for their ISN's.
However, I wouldn't spend too much time investigating blind tcp spoofing
other than to synthesize it with the knowledge you already possess for a
more well-rounded approach to things.  Then again, I could be wrong.

Signed,
George Todd


-----Original Message-----
From: l0rtamus prime [mailto:simon () SNOSOFT COM]
Sent: Sunday, August 20, 2000 9:20 PM
To: PEN-TEST () SECURITYFOCUS COM
Subject: Re: [PEN-TEST] Exploiting sequence number predictability


I am interested in learning more about this subject.  I know nothing about
it and feel that I need to.   Does anyone have any documents that will
explain this to me from ground 0?


At 02:37 PM 8/18/2000 +0200, you wrote:
> Hi folks,
>
> I was wondering if anyone knew of any tools for exploiting predictable
> initial sequence numbers?  I understand the concept, and always see tools
> like nmap reporting on the quality of the ISN. But I am wondering how
> serious the vulnerability really is.  How easy is it to actually exploit
the
> weak ISN's?
>
> I've also used tools like hunt, for session hijacking, but that presupposes
> knowlege of the sequence numbers on the network, and doesn't really exploit
> the predictability aspect.
>
> Are there any tools around that exploit this, or are they mostly limited to
> custom tools written for a specific situation?  What level of skill is
> required to exploit a TCPWrappered telnet daemon, for example, assuming I
> know the username and password, and the exact banner and prompts?
>
> I imagine it is a case of:
> 1. determine the predictability algorithm (64k rule, or whatever)
> 2. Craft the packets required to execute the commands desired with the IP
> address of a permitted workstation.
> (packet 1 : SYN
>  packet 2 : ACK xxxxx/username^M
>  packet 3 : ACK xxxxy/password^M
>  packet 4 : ACK xxxxz/echo > /etc/hosts.deny; echo attacker >>
> /etc/hosts.allow; exit^M, or whatever)
>  where xxxxx-xxxxz are determined by the ISN, the number of bytes in the
> banner and login prompt, password prompt, and welcome banner/motd)
>
> (I can see why the R services are an easier target, cos you avoid all the
> variables in the login sequence, and can include your credentials and issue
> your command in the (same) second packet sent, I think)
>
> 3. Check where the target machine is in its sequence numbers by making a
> legit connection to, say echo, or whatever.
> 4. spam out a flood of packets that cover the range of ISN's based on the
> time between the target machine answering the legit connection, and your
> crafted packet arriving at the target.
>
> Is this how it works?
>
> Thanks.
>
> Sincerely,
>
> Rogan
> --
> In God we Trust -- all others must submit an X.509 certificate.
>      -- Charles Forsythe <forsythe () alum mit edu>
> --
> Rogan Dawes
> Deloitte & Touche
> Enterprise Risk Services
> Network & System Quality
>
> Tel:   +27 11 806 6216
> Fax:   +27 11 806 5202
> Cell:  +27 82 784 9498
> Email: rdawes () deloitte co za
> --
> NOTE:  This e-mail message and its attachments is subject to the
>        disclaimers as published at:
>        http://www.deloitte.co.za/disc.htm#emaildisc