The latest branded vulnerability, "httpoxy," comes complete with a website and Twitter feed -- but this time, experts...
say, the effort was consistent with the responsible disclosure of the flaw.
The researchers discovered that the httpoxy vulnerabilities have been described many times since as early as 2001 and found in apps written with PHP, Python and Go, and could potentially be common in other programming languages. The httpoxy vulnerabilities don't allow remote code execution, but they do enable man-in-the-middle (MiTM) attacks against vulnerable web services.
"Httpoxy is a direct [man-in-the-middle attack]. But only for outgoing requests the server makes, and only for those made from the handler for an httpoxy-crafted request," said Dominic Scheirlinck, principal engineer, at the Auckland, New Zealand e-commerce firm Vend. Scheirlinck is the lead for the httpoxy disclosure team. "At this stage, we think you'd need to chain httpoxy with some other exploit to achieve further results, like affecting the requests made for other users."
Somehow, the vulnerability flew under the radar for many years; while it was first noted -- and fixed -- in a Perl library in March 2001 and in Curl in April 2001, Scheirlinck said: "Even though it was noticed in several places, at several times, nobody bothered to look outside the project they were working on at the time."
Httpoxy requires the code to be running under a CGI-like context that recognizes HTTP_PROXY as a real or emulated variable, an HTTP client that trusts HTTP_PROXY and will use that variable to configure as the web proxy, and making an HTTP (not an HTTPS) request.
Ultimately, the risks depend on what the site uses HTTP for internally, Scheirlinck told SearchSecurity by email. "If you have a billing back end, and the PHP app talks to it over HTTP, you have people potentially getting free access. Or, if you have an HTTP microservice that decides what permissions a user gets, you have people potentially getting elevated permissions, et cetera."
"The problem is that's different for every application. And we're unlikely to get embarrassing details like that for closed-source code; people will probably just stay quiet on what their exposure was."
Just how bad is it?
"I'd say the most interesting targets for exploitation would be to get secrets from the httpoxied request," Scheirlinck said. "For example, API keys that would otherwise be sent to an API. The 'tying up server resources' thing is easy to do, but I think the attacker would rather have a good confidential information leak."
Experts agreed it could have been worse, though httpoxy is bad enough. "It's not the worst category of vulnerabilities (remote code execution), but it does allow you to manipulate vulnerable web servers into sending traffic through a malicious proxy which allows for man-in-the-middle snooping," said John Bambenek, manager of threat systems at Fidelis Cybersecurity, based in Waltham, Mass. "This doesn't work over SSL/TLS so, in theory, any truly sensitive information is secure because it should be over an encrypted channel."
"In principle, this is a fairly significant vulnerability, at least with respect to the potential number of targets and its overall simplicity," said Lane Thames, security researcher at the Tripwire Vulnerability and Exposures Research Team (VERT); and because httpoxy affects web application servers, "it has a huge potential attack surface."
"Plus, it is a vulnerability where a remote attacker does not have to do much to potentially exploit it," Thames added. "Essentially, an attacker only needs to send a simple HTTP header payload to a vulnerable web application; utilizing the exploitation 'results' depends on the attacker's motive, for example, trying to DDoS an API endpoint versus implementing a MiTM attack."
"Anytime an attacker can manipulate the network behavior of a server, it is a problem," Bambenek said. "This allows you to snoop on traffic you should not be able to."
According to Christopher Robinson, manager at Red Hat's product security program management, "In a worst-case scenario, an attacker could possibly redirect outgoing HTTP traffic from a CGI script to other servers." In other words, outgoing authentication requests that are required to respond to the current request.
"This could lead to the disclosure of sensitive information contained within both request and response sent between the CGI script and HTTP server. On Linux, the majority of web applications no longer run as CGI scripts, meaning they are not vulnerable to this type of attack."
Referring to the first time the flaw was found -- and fixed -- Robinson said: "The world of security was quite a bit different back in 2001; it wasn't common to look at issues as having wide reaching consequences. Today, there are a large number of security researchers investigating issues like never before. Documentation, including best practices, has also improved significantly since then."
"Web apps were also quite different in 2001, and tended to be more monolithic. The idea of doing server-side HTTP requests while fulfilling a client-side request was also not very common. Today, it is a different world with distributed applications and microservices."
Responsible disclosure, or not?
As for the move to name the vulnerability, Scheirlinck said: "We thought about it very carefully; we know it's a controversial subject in the security disclosure community, and that there's the potential for grandstanding or dilution of the effectiveness of named disclosures if it becomes 'fashionable.'"
The decision depended on the fact that "httpoxy has existed (and been known about) for a long time, yet new occurrences of the vulnerability were still being introduced as late as 2016," Scheirlinck said. "Indeed, we found a large number of feature requests for HTTP clients to add the ability to read HTTP_PROXY in Github issues. The situation appeared to be getting worse, not better."
The httpoxy team also weighed the fact that "the libwww-perl, curl and Ruby teams all noticed at some point over the last 15 years, yet thousands of other applications remain vulnerable today. We could only think that was because their finding wasn't loudly and urgently transmitted to everyone else using CGI," Scheirlinck said. "We felt it called for a 'louder' fix that would name the problem and stop it from reoccurring in another 15 years."
Thames agreed that the vulnerability branding was consistent with the responsible disclosure of the flaw. "Based on the timeline, this vulnerability has been lurking for some time now. Maybe this will help to resolve the complete set of vulnerabilities as well as shine some light on the underlying cause to help us avoid a similar mistake in the future."
Find out more about responsible disclosure of security vulnerabilities.
Read about the ImageTragick vulnerability disclosure.
Learn more about ways to securely deploy PHP.