HTTPoxy: Threat­en­ing the security of CGI ap­pli­ca­tions

Countless web projects rely on proxy servers for per­for­mance and security purposes. These practical programs function as a com­mu­ni­ca­tion interface between client and website and relieve the web server by receiving, editing, routing, and re­spond­ing to HTTP requests. But because of a security vul­ner­a­bil­i­ty known as HTTPoxy, this technique can be abused by attackers for data theft. Ap­pli­ca­tions that are based on the CGI standard (Common Gateway Interface) and configure so-called en­vi­ron­men­tal variables are affected. For example, some programs can read your proxy con­fig­u­ra­tions from the variables, which quickly becomes a problem when criminals ma­nip­u­late these settings.

When a web server com­mu­ni­cates with the client of a user via the Common Gateway Interface, the RFC standard 3875 provides that the headers of all sent HTTP requests are stored as en­vi­ron­men­tal variables. The name of this variable consists of the prefix “HTTP_” and the name of the header in uppercase. In this case, the header is “Proxy”, which au­to­mat­i­cal­ly generates the variable HTTP_PROXY. This is given as the default con­fig­u­ra­tion of proxy settings. If the CGI ap­pli­ca­tion reaches or executes a request con­tain­ing HTTP_PROXY, it’s redi­rect­ed via the cor­re­spond­ing proxy server.

These described cir­cum­stances allow an attacker to put their own proxy server into play, and use it to get hold of con­fi­den­tial in­for­ma­tion. To do this, it sends an HTTP request with the header Proxy and a cor­re­spond­ing value (for example, the IP address of the proxy), so that future user requests – incoming or outgoing – will be redi­rect­ed to them. Depending on the scenario chosen, the attacker can then either return their own data at will or directly read the user’s input data.

The vul­ner­a­bil­i­ty, whose name has no special meaning, was caught for the first time in March 2001. The pro­gram­mer Randal L. Schwartz detected HTTPoxy in the Perl library libwww-perl and told Gisle Aas, the developer of the library. The vul­ner­a­bil­i­ty was im­me­di­ate­ly closed in Update 5.51 by modifying the variable name through which the proxy con­fig­u­ra­tion could be con­trolled to CGI_HTTP_PROXY. In the same year, the vul­ner­a­bil­i­ty was also detected in the data transfer program curl, and the developer Daniel Stenberg adapted the software so that only the lowercase variant http_proxy could determine the proxy server – while at the same time advising that this was fun­da­men­tal­ly in­suf­fi­cient for Microsoft systems. In current Windows versions, the problem no longer exists.

Around a decade later, in July 2012, the Ruby team came across the long-forgotten HTTPoxy problem when they im­ple­ment­ed the NET::HTTP class, an HTTP client API for Ruby ap­pli­ca­tions. To get around the problem, they set HTTP_PROXY and others under the status of a standard variable. In the following years, the web server ap­pli­ca­tions NGINX (2013) and Apache (2015) became some of the most prominent cases in which attentive users informed the de­vel­op­ers about a potential danger.

In 2016, the security team of the developer company Vend found that the HTTPoxy security gap is still around 15 years after its first discovery, and PHP, in addition to various other pro­gram­ming languages, as well as libraries, can be exploited – provided that they’re used in com­bi­na­tion with CGI or a com­pa­ra­ble runtime en­vi­ron­ment with variables. Many affected ap­pli­ca­tions that enable the use of HTTPoxy have been listed in the official spec­i­fi­ca­tions for security vul­ner­a­bil­i­ties, known as the CVEs (Common Vul­ner­a­bil­i­ties and Exposures):

• CVE-2016-5385: PHP
• CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
• CVE-2016-5388: Apache Tomcat
• CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
• CVE-2016-6287: CHICKEN’s http-client
• CVE-2016-1000104: mod_fcgi
• CVE-2016-1000105: Nginx cgi script
• CVE-2016-1000107: Erlang inets
• CVE-2016-1000108: YAWS
• CVE-2016-1000109: HHVM FastCGI
• CVE-2016-1000110: Python CGI­Han­dler
• CVE-2016-1000111: Python Twisted
• CVE-2016-1000212: lighttpd

Re­gard­less of whether you operate your own web server or not, HTTPoxy presents a risk when you’re online. If the requested web service can be redi­rect­ed through un­de­sir­able external HTTP requests, then, as a result, its data won’t be in safe hands. To minimize the risk of data loss, you should give pref­er­ence to sites that are protected by a TLS/SSL cer­tifi­cate and transfer all in­for­ma­tion in encrypted form. In this way, it’s still possible to redirect the data over a false proxy, but criminals are much less likely to profit from the secure in­for­ma­tion, and in the best case scenario, won’t profit at all. If you operate your own site, switching to HTTPS is a must today. You always have the option to avoid HTTPoxy in general by simply removing the vul­ner­a­bil­i­ty. Because the proxy header is reg­is­tered neither as an IETF standard or an official IANA header, you can safely intercept it before it reaches your web ap­pli­ca­tion. By default, standard HTTP clients and servers don’t send any data packages with this header. In addition to en­crypt­ing the HTTP data exchange, you have two different ways to keep dangerous requests away from your web project:

1. Filter out the proxy header from all incoming packages.
2. Au­to­mat­i­cal­ly block all incoming packages that contain a proxy header.

The first option is much more common, and can be ac­com­plished using any common web server, proxy, or load balancing software. In the following sections you’ll find in­for­ma­tion on how to withdraw po­ten­tial­ly dangerous headers from the data traffic on various Linux dis­tri­b­u­tions with the help of the web server ap­pli­ca­tions Apache and NGINX, as well as the proxy server software HAProxy.

Avoid HTTPoxy with Apache

The free software Apache is installed by default on all common Linux dis­tri­b­u­tions and is still the top choice for many when it comes to operating your own web server. One feature of the program, among others, is the module mod_headers, which allows you to filter out the proxy header from all incoming HTTP requests. The strategy differs slightly from dis­tri­b­u­tion to dis­tri­b­u­tion.

Ubuntu and Debian:

The first step is to activate the module, which is done with the following command:

Then open Apache’s central con­fig­u­ra­tion file with an editor, for which the command line tool nano (used in the example) is rec­om­mend­ed:

Now expand this file at the end with the following entry:

After you’ve saved the file, activate the HTTPoxy pro­tec­tion by loading specified con­fig­u­ra­tion file via a2enconf script and restart­ing the server:

CentOS and Fedora:

If you’re using a version of the Linux dis­tri­b­u­tions CentOS or Fedora, that mod_headers module is already activated by default, so you can skip this step and go right to opening the con­fig­u­ra­tion file:

Insert the new entry at the end:

Then save the changes and restart the Apache server:

Remove HTTP proxy header with NGINX

As a web server ap­pli­ca­tion, NGINX is now an es­tab­lished force that’s growing in pop­u­lar­i­ty. With the help of the open source software, only a few steps are required to protect CGI ap­pli­ca­tions that run on the server or between the client and the server from the HTTPoxy security gap.

Ubuntu and Debian:

FastCGI pa­ra­me­ters (FastCGI is an op­ti­miza­tion of the CGI standards) under Ubuntu and Debian are usually contained in the fastcgi_params or fastcgi.conf files if you install an NGINX FastCGI proxy. In both files, you can cut off the proxy header in HTTP requests. Simply use the following lines of code:

If you use NGINX as a con­ven­tion­al HTTP proxy, you can also filter out the header. To do this, enter the cor­re­spond­ing rule into the proxy_params file that lists the pa­ra­me­ters for the proxy server:

In the last line, restart NGINX with the command:

CentOS and Fedora:

The strategy for banning HTTPoxy hazards for FastCGI proxies on CentOS or Fedora don’t vary that much from the strate­gies for Ubuntu and Debian systems. Since the NGINX con­fig­u­ra­tions on these dis­tri­b­u­tions are set in either the fastcgi_params or fastcgi.conf files, you can also shut off the proxy header here with the commands listed earlier:

To protect con­ven­tion­al proxies under Fedora and CentOS, you have to make sure that the header is blocked every­where that NGINX runs the proxy_pass directive. To find out where these are used, you can rely on the services of the grep search command:

This contains a list of the text files with the directive, where the outputs look something like the following example:

In this case, proxy_pass would be in the NFINX con­fig­u­ra­tion file. The cor­re­spond­ing entry in nginx.conf should be added as follows:

In both cases, you finish by restart­ing the server:

Protect your HAProxy server from HTTPoxy

If you forward HTTP requests to your web project through a HAProxy server, you can remove the proxy header even before the proxy sends the requests. The method doesn’t differ between the variously named Linux dis­tri­b­u­tions. First, open the central con­fig­u­ra­tion files of the proxy ap­pli­ca­tion with the following command:

Now open the haproxy.cfg file with the same nano command line editor as earlier. If you specified an al­ter­na­tive directory for HAProxy during in­stal­la­tion, then you need to adopt the command ac­cord­ing­ly.

In the opened file, you can now insert an HTTP request directive to remove the unwanted header in the three sections “frontend”, “backend”, and “listen”. The result looks as follows:

Save the changes and restart the HAProxy service:

To use the service, just enter the URL of the web ap­pli­ca­tion you want to check into the input field and click “Test”.