On Sat, 30 Dec 1995, Darren Reed wrote:
> > Wait. Where are you caching it? If I am on your subnet sniffing all of
> > your packets, I can see them going out, and I can see the ACKs coming back.
>
> Firewall.
But if I am on your subnet, then I can see ALL packets. I can make mine
INDISTINGUISHABLE from the real machine's... unless I am totally missing
something here, how would it be possible to tell which machine produces
those 1's and 0's if they are identical?
> > Basically it sounds like you are caching the packets, both the hijacker's
> > and the real ones, and looking inside the data portion of the packet.
> > How are you going to make judgements based upon the data to determine
> > which are "good" and which are "bad" since the headers should be exactly
> > the same between the two packets. What are you going to look for?
>
> No, don't look inside the data bit. Just look at the ACK/SEQ numbers.
Yes, but *I* am getting the ACK SEQ numbers as well, and in most cases,
if the increase in SYN #'s is consistant I can predict, upon reciept of
the last packet with 100% certainty what the next packet's seq.#'s are
going to be. I can do this because I am sniffing and creating packets on
the fly. The packets that I create are consistant with the numbers
coming in from the other machine, because I am taking the numbers right
off of those headers in real time, adding 1 (like TCP does when ACKing),
and using the incoming packet's sequence number (plus 1) as my ACK. This
is EXACTLY what the firewall is expecting to recieve, and I am giving it
what it expects. Now, how can it tell that mine is not correct? To get
mine there first, all I have to do is ping flood or something similar the
REAL machine for a split second while I insert the FIRST of my packets
into the stream. After that the REAL machine will always be AT LEAST 1
ACK behind, and his ACKs will be rejected, until I quit hijacking the
session.
> If you have one packet saying "I haven't sent any more data" after receiving
> data and checking with the claimed sender, they you have reason to dump it.
> I'd say one negative would be enough to make this decision. How do you know
> what the right ACK/SEQ numbers should be ? Keep track of state/connection
> flow for a TCP connection (which is what I hear FW-1 does).
I am actively sniffing their packets. I can see the whole thing, from
data to seq. numbers, ports, etc., etc.
The sequence numbers are no problem.
>
> This assumes the hijacker is taking over an idle connection or tries to
> insert data which doesn't match the current flow.
No, you can take over an active connection. As far as matching the
current flow, well it depends on what they are doing. If they are
telnetted into a machine and are sitting at -bash but not necesdsarily
idle then I can do anything and it will go unnoticed. Besides, if I pipe
the packets to a display, I can see exactly what they are doing. I cna
then automagically send the correct packets to match. If they are
telnetted into joe.com, and ftp'ed as root to fred.com and I hijack their
session, I can simply issue a put command and put an .rhosts file in
there, or I could quit, and put an .rhosts file or something like that
(or change the passwd) on the joe.com account.
>
> Right. Now, given the above scenario, you might include a flood of TCP
> packets against a single port as part of a detection scheme.
That would probably be the best indicator, however, all it takes usually
is 8 packets. You gotta be careful too, or you will set off false
alarms, or the opposite. Better safe than sorry, though.
> This presumes your packet is used instead of the other. ie you want yours
> to get their first, so you watch and predict the next data packet size.
> Watching isn't enough for this because yours will then always be (unless
> the other is dropped) juat another duplicate. I guess you could always
> try influence what gets dropped...(see above).
Well, if yours gets there first, then the other one will be the one that
gets dropped as a duplicate.
Brain21
Follow-Ups:
|
|
