Vulnerability Note VU#435052

Intercepting proxy servers may incorrectly rely on HTTP headers to make connections

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
Host: www.w3.org

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.

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.

• 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.

• 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.

http://www.thesecuritypractice.com/the_security_practice/TransparentProxyAbuse.pdf
http://www.ietf.org/rfc/rfc2616.txt
http://www.webappsec.org/lists/websecurity/archive/2008-06/msg00073.html
http://www.us-cert.gov/reading_room/securing_browser/
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14213
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
http://www.owasp.org/index.php/Testing_for_HTTP_Methods_and_XST_(OWASP-CM-008)#Black_Box_testing_and_example
http://en.wikipedia.org/w/index.php?title=List_of_TCP_and_UDP_port_numbers&oldid=266934839

Credit

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.

Other Information

If you have feedback, comments, or additional information about this vulnerability, please send us email.