Vulnerability Note VU#150227
HTTP proxy default configurations allow arbitrary TCP connections
Multiple vendors' HTTP proxy services use insecure default configurations that could allow an attacker to make arbitrary TCP connections to internal hosts or to external third-party hosts.
HTTP proxy services commonly support the HTTP CONNECT method, which is designed to create a TCP connection that bypasses the normal application layer functionality of the proxy service. Typically, the HTTP CONNECT method is used to tunnel HTTPS connections through an HTTP proxy. The proxy service does not decrypt the HTTPS traffic, as this would violate the end-to-end security model used by TLS/SSL.
The HTTP CONNECT method is described in an expired IETF Internet-Draft written in 1998 by Ari Luotonen. This document clearly explains the security risks associated with the HTTP CONNECT method:
The CONNECT tunneling mechanism is really a lower-level function than
the rest of the HTTP methods, kind of an escape mechanism for saying
that the proxy should not interfere with the transaction, but merely
forward the data. In the case of SSL tunneling, this is because the
proxy should not need to know the entire URI that is being accessed
(privacy, security), only the information that it explicitly needs
(hostname and port number) in order to carry out its part.
Due to this fact, the proxy cannot necessarily verify that the
protocol being spoken is really what it is supposed to tunnel (SSL
for example), and so the proxy configuration should explicitly limit
allowed connections to well-known ports for that protocol (such as
443 for HTTPS, 563 for SNEWS, as assigned by IANA, the Internet
Assigned Numbers Authority).
Ports of specific concern are such as the telnet port (port 23), SMTP
port (port 25) and many UNIX specific service ports (range 512-600).
Allowing such tunnelled connections to e.g. the SMTP port might
enable sending of uncontrolled E-mail ("spam").
Many vendors' HTTP proxy services are configured by default to listen on all network interfaces and to allow HTTP CONNECT method tunnels to any TCP port. A proxy may also allow the GET method with a crafted HTTP 1.1 Host request-header and the POST method to be used to create arbitrary TCP connections. Other HTTP methods (PUT) and FTP commands (USER/PASS, SITE, OPEN) can also be used to make arbitrary TCP connections through proxy services. SOCKS proxies suffer from similar insecure default configuration vulnerabilities, as do products that provide FTP proxy services.
Since most proxy services do not inspect application layer data in an HTTP CONNECT method tunneled connection, almost any TCP-based protocol may be forwarded through the proxy service. This creates an additional vulnerability in the case of HTTP anti-virus scanners and content filters that do not check the contents of an HTTP CONNECT method tunnel [VU#868219]. In addition, an attacker may be able to cause a denial of service by making recursive connections to a proxy service. Note that a wide variety of products including proxy servers, web servers, web caches, firewalls, and content/virus scanners provide HTTP proxy services.
Most products can be configured to specify which networks can access the HTTP proxy service and which destination TCP ports (and possibly IP addresses) are permitted. Products that provide a reasonably secure default configuration are noted as "Not Vulnerable" in the Systems Affected section of this document. It is important to note that any proxy service can be configured insecurely, potentially allowing access from any source to any destination IP address and TCP port.
The HTTP CONNECT method, as well as other HTTP methods and FTP commands, can be abused to establish arbitrary TCP connections through vulnerable proxy services. An attacker could use a vulnerable proxy service on one network as an intermediary to scan or connect to TCP services on another network. In a more severe case, an attacker may be able to establish a connection from a public network, such as the Internet, through a vulnerable proxy service to an internal network.
Systems Affected (Learn More)
|Vendor||Status||Date Notified||Date Updated|
|AnalogX||Affected||-||23 Sep 2003|
|Astaro Security Linux||Affected||-||19 Jun 2003|
|CacheFlow Inc.||Affected||-||15 Sep 2003|
|Cisco Systems Inc.||Affected||19 Apr 2002||16 May 2002|
|IBM||Affected||19 Apr 2002||23 Sep 2003|
|Kerio||Affected||-||15 Oct 2002|
|Novell||Affected||19 Apr 2002||19 Jun 2003|
|Symantec Corporation||Affected||19 Apr 2002||19 Jun 2003|
|Tiny Software||Affected||-||25 Jun 2002|
|Trend Micro||Affected||19 Apr 2002||10 Feb 2003|
|WebWasher||Affected||-||19 Jun 2003|
|Alcatel||Not Affected||19 Apr 2002||20 Jun 2002|
|Apache||Not Affected||19 Apr 2002||16 Oct 2002|
|Check Point||Not Affected||19 Apr 2002||23 Jul 2002|
|DeleGate||Not Affected||-||29 Jun 2004|
CVSS Metrics (Learn More)
An instance of this vulnerability in Check Point FireWall-1 was reported by Volker Tanger in February 2002. The CERT/CC thanks Ronald Guilmette for information used in this document.
This document was written by Art Manion.
- CVE IDs: Unknown
- Date Public: 19 Feb 2002
- Date First Published: 17 May 2002
- Date Last Updated: 29 Apr 2005
- Severity Metric: 89.50
- Document Revision: 104
If you have feedback, comments, or additional information about this vulnerability, please send us email.