mailing list archives
Re: Tying a session to an IP address
From: exon <exon () home se>
Date: Mon, 10 May 2004 22:57:39 +0200
Mark Foster wrote:
Scovetta, Michael V wrote:
..."I'd say it doesn't do diddly squat to add to security, since it's
trivial to spoof ones address."
Is that really true? Is it trivial to spoof an arbitrary, specific
address? Can you make my traffic log think that you came from
220.127.116.11? Or 127.0.0.1? I agree that within a subnet or behind
a hacked router, sure, but at some point a router in the downline is
going to say, "WTF! I don't know about the 158.4 subnet, screw that!"
Unless I totally misunderstand the issues at hand in spoofing IPs...
Spoofing an IP address in a UDP packet really is trivial.
Spoofing an IP address in a TCP packet is also trivial, however with TCP
you have a "session" which relies and sequence numbers and windows for
packet-reassembly on the receiving end. So hijacking a HTTP session from
a spoofed address is not nearly as trivial since you'd need to know what
the sequence number and window sizes are for each packet in the
Hijacking a session is quite a different thing than simply spoofing ones
address, and for a HTTP session it would be even more so, considering
the fact that it is a stateless protocol (I'm not considering layer 7
stuff here), and that the data going TO the server generally is quite
small (i.e. few packets for guessing seq-number).
Even then it would be a one-sided conversation.
Naturally it would be oneway, unless the spoofing failed.
However I wonder if there are tools out there that make this type of
hijack possible and maybe even easy?
Probably not, for a number of reasons;
1. HTTP is a stateless protocol, which makes hijacking near enough
2. Hijacking requires you to be able to intersect the packets somewhere
between A and B.
3. Hijacking is more difficult nowadays, since seq-numbers hop around
more than the original SEQ++; routine used in older code. It IS still
possible to make calculated guesses at what next seq will be, but it's
definitely far from trivial.
- Re: Tying a session to an IP address [summary], (continued)