Vulnerability Note VU#435052
Intercepting proxy servers may incorrectly rely on HTTP headers to make connections
Proxy servers running in interception mode ("transparent" proxies) that make connection decisions based on HTTP header values may be used by an attacker to relay connections.
HTTP Host Headers are defined in RFC 2616 and are often used to by web servers to allow multiple websites to share a single IP address.
From RFC 2616:
A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for <http://www.w3.org/pub/WWW/> would properly include:
GET /pub/WWW/ HTTP/1.1
A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
Transparent proxy servers intercept and redirect network connections without user interaction or browser configuration. Some transparent intercepting proxy implementations make connection decisions based on the HTTP host-header value. Browser plugins (Flash, Java, etc) may enforce access controls on active content by limiting communication to the site or domain that the content originated from. An attacker may be able to forge HTTP host-header (or other HTTP headers) via active content. A proxy server running in intercepting ("transparent") mode that makes connection decisions based on HTTP header values instead of source and destination IP addresses is vulnerable due the ability of a remote attacker to forge these values.
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. Note that this vulnerability only affects proxy servers that run in transparent mode and browser same origin policies prevent attackers from re-using authentication credentials (cookies, etc) to obtain further access. This issue does not apply to proxy servers running in reverse mode.
More information about this issue can be found in the Socket Capable Browser Plugins Result In Transparent Proxy Abuse paper.
An attacker may be able to make full connections to any website or resource that the proxy can connect to. These sites may include internal resources such as intranet sites that would not usually be exposed to the Internet.
When possible, administrators are recommended to obtain updated software. See the systems affected section of this document for a partial list of affected vendors. In network architectures using NAT, fixing this issue may not be feasible. Administrators are encouraged to review the below workarounds.
Administrators can determine if their proxy server is vulnerable by reading the "Reproduction Instructions" section of the Socket Capable Browser Plugins Result In Transparent Proxy Abuse paper.
Workarounds for Administrators
It is possible to limit the impact of this vulnerability by restricting access in several ways. None of the below workarounds solve the issue, but they will significantly reduce the impact.
- Because an attacker can not access HTTP cookies, internal services that use an authentication scheme (such as a username/password) are not likely to be affected.
- Network designs that have limited connectivity between the proxy and internal services will prevent an attacker from obtaining direct access to these services via the proxy. Administrators should consider using access control lists or firewall rules to prevent direct connections between internal servers and proxy servers.
- Administrators should limit the CONNECT method to only the minimum required port range (usually 443/tcp).
- Limiting the range of ports a proxy server can communicate on will limit what resources an attacker can target. When possible, router or switch access control lists should be configured to prevent HTTP proxy servers using ports or protocols that they should not normally need access to. HTTP proxy servers do not usually need to communicate with well known ports other than 80/tcp and 443/tcp.
Workarounds for users
Workarounds for proxy server vendors
- To exploit this issue an attacker needs to execute active content (Java, Flash, Silverlight, etc) in the context of a web browser. Mozilla Firefox users should consider using the NoScript plugin to whitelist sites that can execute dynamic content. See the Securing Your Web Browser document for more information about secure browser configurations.
Although these workarounds will not address the underlying issue, vendors who distribute HTTP proxy servers are encouraged to implement them to mitigate future vulnerabilities.
- In default configurations the proxy server should only be able to connect to a limited number of well known ports.
- The CONNECT method should only be allowed for traffic that uses destination port 443/tcp, unless the proxy is designed to act as a TCP tunnel on all ports.
If you are a vendor and your product is affected, let
us know.View More »
|Vendor||Status||Date Notified||Date Updated|
|Apple Computer, Inc.||Affected||09 Dec 2008||11 Sep 2009|
|Astaro||Affected||-||30 Apr 2009|
|Blue Coat Systems||Affected||02 Jan 2009||04 Mar 2009|
|Internet Initiative Japan||Affected||-||13 Apr 2009|
|QBIK New Zealand Limited||Affected||15 Jan 2009||21 Jan 2009|
|SmoothWall||Affected||09 Dec 2008||20 Feb 2009|
|Squid||Affected||02 Jan 2009||23 Feb 2009|
|Ziproxy||Affected||13 Jan 2009||07 Aug 2009|
|Borderware Technologies||Not Affected||09 Dec 2008||03 Feb 2009|
|Check Point Software Technologies||Not Affected||09 Dec 2008||20 Feb 2009|
|Cisco Systems, Inc.||Not Affected||09 Dec 2008||12 Mar 2009|
|Cray Inc.||Not Affected||09 Dec 2008||17 Dec 2008|
|Debian GNU/Linux||Not Affected||09 Dec 2008||20 Feb 2009|
|Extreme Networks||Not Affected||09 Dec 2008||24 Apr 2009|
|Force10 Networks, Inc.||Not Affected||09 Dec 2008||04 Feb 2009|
Thanks to Robert Auger from the PayPal Information Risk Management team for reporting this issue as well as providing technical information.
This document was written by Ryan Giobbi.
23 Feb 2009
Date First Published:
23 Feb 2009
Date Last Updated:
28 Sep 2009
If you have feedback, comments, or additional information about this vulnerability, please send us email.