The vulnerability d’jour this week was named HTTPoxy, an applicable pun on pox and proxy. We have patched our servers for this already, and are here to take a few extra steps to help explain the vulnerability and hopefully spread a little knowledge.
The first part of this post will explain how the HTTPoxy vulnerability works, and later I will discuss how it may affect WordPress sites.
TL;DR: Skip ahead to read how it affects WordPress sites.
Here are a few key words / definitions to keep in mind for the following reading:
Request Header: This is a list of free-form fields of which browsers or web clients sent to a web server.
Proxy: In technology, a proxy is a service that acts as an intermediary for requests from clients seeking resources from other servers.
API: In this context web service APIs are interfaces with third party systems to exchange or process data.
This vulnerability is surprisingly not new, a similar flaw was reported in libwww-perl back in 2001. This is a reminder that sometimes vulnerabilities will keep coming back until they’re ingrained in people’s minds — perhaps that’s one good side effect of the logo+website method of vulnerability disclosure.
The issue is simple, developers wrote code and assuming a system environment variable “HTTP_PROXY” can only by the system. This assumption can be incorrect in some of the most popular environments when the servers (nginx, apache, etc..) pass on information they have about the request to the CGI (php, perl, ruby, etc…) environment allowing a visitor to the site to set the HTTP_PROXY value.
This is all caused by request header variables, which are set by the visitor, then renamed “HTTP_variable name” in the code. The problem here, is that a request header variable named “Proxy” gets renamed to: “HTTP_PROXY”. Then in turn if the code uses the value of “HTTP_PROXY” as it’s value to proxy any outgoing HTTP connections it needs to make, you have the perfect storm that creates this vulnerability.
The biggest problem that would enable this to be a major concern is, Web based APIs.
APIs or other methods in a site’s codebase are used to communicate with remote servers, typically over HTTP are common. They enable a site to be able to talk with other servers, like payment processors, user authentication services and much more to get a task done. If your site does this, perhaps via a plugin or other add-on, and that code inadvertently trusts the value of the HTTP_PROXY to use as a Proxy for it’s connections when sending API requests … well, that will be a problem. Here is two ways it would make you have a very bad day:
Some APIs require requests to be sent with secret values, this is how they validate who you are and allow you access to the actions you can take. Since the secret key value is sent with every request, they can be stolen if the API request is sent to a server under the attacker’s control. The attackers would then be able to use your API key to tell the service to do whatever that API allows of you! (Imagine how bad this would be if your API key for your payment processor was stolen?)
Man in the Middle:
The example of a man in the middle attack would affect a site that uses an API to validate an action being attempted. The attackers would send the request to your site with their malicious proxy information and when the site attempts to validate the action the attacker’s proxy always responds how the attacker wants. What should be a failed login, the attackers proxy would respond with successful login. What should have been a declined charge, the attacker’s proxy can say went through, which could mean you’re sending out a product that was never actually paid for.
Sounds scary enough to me, but does this affect WordPress?
The WordPress core is not affected. It does not rely on an API for authentication or other purposes, nor does it utilize the value of HTTP_PROXY for any purpose. However, plugins are a different matter.
With the concerns of the community in mind, I began auditing the source code of every active WordPress plugin to identify what plugins may be vulnerable. In total over 2 dozen likely vulnerable plugins were identified as at risk due to blindly trusting the HTTP_PROXY value. The information gathered was forwarded to the plugin team about the findings. Much thanks goes out to @ipstenu the Representative of the Plugin Repository Team (aka Lead Plugin Repo Wrangler) who volunteered to help spread the word to the plugin authors so they can fix the problem in their code.
The majority of affected plugins were caused by libraries they included. While not the plugin author’s direct fault, it’s hopeful that they’ll update their plugin’s library quickly. This would also be a time to remember the importance of keeping a code base’s libraries up to date, especially in the case of security issues that may crop up.
For the time being, hosts can apply patches to purge the “Proxy” header (as explained on httpoxy.org), we have done this ourselves but we hope that taking the extra step and getting the plugins patched directly will help avoid any further bad press for WordPress security and community.
For more on how we handle reverse proxy hosting here at Pagely, read this.