A CGI application vulnerability called httpoxy was announced in July with coordinated disclosure from many vendors. httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. The vulnerability allows an attacker to remotely set the HTTP_PROXY environment variable on affected servers which can lead to a number of bad consequences. This can lead to a remotely exploitable vulnerability.This vulnerability mainly affects applications that use “classic” CGI execution models. For PHP (both CGI and mod_php versions) whether you are vulnerable depends on your specific application code and PHP libraries. If your run Python or Go under CGI, they can also be vulnerable. httpoxy has a number of CVEs assigned to it.
This issue is not new, but has just became to limelight again. HTTPOXY affects clients that honor the HTTP_PROXY variable and use it for their proxy configuration and server side applications which use HTTP_PROXY as real or emulated variable in their environment. This bug was first discovered over 15 years ago – but still in July 2016 researchers found that the vulnerability was still exploitable in PHP. So, the bug was lying dormant for years, like a latent infection: pox. To put it plainly: there is no way to trust the value of an HTTP_ env var in a CGI environment and you should block the Proxy header.
Best advice is to patch as soon as possible. Immediate mitigation before patching can be performed by blocking ‘Proxy’ request headers as early as possible - httproxy.org has released details for many enviroments (Apache, OpenBSD, Nginx/FastCGI and others). If you’re running PHP or CGI, you should block the Proxy header now. Blocking can be done in web server, web load balancer, web proxy or cloud proxy service.
The vulnerability is easily remotely exploitable and servers can be scanned for it, for details on that read HTTPOXY Vulnerability: How to protect and test your web server article that recommends https://httpoxy.rehmann.co/ service for testing your own servers.
12 Comments
Tomi Engdahl says:
HTTPoxy – CGI “HTTP_PROXY” variable name clash
https://access.redhat.com/security/vulnerabilities/httpoxy
The Problem: HTTP_PROXY name clash
A CGI script cannot distinguish between CGI’s “Protocol-Specific Meta-Variable”, containing the value of the HTTP request’s “Proxy” header, and the “system” environment variable HTTP_PROXY, containing HTTP proxy settings. A CGI script, module, or library reads the “HTTP_PROXY” environment variable, and assumes that this contains the “system” HTTP proxy settings. The misinterpreted value then changes how new HTTP requests are dealt with by the CGI script (and any other scripts and programs it may call) made during the processing of the current HTTP request.
Take Action
All Red Hat customers using CGI scripts with PHP, Go, or Python are strongly recommended to apply mitigations to their systems.
–
As the documentation shows:
https://docs.openshift.com/enterprise/3.2/install_config/install/deploy_router.html
You can use F5 or haproxy as the router. Both of these do not fdirectly run CGI programs. It is not safe to simply start deleting/dropping headers that people may be using, in both cases (haproxy and F5) a simple configuration change can be used to drop the header if you do not need it. For Haproxy simply add:
http-request del-header Proxy
And for F5 the following ASM mitigation should work:
headercontent:”Proxy:”; nocase; re2:”/^\s*Proxy:/Hmi”;
Tomi Engdahl says:
How to Protect Your Server Against the HTTPoxy Vulnerability
https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-httpoxy-vulnerability
The vulnerability is caused by a name collision between the HTTP_PROXY environmental variable, frequently used to specify the location of a backend proxy service, and the Proxy HTTP client header. The CGI specification calls for client-provided headers to be passed to the environment with a HTTP_ prefix for namespacing. This mangling clashes with configuration variables like HTTP_PROXY, which also start with HTTP_. If a CGI application or a library uses this variable without additional processing, it could end up using the value provided by the client when attempting connections to the proxy service.
As this vulnerability impacts a variety of CGI-like implementations, a number of security vulnerability identifiers have been created: CVE-2016-5386, CVE-2016-5386, CVE-2016-5387, CVE-2016-5388, CVE-2016-1000109, and CVE-2016-1000110 (At the time of this writing, these are reserved, but not filled out).
Vulnerable Servers and Applications
HTTPoxy is a general vulnerability found by many CGI implementations. An application or server can correctly implement the CGI specification and still be vulnerable.
For a deployment to be vulnerable, it must:
Use the HTTP_PROXY environmental variable to configure proxy connections: Either in the application code itself or any libraries that are used leverages. This is a fairly standard method of configuring proxy servers using the environment.
Make requests to backend services using HTTP: Because the name collision is specific to the HTTP_ prefix, only requests made by the application using HTTP will be affected. Requests using HTTPS or any other protocols are not vulnerable.
Operate in a CGI or CGI-like environment: Deployments where client headers are translated into HTTP_ prefixed environmental variables are vulnerable. Any compliant implementation of CGI or related protocols like FastCGI will do this.
As you can see, a combination of deployment- and application-specific factors are necessary for a deployment to be vulnerable.
PHP applications in particular should be audited, since CGI-like deployments are much more common in the PHP ecosystem than in other languages.
Fortunately, HTTPoxy is relatively simple to fix. The vulnerability can be addressed from the web server layer or the application or library:
Applications or libraries can ignore the HTTP_PROXY variable when they are in a CGI environment.
Applications or libraries can use a different environmental variable to configure proxy connections
Web servers or proxies can unset the Proxy header received in client requests
Tomi Engdahl says:
HTTPOXY Vulnerability: How to protect and test your web server
https://www.howtoforge.com/tutorial/httpoxy-protect-your-server/
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.
Tomi Engdahl says:
Tools for testing HTTPoxy vulnerability
https://github.com/silverfoxy/HTTPoxy-Test-Tools
Tomi Engdahl says:
How to fix Httpoxy a CGI PHP/Nginx/Apache/Go application vulnerability on Linux or Unix
http://www.cyberciti.biz/faq/fix-httpproxy-cgi-application-vulnerability-for-linux-unix-apache-nginx-python-php/
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.
Tomi Engdahl says:
Responsible disclosure of latest named vulnerability, ‘httpoxy’
http://searchsecurity.techtarget.com/news/450300551/Responsible-disclosure-of-latest-named-vulnerability-httpoxy
Tomi Engdahl says:
15-year-old security hole HTTPoxy returns to menace websites – it has a name, logo too
So you know it’s really scary
http://www.theregister.co.uk/2016/07/18/httpoxy_hole/
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.
Tomi Engdahl says:
Old HTTPoxy Flaw Exposes Web Applications to Attacks
http://www.securityweek.com/old-httpoxy-flaw-exposes-web-applications-attacks
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.
Tomi Engdahl says:
HTTPoxy – Is your nginx affected?
http://tunnelix.com/httpoxy-is-your-nginx-affected/
Tomi Engdahl says:
Tools for testing HTTPoxy Vulnerability
https://www.silverf0x00.com/tools-for-testing-httpoxy-vulnerability/
Tomi Engdahl says:
HTTPoxy – the disease that could make your web server spring a leak
https://nakedsecurity.sophos.com/2016/07/19/httpoxy-the-disease-that-could-make-your-web-server-spring-a-leak/
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.
Tomi Engdahl says:
[NSE] NSE script to detect web apps vulnerable to HTTPoxy
http://goo.gl/Ttsn9x
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