Proxy server bug exposes websites' private parts
By the dozen
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Updated Computer networks that use proxy servers to automatically redirect browser connections should be on the lookout for a serious architectural flaw that could allow attackers to remotely access intranets and other website resources that are normally off limits, security experts are warning.
At least four proxy server vendors, including QBIK New Zealand, SmoothWall, Squid and Ziproxy remain vulnerable to flaw, according to this advisory from the US Computer Emergency Readiness Team. Products from several dozen additional vendors were vulnerable but have been updated in the past few weeks. Network administrators will need to install the latest versions to ensure their networks aren't vulnerable.
The architectural flaw affects proxy servers that run in what's known as transparent interception mode. The configuration allows servers to intercept and redirect network connections without any user interaction or special browser settings. To exploit the bug, attackers can manipulate host header values using active content such as Java and Flash.
"An attacker may be able to make full connections to any website or resource that the proxy can connect to," CERT warns. "These sites may include internal resources such as intranet sites that would not usually be exposed to the internet."
The vulnerability was originally reported by Robert Auger of PayPal's Information Risk Management team. In a note posted on Cgisecurity.com, he said he planned to release a more detailed technical analysis in March, presumably after network administrators have had a chance to patch vulnerable networks. Based on the bare-bones analysis provided by CERT, it appears the bug may also threaten end users, presumably through phishing attacks.
"To successfully exploit this issue, an attacker would need to either convince a user to visit a web page with malicious active content or be able to load the active content in an otherwise trusted site," the advisory reads.
The good news is that the vulnerability only seems to affect proxy servers running in transparent mode. Browser same-origin policies, which prevent cookies and other types of content set by one domain from being accessed or manipulated by a different address, make it hard for attackers to reuse authentication credentials to gain unauthorized access.
CERT is encouraging admins to update their proxy servers and in the meantime to follow a series of workarounds.
It remains unclear how common transparent interception is used in proxy servers. While several security experts said few large companies use it, Kevin Johnson, a senior security analyst at InGuardians, said the configuration is often used when implementing reverse proxies for load balancing, content caching and other network management services.
"It's a good thing this was announced," he told The Register. "Proxy servers have been a point of interest for the last decade." ®
COMMENTS
lol this is really an old old bug!
I used to do this to bypass crap security at work back in the day when Quake 1 was still brand new.
Lack of imagination
If I understood AC's explanation, an applet could access arbitrary intranet sites while appearing to the browser and VM to be communicating with its host site. Routers with default configuration and web admin interface enabled are an obvious target. Trivial to script a session to add lax firewall rules. You DO read your proxy logs, right?
Not convinced of the seriousness of this one
For those who know a little about HTTP, this vulnerability is basically to do with the fact that many transparent proxies make a connection directly to what's in the "Host:" header of a request, *not to the original destination IP*. So I could, for example, make an outbound connection to the IP address of google.com on port 80, send an HTTP request with the "Host:" header set to the hostname of an internal machine, and end up connected to the internal machine rather than Google - without, if the code making the connection was hosted on google.com, necessarily breaking the security model of whatever sandbox environment my code runs in.
So having acknowledged the vulnerability... why do I say it's "not serious"? Well, for an attacker to exploit this, they have to know that a vulnerable transparent proxy is in use, trick someone into running their code, know the location of whatever is on the LAN that they want to access, and that resource has to be unsecured (i.e. accessible without username/password) or secured with details I have previously pilfered. Additionally, the code's environment has to allow me to make arbitrary TCP connections, because sandboxed no language which just provides a wrapper around HTTP requests should allow code to insert an arbitrary "Host:" header, so no JavaScript for you, script kiddies. Also, since the HTTP "CONNECT" request (used for HTTPS tunnels; can be abused for arbitrary tunnelling on badly configured proxies) doesn't use "Host:" headers, you can only access resources on plain old HTTP (no other protocols, not even HTTPS).
Workarounds are simple: require usernames & passwords for intranet sites, use HTTPS for intranet sites, explicitly deny access to intranet sites via access controls on the proxy, or best of all, *don't use a transparent proxy* (say it with me: TRANSPARENT PROXIES SUCK).
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
