Sam - February 26, 2017
Defend Yourself Against HTTProxy Exploit
What Is HTTPoxy?
HTTPoxy also known has CGI application vulnerability has been uncovered on July eighteenth, 2016. When reaching backing services, an attacker can trigger vulnerable deployments by passing an HTTP Proxy header with their demand, which will modify the URL utilized by the application.
The CGI speciation requested for client-provided headers to be passed to the environment with an HTTP_ prefix for namespacing. The vulnerability is caused by what is known as a collision between the HTTP_PROXY environmental variable, continually used to indicate the location of a backend proxy service, and the Proxy HTTP client header. In the event that a CGI application or a library uses this variable without extra processing, it could end up utilizing the esteem gave by the client when attempting to connect to the proxy service and this may clash with configuration variables such as HTTP_PROXY which begin with HTTP_.
Since 2001, the HTTPoxy vulnerability has been known in some forms yet never perceive as a cross board issue until recently. Various security vulnerability identifiers have been generated: CVE-2016-5386, CVE-2016-53887, CVE-2016-5388, CVE-2016-1000109, and CVE-2016-1000110 (At the time of this writing, these are reserved, but not filled out) as this vulnerability impacts an assortment of CGI-like implementations. In spite of the fact that it may impact many deployments, relief is quite straight forward and simple.
Vulnerable Servers and Applications
HTTPoxy is found by numerous CGI implementations and is generally vulnerability. A server or application can effectively execute the CGI specification and still be vulnerable.
In order for a deployment to be vulnerable, it must:
Find the perfect Proxy Product.
Make use of the HTTP_PROXY environmental variable to configure proxy connections: This is a pretty standard method of configuring proxy servers using the environment. Either in the application codes itself or any libraries that are utilized influence.
Make solicitations to backend administration using HTTP: Requests using HTTPS or any other protocols are not vulnerable because the name collision is peculiar to the HTTP_ prefix, the main request made by the application using HTTP will be influenced.
Work in a CGI or CGI-like environment: Deployments, where customers headers are converted into HTTP_, prefixed environmental variables are vulnerable. Any consistent usage of CGI or related conventions like Fast CGI will execute this.
To know if your deployment is been affected, Luke Rehmann has developed a simple site to check publicly accessible sites for vulnerability. As you can see, combinations of deployment- and application- particular variables are vital for a deployment to be vulnerable.
Language Specific Information
Since CGI-like deployments are substantially more regular in the PHP ecosystem than in other languages, then PHP applications, in particular, ought to be reviewed. Moreover, the widespread usage of the getenv strategy in popular libraries intensifies this issue, as it is not instantly clear that these will not just configuration variables but will likewise return unsanitized client input. Specific libraries that are as of now influence are Artax, Guzzle (version 4.0.0rc2 and greater), and Composer’s Stream Context Builder class.
If CGI is been used, libraries that naively read the HTTP_PROXY variable without stabilizing their behavior are vulnerable. However, some other languages that are believed to be vulnerable when deployed utilizing CGI were Go and Python and these languages are commonly deployed utilizing other, non-vulnerable strategies
Step by Step Instruction to Defeat the Vulnerability
The vulnerability can be managed by the web server layer or the library or application and luckily, HTTPoxy is generally easy to fix:
Web proxies or servers can unset the Proxy header received in client requests
Libraries or applications can make use of a different environmental variable to configure proxy connections
Libraries or applications can ignore the HTTP_PROXY variable if they are in a CGI environment.
Consider using an alternative variable that will not crash when running in a CGI-like environment if you are a library or application author and your project relies on the HTTP_PROXY variable to configure a proxy backend. Ruby and some other projects use CGI_HTTP_PROXY for this purpose. If you are using a vulnerable library, you ought to ease the risk on the server end until patches are accessible to address the issue.
It’s safe to ignore in most cases if the Proxy header is not a standard HTTP header because the Proxy HTTP header does not have any standard legal purpose, this should be possible in the load balancer or web server used to direct demands to the application itself.
Cut off the HTTP Proxy Header with Apache
The mod_headers module can be used to unset the header for all requests on the off chance that you are running the Apache HTTP web server.
Ubuntu and Debian Servers
To allow mod_headers in Ubuntu or Debian servers, type:
$ sudo a2enmod headersThereafter, open the worldwide configuration file:
$ sudo nano /etc/apache2/apache2.confGetting to the bottom, include:
/etc/apache2/apache2.confRequest Header unset Proxy early
Save and close the file.
Check the configuration for syntax errors:
$ sudo apache2ctl configtestIf there are no syntax errors reported, restart the service\
$ sudo service apache2 restartCentOS and Fedora Servers
By default for conventional installations, the mod_headers module should be enabled. Open the global configuration files to unset the Proxy header:
$ sudo nano /etc/httpd/conf/httpd.confGetting to the bottom, add:
/etc/httpd/conf/httpd.confRequest Header unset Proxy early
Save and close the file when you are done.
Check for syntax errors by typing:
$ sudo apachectl configtestIf there are no syntax errors found, restart the service by typing:
$ sudo service httpd restartRemoving the HTTP Proxy Header with Nginx
In Nginx, you can easily sanitize the environment for any CGI-like environment running on the server or upstream. Moderation is likewise trifling.
Ubuntu and Debian Servers
FastCGI parameters are usually included from either the fastcgi.conf or fastcgi_params files when setting up a FastCGI proxy on Ubuntu and Debian servers. You can unset the HTTP_PROXYheader in both of these records::
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee –a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_paramsWhen configuring your FastCGI proxies, if you are not sourcing one of these files, then be sure to add this same line in the proxy location itself:
/etc/nginx/sites-enabled/some_site.conf. . .
location ~ \.php$ {
. . .
fastcgi_param HTTP_PROXY "";
. . .
}
}Check for syntax errors by typing:
$ sudo nginx -t If there are no errors found, restart the service:
$ sudo service nginx restartCentOS and Fedora Servers
Nginx on CentOS and Fedora also make use of the same fastcgi.conf and fastcgi_params files to configure FastCGI proxying. In both of these files unset the HTTP_PROXY header by typing:
$ echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
$ echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_paramsWhen configuring your FastCGI proxies, if you are not sourcing one of these files, then be sure to add this same line in the proxy location itself:
/etc/nginx/nginx.conf. . .
location ~ \.php$ {
. . .
fastcgi_param HTTP_PROXY "";
. . .
}
}You should clear the HTTP Proxy header if you make use of Nginx for conventional HTTP proxying. All you need is to add a rule to unset the Proxy header in any location where you are implementing a proxy_pass. You can easily search your configuration directory if you are not sure where proxy_pass is being used:
$ grep -r "proxy_pass" /etc/nginxOutput
/etc/nginx/nginx.conf.default: # proxy_pass http://127.0.0.1;Like the example above, any results that are not commented should be edited to include proxy_set_header Proxy “”;:
/etc/nginx/nginx.conf. . .
location / application / {
. . .
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
. . .
}
}Check for syntax errors by typing:
$ sudo nginx –tIf no errors are found, restart the service:
$ sudo service nginx restartRemoving the HTTP Proxy Header with HAProxy
You can drop Proxy header before forwarding traffic if you are using HAProxy to direct traffic to your application servers.
Open up the /etc/haproxy/haproxy.cfg file for editing:
$ sudo nano /etc/haproxy/haproxy.cfgIn the backend, frontend, or listen sections of your configuration, you can set the http-request directive.
/etc/haproxy/haproxy.cfgfrontend www
http - request del - header Proxy
. . .
backend web - backend
http - request del - header Proxy
. . .
listen appname 0.0.0.0: 80
http - request del - header Proxy
. . .Save and close the file when you are done. These do not need to be set in each of the sections, though it won’t hurt to include them.
Check the syntax by typing:
$ sudo haproxy -c -f /etc/haproxy/haproxy.cfgIf you found no problems, restart the service by typing:
$ sudo service haproxy restartConclusion
The HTTPoxy vulnerability has been in existence for a long time and may influence a vast set of applications deployed on the web. Fortunately, it can without much stress easy to fix using the header-altsering capabilities local to any web server.
