According to the London-based security consultancy, which has been working with the Apache Software Foundation to advise users of the open source platform, it has developed a number of remediation processes to work around the issue.
The problem centers on insecurely configured reverse web proxies, which are used to route external HTTP and HTTPS web requests to one of several internal web servers to access data and resources. Typical applications, said Context, include load balancing, separating static from dynamic content, or to present a single interface to a number of different web servers at different paths.
Where other proxy systems may suffer from the same vulnerability, the consultancy said that the specific attack identified by its researchers was based on an Apache web server using the mod_rewrite proxy function, which uses a rule-based rewriting engine to modify and rewrite web requests dynamically.
When the web proxies had not been configured securely, Context reported it was able to use an easy-to-obtain hacking tool in order to force a change in the request to access internal or DMZ systems – including administration interfaces on firewalls, routers, web servers and databases. And if credentials on internal systems were weak, a full network compromise was possible, including uploading trojan WAR files to a server.
The good news, Infosecurity notes, is that the consultancy asserted that the vulnerability can easily be mitigated by checking reverse proxy configurations to ensure that the rewrite rules cannot be abused and so allow for the URLs to be rewritten in such a way that they can access internal systems.
In connection with this, Context has released the latest version of its free-to-download Context Application Tool (CAT), which is designed to deliver manual web application penetration testing that can be used to identify the vulnerability.
For the rule-writers among you, the difference between the two rules can be as simple as adding an extra slash, which ensures that Apache does not interpret the domain and port parts of the request as a username and password.
For example, said Context, if the Apache configuration file is configured like this:
RewriteRule ^(.*) http://internalserver:80$1 [P]
and not like this:
RewriteRule ^(.*) http://internalserver:80/$1 [P]
then access from the internet to any internal system is possible.
In its advisory, Apache recommended that Apache HTTPD users examine their configuration files to determine if they have used an insecure configuration for reverse proxying. The full Apache response can be viewed here.
Commenting on the issue – and its remediation – Michael Jordan, Context's research and development manager, said that the vulnerability is totally avoidable if the reverse proxies are properly configured. “We have not investigated other web servers and proxies but it is reasonable to assume that the problem is more widespread”, he said.