Packet hijacking

[Red Squirrel]

Say you have a TCP session between point A and B, and a hacker is on point C, which is not in the path of A and B, I've heard it is possible for C to hijack A's packets when connecting to B and say, sending a password to login to a forum.

The way I was explained was that if you hammer A on an open port, the OS will get confused and start sending packets to the wrong host. I can't figure out how this would be possible as this all happens at a rather low layer and is contained withing a TCP session. If anything the packets will just get dropped.

How is this possible? This is basically what the hackers who can crack SSL do though I heard they also use a network called thor, which still, can't see how it would grab data from an outside path.

I'm not network/security expert but I know the basics of how stuff works, and the fact that this is possible really has me stumped. I thought the only way to sniff packets was to physically have access to the network path the packets are taking, or have something installed on a remote machine that is in that path.

 

[StormSide]

http://en.wikipedia.org/wiki/ARP_poisoning

http://www.irongeek.com/i.php?.../AQuickIntrotoSniffers

 

[Red Squirrel]

Isn't arp poisoning restricted to a single routing/lan segment though? As it involves mac addresses.

 

[n0cmonkey]

Originally posted by: RedSquirrel
Isn't arp poisoning restricted to a single routing/lan segment though? As it involves mac addresses.

Yes, arp is for local segments only. DNS poisoning can be a lot of fun, and doesn't require presence on the local network.

Haven't looked into the SSL stuff though, so I'm not sure how it works.

 

[n0cmonkey]

Marlinspike's SSLstrip sits on a local network and intercepts traffic. When it detects an encrypted HTTPS (Hypertext Transfer Protocol Secure) site, it automatically substitutes a look-alike of the intended destination as an unencrypted HTTP site. That switching trick strips away the security that prevents a third party from stealing or modifying data, while telling the server that an encrypted page has been sent.

From SSLstrip's page:

How does this work?

First, arpspoof convinces a host that our MAC address is the router's MAC address, and the target begins to send us all its network traffic. The kernel forwards everything along except for traffic destined to port 80, which it redirects to $listenPort (10000, for example).

I'm not sure if DNS cache poisoning would work in a similar way, my headache is preventing thought.