Vulnerability Note VU#150227

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:

6. Security Considerations

   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").

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.
The CERT/CC has received numerous reports of this technique being used to connect to SMTP services (25/tcp) to initiate the delivery of unsolicited bulk email (UCE/SPAM).

If a proxy service allows recursive connections, an attacker may be able to cause a denial-of-service condition by consuming resources by making repeated connections from the proxy service back to itself.

Apply Patch or Upgrade

Apply a patch or upgrade from your vendor. For information about a specific vendor, check the Systems Affected section of this document or contact your vendor directly.

Vendors listed as "Not Vulnerable" ship HTTP proxy services with reasonably secure default configurations, meaning that the proxy only allows connections to a limited number of TCP ports, or only listens on an internal or loopback interface, or requires further configuration before it will pass traffic. The vendor ships a secure or disabled proxy, and the responsibility of configuring the proxy is placed on the administrator. Note that almost any proxy service, including those from vendors listed as "Not Vulnerable," can be configured insecurely. Different distributions or packages may configure the same proxy application in different ways.

Secure Proxy Configuration

Check the configuration of your proxy services to determine if they allow connections to arbitrary TCP ports and whether they allow connections from untrusted networks such as the Internet. Configure your proxy services to only allow connections from trusted networks to reasonably safe TCP ports such as HTTP (80/tcp) and HTTPS (443/tcp). If possible, configure your proxy services not to allow recursive connections. For more information about specific products, check the Systems Affected section of this document, consult your product documentation, or contact your vendor.

Examine Tunneled Data

If possible, configure your HTTP proxy services to check the application layer contents of HTTP CONNECT method tunnels. Even if an HTTP proxy service is not able to decrypt HTTPS data, the proxy service could examine the initial stages of an HTTP CONNECT method connection to confirm that an SSL/TLS handshake is indeed being performed.