> > The duplication is not as severe as you would see with a hijacked session.
> >You will generally see several hundred ACKed packets thrown around for each
> >new packet introduced by the hijacker.
>
> It seems to me that an expert attacker would have no problem in taking over
> the session without producing a couple of hundred of unexpected ACKed packets.
The point was that the attacker himself does not participate in the ACK food
fight. Its a result of the two valid endpoints that are in a desynced
state: one is trying to tell the other what its idea of the current state
the connection should be. A dropped packet is the only way to end this
spat, given reliable network stacks on an unreliable medium.
> > This is true if you look at only a single ACK on one side of the stream. If
> >you compare the ACKs from both sides, you can see the side that has been
> >spoon-fed data by the attacker as their ACK # will be higher than the
> >supposedly corresponding SEQ # of the unmolested side. This is due to the
> >fact that the SEQ/ACK pair is based solely on the # of bytes sent/received
> >after the session has been established.
> > This pair is by no means a security mechanism in the purest sense. It is
> >used primary to keep the sides in synch with one another. The fact that
> >it prevents accepting data out of order is really just a security side
> >effect inherent with connection-oriented bitstreams.
> >
>
> If the "good-guy"'s system on the remote side is brought to its knees (via
> a Denial-of-Service attack, etc.), then there is nothing really to compare
What denial of service attacks prevent a host from responding to flows that
are already in a CONNECTED state? Okay, the F00F bug just made the
headlines, but there are a large number of other types of boxes out there
that you just simply can't lock up. Heck, before the F00F storm, what could
you do to lock up x86 boxes with the type of DoS you describe?
> against. Also, it is trivial for seasoned hackers to supply the Sequence
> Numbers as well as pretty much any other info you would expect to find in
> the packets.
The information forgery is a given from the evil side. You simply cannot
get around (as the attacker) what the unsuspecting hosts will spit out onto
a shared medium. Whats the multicast paradigm? "Anybody can send, receivers
just selectively ignore." So here, the receiver (monitor) "decides" to
listen everybody.... what's an attacker to do?
-Jason
|
|
