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:
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.
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.
Workarounds for users
Although these workarounds will not address the underlying issue, vendors who distribute HTTP proxy servers are encouraged to implement them to mitigate future vulnerabilities.
Systems Affected (Learn 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|
CVSS Metrics (Learn More)
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.
- CVE IDs: Unknown
- Date Public: 23 Feb 2009
- Date First Published: 23 Feb 2009
- Date Last Updated: 28 Sep 2009
- Severity Metric: 3.54
- Document Revision: 139
If you have feedback, comments, or additional information about this vulnerability, please send us email.