> I'm agree that host authentication is the only real defense. I think
> network level encryption will defend against this kind of attack too.
> Transport level encryption might stop hijacking, but still vulnerable to
> DoS attack (the attacker might still able to put both hosts in
> desynchronized mode).
All true and very relevent. You COULD even encrypt most of the headers, but
this breaks things like NAT and proxy services.
> 1. How do we detect a hijack.
> Even in normal TCP conversation, there are lot of packets with
> invalid SN (duplication, etc.), so how we decide if an invalid packet is
> part of a hijacked session and which is not?
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.
> 2. How to determine which is the attacker and which is the victim.
> By using only TCP seq. num., we definitely CAN NOT decide which is
> the attacker and which is the victim, because a skilled attacker would
> most likely only send 'good' packet, making the victim looks bad. While
> a 'young' attacker probably still making mistakes on calculating SN,
> thus making both attacker and victim look bad.
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.
> By looking at route information in the packet (if available) will
> provide important clue, but still not reliable if your network use
> multiple route.
This really is a non-issue as just about all routers and hosts nowadays have
source-routing disabled. I realize that there is a possibility for
misconfigured boxes, but this is a reaching effort that generally does not
turn up anything. That is, a source-routed packet will set off too many
alarms and gives away all covertness of the attack.
> Looking at the H/W address of a packet won't help much, because
> you'll only see the gateway H/W address in the packet.
Actually, this is where you will see the mistakes of a 'young' attacker.
Calculating the SEQ/ACK # of a session is fairly straight-forward once the
highjacking has commenced: you just have to wade through all of the ACK
syncs between the two hosts. As I stated in another post, JUST ABOUT all of
the scripts/prgrams out there that do various forms of IP spoofing (I did
find an old SunOS forging tool in my archives that modified the MAC address of
the outgoing packet) do NOT address the layer-2 issue. Forged IP packets
from user space WILL STILL CONTAIN the source MAC address of the host used
to forge the packet. This is trivial to detect.
The "professional" hacker (the word professional used loosely here) will
have a modified IP stack that addresses this issue by swapping out the local
MAC with that of forged IP-layer-2 mapping. There are still some tricks to
catch this, the attacker just has to be careful on how this mapping is
obtained (this is part of my thesis, I've had to deal with this aspect quite
intimately!).
So, in a nutshell, LOOKING at the layer-2 information will turn up 90% of
the offending hosts performing ANY kind of spoofing attack.
There is also the analysis of the IP packet ID that I won't get into.
Although it can used be for detection purposes, it gives less information
on _who_ is doing the attack.
> 3. To make the situation worse...
> The attacker might send OOB packets, change route information, or
> other DoS attack to the victim. The firewall/IDS should aware that these
> are parts of the hijacking procedure, and terminate the victim's
> sessions immediately.
OOB packets aren't usually handled by the end host in the purest sense and
routers, by definition, don't accept redirects. Where do these aspects come
into play?
> Infact, if WheelGroup claims that their product can deal with TCP hijack
> attack, how the heck they're doing it?
Good question, any takers?
-J.
Follow-Ups:
References:
|
|
