There is a report about an alleged "vulnerability" in Admin Tools floating around the Internet. However, the described behavior is documented, optional and does not violate the site's confidentiality, integrity or trust. As a result it's not a "vulnerability". In the spirit of transparency we disclose both the report and our response to it.
### Steps to reproduce the issue
Substitute www.example.com with a server you can access the access.log file
go to http(s)://<some-joomla-installation>/component/search/?Itemid=http://www.example.com/
### Expected result
Go to the www.example.com server and check the access log file. The site has been accessed by the <some-joomla-installation> server.
### Actual result
Sites can be attacked through <some-joomla-installation> server or at least queried. This should be prevented.
### System information (as much as possible)
This is not a vulnerability. It's an integral part of an optional protection offered by Admin Tools called RFIShield which is only necessary on old or misconfigured servers. This protection is marked for removal when we stop supporting PHP 5.4. The rationale is simple: even though the allow_url_include feature was introduced in PHP 5.2 we only saw it being disabled by real world hosting companies around the time they started supporting PHP 5.5. In the meantime you can simply disable that feature if for some misguided reason you think your server's IP address is a "secret" (newsflash: it's not).
The RFIShield feature protects you against direct inclusion of remotely hosted PHP code. In order to do that it needs to inspect the content of every POST/GET variable whose content has a URI format with an http:// or https:// schema. A GET request is issued towards that resource and its response is inspected. If executable PHP code is detected the entire request containing that URI is blocked.
A vulnerability needs to compromise at least one of the CIA components of information security (Confidentiality, Integrity, Availability). Let's analyze the impact to each component.
Since there is no violation of either component of information security calling this behavior a "vulnerability" is a stretch of someone's imagination.
The only possible reason to want your server's IP to be kept secret is if you have reasons to fear a (Distributed or not) Denial of Service attack and for this reason you're using a DoS mitigation service such as CloudFlare. In this case you shouldn't need to use the RFIShield feature since your server should be configured with allow_url_include disabled. If you're under fire or at risk of being massively attacked you should have taken this kind of basic precautions. Likewise, if your use case is so high risk you should have read the documentation of Admin Tools and figured out which features to enable and which to disable. Moreover, a high risk environment would also be using the .htaccess / NginX configuration / web.config Maker or a custom security-enhanced server configuration which blocks requests with a URL in the request parameter values. Therefore in the use case where you'd have reasons to worry about this behavior you should have already been protected. That's the thinking that led to the implementation of RFIShield back in 2010.
In case it wasn't abundantly clear already, you can disable this optional feature by going to Components, Admin Tools, Web Application Firewall, Configure WAF and turn off the RFIShield feature.
In fact you should disable this feature in the following circumstances:
We will add two checks on the RFIShield feature to suppress it when it's not needed or there is an increased risk:
ini_get()function in PHP. When that PHP feature is disabled your server is generally immune to remote file inclusion, therefore we can safely suppress this feature.
Since there is no immediate threat to anyone we are not going to issue an exceptional release including the aforementioned safeguards. They will be included in the next version of Admin Tools. Further to that, as we explained several times already, you can always DISABLE the RFIShield feature on your site.
Clarification: "suppress" means that even if the feature is enabled it will NOT perform its task, i.e. it will act as though it was disabled.
Whichever company started floating this report on the Internet did a disservice to everybody by not contacting us first for comment. They spread fear, uncertainty and doubt about an non-existent issue. This is grossly irresponsible. If you have received this kind of report we'd recommend severing ties with the irresponsible party who floated an unverified report without vendor feedback to its clients. They are obviously inventing "vulnerabilities" to get your money without offering real service.