IPS Leaking backend IP's

[OctoDev]

Honestly, I don't know if this needs much explaining.

Many users are using 3rd party services like CloudFlare & sucuri, or other reverse proxy services. The main reason due this, is to 'Hide' the backend server IP Address from attacks such as DDoS, or Rooting. However, IPS is actually exposing the backend IP Address in multiply ways for users like me.

 

 

Here are some ways that are leaking the IP Address on IPS 3.4:

1. Inputting a IP Logger URL, as Avatar URL (There is no option to disable this).
2. Inputting a IP Logger URL, as Signature image (There is no way to 'proxy' the image check on a remote server)
3. Using Image Proxy (There is no way to use a remote server, once again to check the image / cache).

 

I think ways to fix those holes:

1. Option to disable image url input as Avatar.
2. & 3. Option to use a remote file/api to cache, example enter domain: proxy.domain.tld/api.php?url=

 

 

I hope that something gets done about this, i think it's rather a serious concern atm.

If this is a public forum that guests can also access & non-customers, maybe move it? Since this would expose the backend IP Address of any server running IPS, which is quiet bad and can result in sites getting hacked, or ddos'd. 

[Charles]

This is not something our software should "solve" as it's not really a problem. If you are that concerned about what you call IP-leaking then you have two options which are the proper way to handle this and what you should do as best practices for your web server security:

1. simply configure your server to only accept inbound connections from your proxy service. That way it doesn't matter what someone might discover as it won't respond to their connections.

or

2. do not assign a public IP to your servers and use an internal proxy to serve content. We do this for our larger clients we host. The array of web servers do not even have a public IP to connect to so it's a non-issue.

 

Relying on the application level to ensure server security is not good practice. By the time traffic gets to the application, be it our software or any other, it should already be safe and any response the software could possibly make should not create a security problem like you're describing.

[OctoDev]

7 minutes ago, Charles said:

This is not something our software should "solve" as it's not really a problem. If you are that concerned about what you call IP-leaking then you have two options which are the proper way to handle this and what you should do as best practices for your web server security:

1. simply configure your server to only accept inbound connections from your proxy service. That way it doesn't matter what someone might discover as it won't respond to their connections.

or

2. do not assign a public IP to your servers and use an internal proxy to serve content. We do this for our larger clients we host. The array of web servers do not even have a public IP to connect to so it's a non-issue.

 

Relying on the application level to ensure server security is not good practice. By the time traffic gets to the application, be it our software or any other, it should already be safe and any response the software could possibly make should not create a security problem like you're describing.

 

Well, I don't relay on either but I don't want anyone to have my backend IP Address. They simply have no need to, and i didn't think that IPS would be the one "leaking" it. Should at least be a option to disable the upload image via url for avatar.

You wouldn't say "secure it better, and not depend on others" if your site were hit by a 100Gbps DDoS Attack. Even with ddos protected providers, it's a struggle to handle large attacks. 

[Colonel_mortis]

I reported this issue to IPS privately in December, and they decided to mark is as a non-issue.

The only thing that you can do about is is making a plugin to proxy traffic via an external server, so that an attack would only take down the external requests capacity of the site. Ideally, this would be a stock feature, but I doubt that we will see that, despite the fact that even this site is affected by the vulnerability.

[Rheddy]

I have to admit that I find myself agreeing with @Charles on this point. Unfortunately, this isn't something that is IPS' problem. Either you have to properly configure your server or servers or you need to contact your webhost regarding this problem. If your backend IP address is being leaked, then that is something that is coming from your server/webhost, not from the IPS software. The only way I could see if this was something on IPS' end is if you were hosting your site through IPS' cloud services.

What I would suggest is that you look into security services provided by your webhost. There are services such as SiteLock that provide such services to websites.

[Colonel_mortis]

Just now, Morisato said:

I have to admit that I find myself agreeing with @Charles on this point. Unfortunately, this isn't something that is IPS' problem. Either you have to properly configure your server or servers or you need to contact your webhost regarding this problem. If your backend IP address is being leaked, then that is something that is coming from your server/webhost, not from the IPS software. The only way I could see if this was something on IPS' end is if you were hosting your site through IPS' cloud services.

What I would suggest is that you look into security services provided by your webhost. There are services such as SiteLock that provide such services to websites.

No, the problem is that the IPS software is making an excessive number of user-triggered external requests (such as any time you post a link), so it is trivial for an attacker to obtain the IP address of the server, and very difficult to mitigate. Ideally, most of the things that are done by external requests from the server now should be done client side, but for some reason IPS has decided not to make that an option.

[Jswerv3]

3 hours ago, Jimmy Gavekort said:

Honestly, I don't know if this needs much explaining.

Many users are using 3rd party services like CloudFlare & sucuri, or other reverse proxy services. The main reason due this, is to 'Hide' the backend server IP Address from attacks such as DDoS, or Rooting. However, IPS is actually exposing the backend IP Address in multiply ways for users like me.

 

 

Here are some ways that are leaking the IP Address on IPS 3.4:

1. Inputting a IP Logger URL, as Avatar URL (There is no option to disable this).
2. Inputting a IP Logger URL, as Signature image (There is no way to 'proxy' the image check on a remote server)
3. Using Image Proxy (There is no way to use a remote server, once again to check the image / cache).

 

I think ways to fix those holes:

1. Option to disable image url input as Avatar.
2. & 3. Option to use a remote file/api to cache, example enter domain: proxy.domain.tld/api.php?url=

 

 

I hope that something gets done about this, i think it's rather a serious concern atm.

If this is a public forum that guests can also access & non-customers, maybe move it? Since this would expose the backend IP Address of any server running IPS, which is quiet bad and can result in sites getting hacked, or ddos'd. 

 

I reported this issue to IPS a while ago, and I literally sent them their own IP address using that avatar URL logger method - luckily you can just quickly disable that function.

[Colonel_mortis]

51 minutes ago, Jswerv3 said:

 

I reported this issue to IPS a while ago, and I literally sent them their own IP address using that avatar URL logger method - luckily you can just quickly disable that function.

That doesn't fix it though - if you paste any URL (or maybe just any image URL), the server will make an external request to that URL, which can easily be logged.

[MADMAN32395]

1 minute ago, Colonel_mortis said:

That doesn't fix it though - if you paste any URL (or maybe just any image URL), the server will make an external request to that URL, which can easily be logged.

Yes. It would have to make a request for that image. So which ever device makes that request with its public IP will be sent. 

If you're worried about outbound traffic as well. Find a provider to hide that as well. It's not a application flaw. It's server setup.

[Colonel_mortis]

Just now, MADMAN32395 said:

Yes. It would have to make a request for that image. So which ever device makes that request with its public IP will be sent. 

If you're worried about outbound traffic as well. Find a provider to hide that as well. It's not a application flaw. It's server setup.

Not whichever device makes the request, but your server. There is no reason why the requests need to be made by the server when they can just as easily be made on the client side, which would reduce bandwidth usage and server load, and also prevent your IP address from being leaked.

A significant number of sites use services like Cloudflare and Incapsula, which are completely useless if you obtain the IP address of the server. While it is possible to work around the issue using an outbound proxy (as I have done on my site), that should not be necessary, and the benefits of it being required by IPS are almost non-existent.

If nothing else, IPS should make this vulnerability clear to clients - I wouldn't have discovered it if I hadn't been looking at the code to try and figure out some other issue.

[OctoDev]

Glad others agree then, seems like they just push it away and say it's not their problem. Well, technically is when we have no option to disable such. They removed the option in 3.4, however 3.4 also had same ways for signature and other stuff. But they at least had a option to disable avatar remote url  

How can you tell me that having backend IP Address has something to do with my host? Please do some research before you leave replies here, or at least know what you are talking about. 

1 hour ago, Jswerv3 said:

 

I reported this issue to IPS a while ago, and I literally sent them their own IP address using that avatar URL logger method - luckily you can just quickly disable that function.

Not really. There is multiply stuff that requires patching on 4.1

 

• Avatar Uploader
• Signature
• Anything else, perhaps even posts + image proxy caching.

[MADMAN32395]

1 minute ago, Colonel_mortis said:

Not whichever device makes the request, but your server. There is no reason why the requests need to be made by the server when they can just as easily be made on the client side, which would reduce bandwidth usage and server load, and also prevent your IP address from being leaked.

A significant number of sites use services like Cloudflare and Incapsula, which are completely useless if you obtain the IP address of the server. While it is possible to work around the issue using an outbound proxy (as I have done on my site), that should not be necessary, and the benefits of it being required by IPS are almost non-existent.

If nothing else, IPS should make this vulnerability clear to clients - I wouldn't have discovered it if I hadn't been looking at the code to try and figure out some other issue.

You know this is an issue with any software right (like email servers, any forum software). Isn't a fault of ips. It's like asking IPS to build you a bicycle.

[Rheddy]

I think I know what @Colonel_mortis is talking about but I don't see as big a problem with this as he does. Someone, a guest, will try and trigger something by either attempting to log into an administrator's account or trying to create content as a guest. Since I don't allow guest posting, the IPS software triggers an alert, sends me an email that a user has triggered an error, and logs their IP address and what they tried to do (along with the user account if they are trying to gain access). This information is only passed along to the email address associated with administrator/owner of the site. I've opted just to start banning IP addresses if someone tries to gain access to an administrator's account.

I hate to be the one to foreshadow bad events, but this is exactly what I warned IPS that would happen when they removed the ability to create usernames and display names. I don't want to stir up any trouble here but now that Colonel_mortis has reminded me of those error emails I keep getting from guests trying to gain access to my admin account, they've deliberately left anyone who uses the IPS software vulnerable to hackers.

Before, with IPS 3.x, a user could register for an account and set a display name that's different from their login username. With IPS 4.x, IPS has made the system far too easy for any hacker to access your admin account. What am I talking about? With IPS 3, someone would need your login ID and your password in order to gain access to your account. With IPS 4, IPS has done half of the work for the hackers by displaying your account username and all they need to do is guess your password. I have a secondary administrators account on my site and I would say that in the past month since I upgraded from IPS 3 to IPS4, there have been dozens of attempts to hack that admin account.

I think IPS needs to seriously consider improving account security with the IPS software by bringing back the username/display name feature.

[Randy Calvert]

As someone who works for a major cloud security company, I can also agree with Charles.  

The right way to handle this is before it gets to your front door.  In terms of security, if you're fighting the battle at your front door you should be expecting to have collateral damage.  

In terms of securing your application, you should be creating ACLs to restrict what addresses can reach out to your origin infrastructure (meaning your hosting company).  If you're using Cloudflare, this list is published at https://www.cloudflare.com/ips/.  You should configure your firewall (preferably one that sits in front of the web server) to accept requests only that have come through your cloud security company and those addresses that you implicitly trust (such as your personal IP address).

Counting on hiding the address is basically security by obscurity and not an effective approach to protecting the origin.  

The customers that I support typically have a configuration similar to:

CDN/Cloud Security > ISP (including ISP level scrubbing to protect non HTTP/HTTPS DDoS traffic that the CDN/Cloud WAF provider can't stop) > Border Firewall > Load Balancer > Proxy Server (depending on the load, this may not exist > Web Server > Database Server

Anything behind the load balancer does not have a public facing IP address.  It's simply the address of the traffic manager.  For those that don't have a LB, your best bet is to create an ACL (access control list) to block any traffic that is not coming from the cloud service provider.  The higher up you can put that ACL, the better.  (For example, can your hosting provider put the ACL on their firewall or router?  If so, that prevents your local box from having to make the decision of dropping the traffic or not.)

[Colonel_mortis]

2 hours ago, Randy Calvert said:

CDN/Cloud Security > ISP (including ISP level scrubbing to protect non HTTP/HTTPS DDoS traffic that the CDN/Cloud WAF provider can't stop) > Border Firewall > Load Balancer > Proxy Server (depending on the load, this may not exist > Web Server > Database Server

These are forums we're talking about, a significant number of which are small enough not to be able to afford that kind of thing, but large enough to be a target. This site, which is probably one of the sites that would most significantly impact the owners if it went down, has not mitigated direct IP access in any way.

Yes, there are things that can be done, but the most effective way of preventing a DDoS attack is to not give away your IP address in the first place - there's not much else you can do to prevent a layer 3 or 4 attack without spending quite a lot more money.

My argument is that IPS doesn't need to be making most of the requests that it is currently making (they should be done client side instead), which would have multiple advantages and not much in the way of disadvantages as far as I can see

[OctoDev]

3 hours ago, MADMAN32395 said:

You know this is an issue with any software right (like email servers, any forum software). Isn't a fault of ips. It's like asking IPS to build you a bicycle.

No. I use remote mail servers especially for this, but that doesn't help when entire IPS is leaking IP's.. 

2 hours ago, Randy Calvert said:

CDN/Cloud Security > ISP (including ISP level scrubbing to protect non HTTP/HTTPS DDoS traffic that the CDN/Cloud WAF provider can't stop) > Border Firewall > Load Balancer > Proxy Server (depending on the load, this may not exist > Web Server > Database Server

No. Since not everyone that runs a IPS forum can afford such. It costs a lot, i know many that even struggle paying shared web hosting, telling us to go get a own CDN or whatever - instead of fixing some actually very basic 'fixes' for IPS is kinda idiotic. It's something simple as a toggle rule, that they had on 3.4

Layer-4 attacks will still come through, even if you 'block all ips but CloudFlare networks'. Closing ports for unknown IP's isnt a solution, bandwidth or other type of attacks will still flood through. 

 

28 minutes ago, Colonel_mortis said:

My argument is that IPS doesn't need to be making most of the requests that it is currently making (they should be done client side instead), which would have multiple advantages and not much in the way of disadvantages as far as I can see

Yes, or at least a option to disable them? There is no option to disable the checks such as Avatar upload via URL. Which is the most known method.

[Jswerv3]

4 hours ago, Colonel_mortis said:

That doesn't fix it though - if you paste any URL (or maybe just any image URL), the server will make an external request to that URL, which can easily be logged.

Well from my understanding the only way to actually get the origin IP from those crusty IP Logger websites that generate fake .jpeg urls - is that the upload avatar from URL for example.. you paste that phony IP Logger link into the upload image from URL - the image is too small, and the error message is the thing that exposes your IP, because it had to ping your server in order to generate the error.

So I am confused how this would work with signatures in 3.4 for example. There is no upload, there is just an embed option - but the embedding option doesnt generate errors so how would they get the origin IP from the sig area?

[Randy Calvert]

Guys...  those of you complaining about costs...  if you would have read the very next paragraph, I included a statement on how to deal with this.  

For those that don't have a LB, your best bet is to create an ACL (access control list) to block any traffic that is not coming from the cloud service provider.

Anyone using CloudFlare for example, I can find your origin info by looking at the raw HTTP headers.  There is NOTHING that IPB can do in the software to hide that.  That's an issue with the free service you're using.  Part of the reason it's FREE is because it's not the best thing in the world.  It's not a full CDN/Cloud WAF like say something Akamai.  

I realize not everyone can afford it.  In an ideal situation, everyone would have redundant infrastructure, with dedicated WAF, IPS/IDS, etc.  When operating a personal or small site with little/no money, there are always going to be risks you can't mitigate.  This is not a SOFTWARE issue...  talk to your cloud security provider.  full CDN/Cloud WAF solutions have the ability to rewrite origin hostnames so as not to expose them publicly.  Ultimately you should not be even allowing direct access to the origin.  

[OctoDev]

9 minutes ago, Randy Calvert said:

Guys...  those of you complaining about costs...  if you would have read the very next paragraph, I included a statement on how to deal with this.  

 

Anyone using CloudFlare for example, I can find your origin info by looking at the raw HTTP headers.  There is NOTHING that IPB can do in the software to hide that.  That's an issue with the free service you're using.  Part of the reason it's FREE is because it's not the best thing in the world.  It's not a full CDN/Cloud WAF like say something Akamai.  

I realize not everyone can afford it.  In an ideal situation, everyone would have redundant infrastructure, with dedicated WAF, IPS/IDS, etc.  When operating a personal or small site with little/no money, there are always going to be risks you can't mitigate.  This is not a SOFTWARE issue...  talk to your cloud security provider.  full CDN/Cloud WAF solutions have the ability to rewrite origin hostnames so as not to expose them publicly.  Ultimately you should not be even allowing direct access to the origin.  

No offence, but if you work for cloud hosting security then you better know blocking ports will not stop attacks.. Unless it's Layer-7..

The thing here is NOT about blocking attacks, it's that IPS are making 3rd party services like CloudFlare completely pointless when it comes to DDoS Protection they provide. And don't come here and tell me nobody uses CloudFlare for DDoS Protection.. That's why they are famous, a app like IPS makes what they do completely useless and defeats the point of using any reverse proxies.

Is it that big of a deal to add a few extra settings, that lets the people that actually use cloudflare and can't afford own content delivery networks - a option to disable the features that 'leak' our IP Address?  

I know about no other forum software out there, that has no option to disable such feature. MyBB, XenForo and other forum softwares can disable avatar upload with remote url with a click.

Now, IPS 4.1 has just gotten worse than 3.4 when it comes to this case.

[Randy Calvert]

 

8 minutes ago, Jimmy Gavekort said:

No offence, but if you work for cloud hosting security then you better know blocking ports will not stop attacks.. Unless it's Layer-7..

It will layer 7 (application layer) attacks obviously.  It will not stop later 3/4 (network/volumetric) attacks.  There is no such thing as a software solution that will stop large scale layer 3/4.  That's why I said earlier the higher up you can put the ACL the better.  (The higher up you are, the more resources that are typically available to filter.)  Services like Cloudflare/Incapsula/Akamai and the rest will not stop those types of attacks at layer 3/4 that are targeted at the origin either.  Your protection from direct to origin attacks like that (for example those that try to attack your origin IP address) is to use a scrubbing solution from the ISP itself (VZ, ATT, Cogent, etc), a cloud based scrubbing service such as Prolexic or Verisign (those require typically having at least a /24 worth of IP space).  However again for situations where you're using shared hosting services or VPS or even dedicated hosting services, you're basically counting on the hosting provider to provide DDoS protection.  In a situation where you don't control your IP space, there is nothing you can do to stop large scale volumetric attacks.  

The only way to protection the origin from DDoS is for it to not be on the internet.  Most people can't afford to do that.  They can't do a dedicated circuit directly to the cloud security provider.  As a result, they have to count on their data center provider to help filter volumetric attacks that might be targeted towards them or pay for their own /24, run BGP, and use a scrubbing service noted above.  

[Colonel_mortis]

Just now, Randy Calvert said:

 

It will layer 7 (application layer) attacks obviously.  It will not stop later 3/4 (network/volumetric) attacks.  There is no such thing as a software solution that will stop large scale layer 3/4.  That's why I said earlier the higher up you can put the ACL the better.  (The higher up you are, the more resources that are typically available to filter.)  Services like Cloudflare/Incapsula/Akamai and the rest will not stop those types of attacks at layer 3/4 that are targeted at the origin either.  Your protection from direct to origin attacks like that (for example those that try to attack your origin IP address) is to use a scrubbing solution from the ISP itself (VZ, ATT, Cogent, etc), a cloud based scrubbing service such as Prolexic or Verisign (those require typically having at least a /24 worth of IP space).  However again for situations where you're using shared hosting services or VPS or even dedicated hosting services, you're basically counting on the hosting provider to provide DDoS protection.  In a situation where you don't control your IP space, there is nothing you can do to stop large scale volumetric attacks.  

The only way to protection the origin from DDoS is for it to not be on the internet.  Most people can't afford to do that.  They can't do a dedicated circuit directly to the cloud security provider.  As a result, they have to count on their data center provider to help filter volumetric attacks that might be targeted towards them or pay for their own /24, run BGP, and use a scrubbing service noted above.  

No, Cloudflare, Incapsula and other related services (herein referred to as CF) are very effective at hiding your IP address. I would challenge your assertion that 

16 minutes ago, Randy Calvert said:

Anyone using CloudFlare for example, I can find your origin info by looking at the raw HTTP headers.

Feel free to prove me wrong - here's the request headers for my site:

(plus a couple of others like cookie, referrer etc)

And the response headers:

(and, even if you are able to obtain the IP address from that, which I highly doubt, that doesn't change the fact that nobody else seems to have figured it out, because nobody has been bypassing cloudflare and attacking the site).

Level 3/4 attacks don't affect the site at all, provided that the site uses CF and the attacker doesn't have your origin IP address, and some layer 7 attacks are able to be mitigated too, though that is considerably less effective. Unfortunately, IPS's decision to make so many outbound HTTP requests on demand is nullifying the protection given by CF against targeted attacks, which is really bad.

[OctoDev]

As Colonel said. CloudFlare can't block all Layer-7, but most. Layer-4, it can "prevent" all attacks, as long as the software you are using isn't leaking the origin server IP Address.. Such as IPS does, multiply places in 4.1 (Avatar upload, signature, text editor).

This solution has been working for me, and thousands of others ever since those services came out. The only issue we "us" everyone that use CloudFlare has is apps like IPS, doing outbound http request to a url that the visitor enters, which will result in the visitor getting the origin server IP Address.

[Jswerv3]

The free version of CloudFlare only goes so far, the Business version is much better with actual DDoS protection, but it does cost $200/m which is no small cost for a small forum or someone who is simply running a board as a hobby

[Randy Calvert]

2 hours ago, Colonel_mortis said:

Level 3/4 attacks don't affect the site at all, provided that the site uses CF and the attacker doesn't have your origin IP address, and some layer 7 attacks are able to be mitigated too, though that is considerably less effective. Unfortunately, IPS's decision to make so many outbound HTTP requests on demand is nullifying the protection given by CF against targeted attacks, which is really bad.

I don't use Cloudflare specifically day to day, however I just did some and you have an Enterprise cloud flare plan, it looks like you can rewrite URL host headers and it looks like with the free plan it can potentially be done in the page content level dynamically on the fly.  Again, you don't need a software solution to do this.  The job of a PROXY is to handle rewriting requests, even in the origin response to the user.  So it looks like it's even possible in Cloudflare to do if set it up correctly.    

By the way...  those are the headers your browser are specifically looking for.  Check out pragma headers and how those can be injected into a request that would not show up unless you knew to implicitly look for them.  ;-)  

[Lindy]

"Hiding" your IP address is not an acceptable security practice and largely only acts as a mild deterrent for gamers attacking each other - it's not a security solution. Your goal should be to make your origin IP useless to others, not just hidden. You can obtain an IP for one of our origins here, but it's not going to do you any good... and that is how it should be. 

I'm not sure it's appropriate to employ rudimentary "security" practices and then come here and state we have a "vulnerability." External calls, embeds, etc. are certainly not limited to IPS software.

I can empathize to a large degree as DDoS attacks have plagued us all at one point. Nonetheless, this just isn't an application layer issue to solve and we're not particularly interested in re-engineering to "anonymize" the software to account for security by obscurity.