Posted by Jerry Stuckle on 01/21/08 22:56

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. This is all done by the transport layer, and
the web server has no idea what's going on.

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

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

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).

> You cannot *set up* a session without a valid return path.
>

But no session is needed. Just the request to the server. 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.

> 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.

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

> 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.

A correctly configured ISP will only accept IP's from its own CIDR. But
not all ISP's are properly configured.

> 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.

> 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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]