Spoofing REMOTE_ADDR 1

[jimoblak]

Is this possible? How?

I have seen a few articles that note vulnerabilities in apps where HTTP_X_FORWARDED_FOR is preferred over REMOTE_ADDR (

http://seclists.org/bugtraq/2004/Apr/0235.html

). I have seen other articles about spoofing HTTP_REFERER but nothing about spoofing REMOTE_ADDR.

The vulnerability warnings about HTTP_X_FORWARDED_FOR are presented because the scripts are inappropriately favoring HTTP_X_FORWARDED_FOR over REMOTE_ADDR. This makes me think REMOTE_ADDR could not be spoofed (as easily or at all).

What security issues are there with displaying unique content to certain users based on REMOTE_ADDR?

Example:

if ($REMOTE_ADDR == '129.54.25.111') {
// Show the user something special
}

 

[sleipnir214]

Actually, as I'm reading the article, neither is necessarily reliable, but that some versions of phpBB relied blindly on X-FORWARDED-FOR, to their detriment.

REMOTE_ADDR, as exposed by PHP as $_SERVER['REMOTE_ADDR'], is provided by the web server. As I understand it, the web server gets the address from its IP stack, which in turn gets the values from the headers of the IP packets that make up the web request. However, if the user is hitting your server via a proxy server, all you will see in $_SERVER['REMOTE_ADDR'] is the IP address of the proxy server.

X-FORWARDED-FOR is a HTTP header that is arbitrarily set by some (but not all) proxy servers, so an attacker can inject a false header to fool software that relies to heavily on X-FORWARDED-FOR.



Want the best answers? Ask the best questions! TANSTAAFL!

 

[jimoblak]

The phpBB issue noted above seems to be an exploit for sending data to a server (ex: code or variable injection exploit), not intercepting a server's output. Spoofing an IP address (if possible) seems to be a one way street. I think I am driving the other way. For my situation, I just want to offer data to a specific IP address while hiding that data from all other addresses. There is no opportunity in my case for code or variable injection.

As I understand it, REMOTE_ADDR is the address of the client that the server is talking to - so spoofing that variable (if possible) might allow someone to send data to the server but the spoofer would not be able to read data returned from the server. The server is sending responses to the true 129.54.25.111, not to the spoofer who is only announcing himself as 129.54.25.111.

Am I understanding this correctly?

How is the code sample above be any different than setting up a firewall to only respond to connections from 129.54.25.111 on port 80? Is REMOTE_ADDR different than the IP address that any firewall would see?

 

[sleipnir214]

You are correct. Since REMOTE_ADDR comes from the web server via the IP stack, any spoofing of an address that happens across a routed network will also cause the return traffic to fail to get to its recipient. There are still ways, but it requires reconfiguring routers.

REMOTE_ADDR spoofing is much easier on your local network, since return traffic will be routed by the MAC address, not the IP address. An attacker could poison a switch's ARP cache, for example.

Whether you want to do this in PHP or at the firewall depends on how you want communication lockouts to take place. If you do it in PHP, a communication between an unwanted IP address and your computer still takes place -- it's just that your script sends a different data stream based on IP address. If you do it at the firewall, you can make your server look as though it's not even available on port 80 except to certain IP addresses.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[thedaver]

I'm sorry, but even after reading the article, WHY IN THE WORLD would one ever try to secure content distribution based upon the reported client IP address in any form?

Between inline content caches, transparent proxies, ARP poisining, router hijaaking, legitimate proxies, rogue proxies, MiTM attacks, and users who walk away from their desktops to get coffee, I simply cannot grasp why solving this would require deliberate management of "IP"-anything.

Why not sessions and/or SSL/VPN depending upon the nature of the data in transmission? The very MOST I would consider trusting the IP values would be as part of encoding a test string to store in the SESSION as part of an authentication scheme to provide an additional layer of insight over MiTM attack.

If the application is so broken as to need this kind of support then I'd ask the application owner to seriously reconsider the level of safety required of the data hosted within it. Otherwise you might as well publish the data in the Wall Street Journal.

Sorry to soap-box, it was too compelling not to blab.
Good luck.


D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[sleipnir214]

I'm sorry, but even after reading the article, WHY IN THE WORLD would one ever try to secure content distribution based upon the reported client IP address in any form?

And you forgot the common, everyday network activity tha will screw up that idea: pooled dynamic NAT. Every one of the 6,000 workstations in my school system go out as the same single IP.


But "why"? To quote the words of Robert Anson Heinlein: Never underestimate the power of human stupidity.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[jimoblak]

WHY IN THE WORLD would one ever try to secure content distribution based upon the reported client IP address in any form?

I believe in the linked article phpBB is using this method for banning purposes. Sessions and/or SSL/VPN are impractical when banning bad users on a forum.

For my purposes, I am developing a revision to a web site. index.php checks the REMOTE_ADDR and loads the original web site for the public. If it recognizes my own IP address, I see the new design.

I started this thread as I was uncertain of the security level involved with checking for REMOTE_ADDR to display specialized content. I appreciate the responses and look forward to learning more. Even if 'inline content caches, transparent proxies, ARP poisining, router hijaaking, legitimate proxies, rogue proxies, MiTM attacks, and users who walk away from their desktops to get coffee' are threats to the REMOTE_ADDR check, I suspect that this technique is still quite useful on a closed source system. phpBB's failing is that it is open source so it lets attackers know specifically how to break it. In any other situation, the attacker would need to know the following: 1) that they are missing specialized content because they are not accessing the site from the right IP address, 2) the IP address needed to access the specialized content.

Every one of the 6,000 workstations in my school system go out as the same single IP.

Wouldn't checking REMOTE_ADDR for this school proxy address on a public web server save you the trouble of managing 6000 different authenticated users to view a human resources section or employee guide not intended for the public?

 

[sleipnir214]

I suspect that this technique is still quite useful on a closed source system

Don't fool yourself into thinking that obfuscation and security are the same thing. Closed-source hasn't helped Microsoft any.

Wouldn't checking REMOTE_ADDR for this school proxy address on a public web server save you the trouble of managing 6000 different authenticated users to view a human resources section or employee guide not intended for the public?

Not necessarily. Tracking users according to IP and tracking users according to login overlap in usefulness, but they are not replacements for one another.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[thedaver]

jimoblak;

What I don't want you to come away from this thread with the impression that anyone here is NOT supporting your needs. I think what you're seeing are some strong suggestions that IP-based authentication, blocking, or stateful HTTP (based on IP) of any sort are NOT trustworthy.

The effort to compromise this kind of solution is not trivial in most cases, but I hope you've caught the recommendation (in the most positive of spirit) to not rely upon IP/network information as a means of assuring "security" using the layers discussed.

I wouldn't dare suggest that cookies/sessions are THAT much more effective (and as sleipnir suggests a combination/hybrid is better) than IP-based "security".

Ultimately it's your role to understand the risks introduced by certain approaches and to weigh the risk/benefit/effort to control your content.

So, after a long babble, I hope you've taken this feedback in a positive, constructive line to advance your solution in the direction you see fit with a better appreciation of risk/reward.

OK?

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[jimoblak]

Thanks thedaver, I am well aware and appreciative of what has been posted. Maybe I need to look at this another way with another question: What is REMOTE_ADDR used for then?

 

[sleipnir214]

REMOTE_ADDR is defined in the CGI (Common Gateway Interface) specification. The CGI spec is an old one that was never ratified by the IETF into an RFC -- the current effort to create an RFC is based on a draft spec that expired in 1997. The fine folks who created the less-than-formal existing CGI spec never anticipated public web proxies, ARP cache poisoning and the like.

You can use it to know the purported IP address of the client. The only time I've ever trusted it is when creating a private intranet part of a public website. I can know that if the REMOTE_ADDR of the client is a 10.x.x.x address, that machine is inside my network. And even then only because I have explicitly configured my firewall in such a way that any packets which claim to have origination addresses of 10.x.x.x and which hit the firewall's external interface are automatically dropped.

REMOTE_ADDR is to be taken like any other data that originates from outside your server -- with a grain of salt.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[thedaver]

REMOTE_ADDR, 'HTTP_X_FORWARDED_FOR'.... etc are obviously PHP methods to query the webserver as to what it thinks it knows about the client's point of origin. Trouble is with caches, proxies, anonymizers, NAT, and deliberate obfuscation of the "IP" addresses; you really don't gain much, IMHO, by parsing the information unless you have the mindset that you DON'T trust the information beyond a certain level of utility.

OK, but let's build a discussion that trusts a significant proportion of these values being legitimate... Then you can use them for geographic caching/load balancing, guesses at default localization of language/display.

Trouble there is that the IP ranges assigned to ISPs and even continents/countries are subject to constant change (though it's mostly stable), so you're left to herding cats in trying to "geo-" anything with the highest level of reliability.

One method I mentioned in preventing Man-in-the-Middle attacks (and it isn't even that good) is to embed a string value in your session that is a combination of strings "username+IP+browser agent" and run it through MD5 for storage.

That string is going to be pretty unique and can be computed in the course of determining if the client you started the session with is still the client you want to talk to. It's NOT foolproof, but it can combine with user/password authentication values to raise the level of assurance a little bit without escalating to hardware tokens, SSL certificates, etc.

Is this what you were curious about or have I wandered off into the weeds a bit too far?




D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[sleipnir214]

Let me sum up my philosophy on REMOTE_ADDR: it all comes down to positive identification and negative identification.

In situations, such as my example of an internal-network-only intranet part of a public website, I can use REMOTE_ADDR as positive identification to allow only certain machines in. I have locked down my network enough that I can trust the REMOTE_ADDR datum for positive ID. That doesn't mean, though that REMOTE_ADDR is my only means of ID. Since I know an unautorized entity could plug a laptop into my network, there are some parts of my intranet that also require logins.

In most other situations, I can not explicitly trust the value of REMOTE_ADDR, so I can only use it for negative identification. I can block a particular IP address and let everyone else in because no one is going to deliberately spoof their address to a blocked one.

It's like Ronald Reagan's comment about trusting the Soviet Union to hold up their end of a nuclear disarmament treaty: Trust, but verify.


Want the best answers? Ask the best questions! TANSTAAFL!

 

[audiopro]

Another example of a safe use for it is to block my IP address from my web logs. I want to know what other people are doing on my sites, not me.

Keith

http://www.studiosoft.co.uk