It all boils down to a missing forward-slash symbol: A newly discovered method of attack could let hackers access databases, firewalls, routers, and other internal network resources via misconfigured reverse-proxy Web servers. The flaw, discovered by U.K. researchers last month, was quickly patched yesterday by the Apache Software Foundation, but the researchers say it could affect other Web platforms as well.

A missing forward-slash mark in a so-called "rewrite rule" for an Apache Web proxy lets an attacker force a change in the HTML request so that he could access the target organization's internal systems. A rewrite rule is for configuring how a public website is presented such that the various back-end servers appear as one unified site, for instance. Researchers at Context Information Security discovered the issue during a penetration-test engagement.

"It's a classic case of functionality lying around that people didn't know was there, and didn't know the misconfigurations are," says Michael Jordon, research and development manger at Context. "Any other URL-rewriting reverse proxy would potentially have the same issue, and we have contacted other Web server providers to inform them of this."

In the Apache case, the attack could be waged using the "mod_rewrite" proxy function: When the Web proxies were configured without a specific slash mark, the researchers were able to use a hacking tool to force a change in the request so that they could access the internal systems behind the public website. In one test, they were able to get to the internal console of a JBoss server, Jordon says.

"We were able to get access to the app server and deploy our own code on it. Then you could take full control of that network," he says. The researchers used their own Context Application Tool (CAT) in the hack, which is available for free.

"It allows us to do manual HTTP requests, and we used it to do the exploit," he says.

Here's an example of a misconfigured reverse-proxy server, courtesy of Context:

RewriteRule ^(.*) http://internalserver:80$1 [P]

And here's an example of properly and securely configured one -- note the slash mark before the dollar sign:

RewriteRule ^(.*) http://internalserver:80/$1 [P]

"Many vulnerabilities are like this, where a small typo within the source code or, in this case, a configuration file, can make you vulnerable," says Ryan Barnett, senior security researcher for Trustwave SpiderLabs. "The reason why this is an issue is that by using the regular expression captures in mod_rewrite, the admin is using untrusted, user-controlled data in an action. This is a big 'no-no' for Web developers, and Web administrators have to deal with it, too. In this case, when the trailing slash character is missing, it impacts the interpretation of the URI scheme and allows the attacker to break out of the correct parsing context."

Apache issued its patch yesterday for the flaw in Apache HTTP Server versions 1.3 and 2.x, and promised that future releases of Apache HTTP Server would validate the request URI to prevent such an attack. "When using the RewriteRule or ProxyPassMatch directives to configure a reverse proxy using a pattern match, it is possible to inadvertently expose internal servers to remote users who send carefully crafted requests. The server did not validate that the input to the pattern match was a valid path string, so a pattern could expand to an unintended target URL," the advisory says.

Trustwave's Barnett says this flaw could be propagated to Microsoft's IIS if a user were importing Apache's mod_rewrite rules into IIS 7 using the rewrite module. "So if the Apache mod_rewrite rules had this issue, they could then be propagated to IIS," he says.

The best way to prevent this type of attack is to apply the new Apache patch and run the latest version of the software, and to ensure that your reverse proxy rewrite rules can't be employed to access internal systems, according to Context.

An in-depth look at the hack is here in a Context blog post.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.