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.
Original report
### 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)
Setting Value
Our response
Executive summary
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).
What actually happens
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.
Risk Analysis (why is this not a vulnerability)
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.
- Confidentiality. No confidential information about your server is exposed. The only "leaked" information is your server's IP address which is public information through DNS. If it wasn't public information your site could not be found.
- Integrity. The integrity of the data is not compromised since no data is read, written or transmitted from your server by the very definition of this process.
- Availability. There is no impact to the availability of your server. Even the timeout limit of the GET request is very low to avoid a misbehaving remote server from causing your server's PHP process to be stuck waiting for data forever.
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.
"Mitigation"
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:
- Your server has a firewall for outbound connections. This makes your site generally immune to remote URL inclusion since you'd need to whitelist the server where the executable code is hosted. Moreover, the RFIShield feature would simply fail to connect to the remote URL for the same reason, simply wasting your server's time.
- You are behind a firewall / CDN / reverse proxy / DDos mitigation service (e.g. CloudFlare CDN). These are the use cases where you might indeed want to keep your server's IP address a (relative) secret.
- Your server already has allow_url_include disabled. This is the architecturally correct way to do that. You can check that by going to your site's backend and clicking on System, System Information, PHP Information. Search that page for allow_url_include and check its setting under Local Value. If it's Off you can safely disable the RFIShield feature of Admin Tools.
Further actions on our part
We will add two checks on the RFIShield feature to suppress it when it's not needed or there is an increased risk:
- When Enable IP Workarounds is enabled. Since this feature is only required when you're behind a firewall / CDN / reverse proxy / DDos mitigation service (e.g. CloudFlare CDN), having it enabled would indicate that automatic GET requests to remote servers might carry unwanted risk in your use case.
- Your server already has allow_url_include disabled. This is an approximate measure, only possible if your host does not block the
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.
Final words on irresponsible disclosure
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.