Posted by The Natural Philosopher on 01/22/08 03:32

Jerry Stuckle wrote:
> The Natural Philosopher wrote:
>> Jonas Werres wrote:
>>>> Nothing at all to do with PHP.
>>>
>>> I think you did not understand what I wrote.
>>>
>>> The OP asked if one can spoof the IP address while requesting a
>>> document.
>>> Jerry says (correctly) that it would not be possible to get the
>>> answer. That might imply that is IS possible to make a request, but
>>> the answer goes nowhere. That would be enough if the purpose of the
>>> request was e.g. to delete a database by SQL injection. The answer is
>>> unimportant.
>>>
>>> What I said was that I think it is not even possible to make a
>>> request (regardless where the answer would go), because that would
>>> require a connection which cannot be established with a spoofed IP.
>>
>>
>> A request implies an open TCP connection, which implies that a session
>> has been set up.
>>
>
> Not the way TCP/IP works. You can send up to 7 packets before an ACK is
> required by the sender.

Not on connection open you cant. and its not 7 either.

It can be actually as big a chunk of data AFTER you have opened the
session as allowed in the session TCP window.


> This is all done by the transport layer, and
> the web server has no idea what's going on.
>
Quite. And if its not done right the web server will never see it
either. The transport layer will simply discard it.


> In that 7 packets you can get several pieces of information. It will go
> to the web server and be processed.
>

No, it won't. It won't go anywhere at all unless it is recognized as
part of an established TCP/IP connection. To do that is a lot more than
just having the right destination address and a spoofed source address.
It needs to correspond to an established source port number and be in
the sequence of packet number associated with that stream ID.




> The web server doesn't reply until it gets the HTTP request - which can
> be much later.

Indeed. So how come it has just 'recieved those 7 packets of data and
processed them'

Even in the context of your own words, you are contradicting yourself.

>
> If the web server's TCP/IP doesn't get the packet, obviously the ACK
> won't be returned. So after a timeout period, the sender's TCP/IP
> resends it (if, instead, the ACK got lost on the return, it is the web
> server's TCP/IP which sorts it out).
>

Oh dear.
>> You cannot *set up* a session without a valid return path.
>>
>
> But no session is needed. Just the request to the server.

That comes over a valid TCP IP CONNECTION, or SESSION.

In fact, as
> far as TCP/IP goes, there is no such thing as a "session". Each packet
> is sent independently, and successive packets may very well take
> different routes.
>

What has that got to do with there being an established connection?I.e.
session?

Jerry. Listen up sweetie pie, Just go here and educate yourself so you
don't look quite such a dork next time.

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



>> That is, you would never get as far as being able to send a request to
>> a server, since that must be done over and establsihed session.
>>
>
> Nope. The server gets the request and tries to reply. Now obviously
> the server's TCP/IP probably won't get an ACK from the reply because the
> message went to a bogus IP address, but eventually after retrying the
> web server's TCP/IP will return a timeout to the web server.

Jerry,. don't open your mouth any wider than is necessary to put both
feet in.

Hint. ChecK out SYN, ESTABLISHED, TCP WINDOW SIZE, SOURCE PORT and other
magic spells in the spellbook I pointed you at.

>
> However, this isn't done until after the web server replies to the
> request - which is after processing for the page has been completed.

No, it will neverr get that far.

If its a SYN packet, a request to OPEN a TCP connection, the server will
return it to where it thinks it came from. But thats all. If its marked
ESTABLISHED, uneless therE IS an established session - i.e. an ongoing
TCP/IP conversation with the server from the spoofed address, it will be
discarded as out of sequence, and/or unknown. The key here is that every
time the bowser opens a TP connection, it uses a random port. That port,
and that source addrss, together form a unique ID as far as the server
is concerned. Every packet in that connection is numbered. To get to the
WEB server, you have to guess the right port, the right IP address and
the right sequence number of a conversation that is HAPPENING ALREADY.
And since the HTTP protocol closes the comnectiuon after EACH request,
you have a pretty damn narrow time window to do this in.



>
>> IP spoofing as far as I can think, can only be utilised if one has
>> admin level access to routing. Typically if uou are on the same
>> NETWORK as the address you are spoofing, or in control of a router
>> between it and its target.
>>
>> i.e. if you sit at an ISP, and stuff in a piece of kit on someone
>> elses IP address, and do clever things with a core router, you MIGHT
>> be able to patch a route to that address into the ISPs routers.
>>
>
> You don't have to be at an ISP to do it. You could actually do it on
> your own system, with the right tools and know-how. All you need is an
> ISP which will accept packets with an illegal address.


Oh, if all you want to do is throw noise into the system, sure. No one
checks *source* addresses anyway as far as routing goes. No pint, since
the rest of the protocols make it a fairly pointless thing to spoof them.
>
> A correctly configured ISP will only accept IP's from its own CIDR. But
> not all ISP's are properly configured.

Total crap. What about packets coming from across the far side of the
world and using them as transit?

Once you are unto the Internet core you route anyone's packets from
anywhere. Off your network as fast as you can..;-)

>
>> I don't actually know if this has ever happened outside of e.g. a
>> large campus network where security was pretty lax. It would be an
>> instant firing if an ISP admin did that.
>>
>
> Yes, it has. You don't hear about it very often because it's of very
> limited use on the web.
>
>> Or possibly someone sniffing a wifi network could grab some login
>> details to a site..not easy, but possible, and spoof via that.
>>
>
> That's also possible, especially if the wifi network is using no
> encryption (even WEP is very poor security). Again, anyone with the
> correct tools can watch each packet going over the network; if it's not
> encrypted, everything can be read.
>

Sure,. Thats Wifi for you. But that LAN rather than WAN issues.

>> Network layer code is pretty robust: its much easier to hack using
>> application layer exploits.
>>
>>
>
> It's robust, but that doesn't mean it can't be fooled.

Not as easily as you seem to think some readers here can be, anyway ;-)

>

[Back to original message]