PDA

View Full Version : HTTP proxy vulnerabilty......



jim
05-23-2002, 03:44 PM
I have found this , what do you think about ?

Vulnerability Note VU#*50227
Multiple vendors' HTTP proxy default configurations allow arbitrary TCP connections via HTTP CONNECT method
Overview
Multiple vendors' HTTP proxy services use insecure default configurations that could allow an attacker to make arbitrary TCP connections to internal hosts or external third-party hosts.
I. Description
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 ***8 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 ***********, 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
44* for HTTPS, 56* for SNEWS, as assigned by IANA, the Internet
Assigned Numbers Authority).

Ports of specific concern are such as the telnet port (port 2*), SMTP
port (port 25) and many UNIX specific service ports (range 5*2-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 interfaces and to allow HTTP CONNECT method tunnels to any TCP port. Since most proxy services do not inspect application layer data in a 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#8682**). 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, caches, firewalls, and content/virus scanners may provide HTTP proxy services.
II. Impact
The HTTP CONNECT method can be abused to establish arbitrary TCP connections through vulnerable proxy services. The CERT/** has received reports of this technique being used to connect to SMTP services (25/tcp) to initiate the delivery of unsolicited bulk email (spam). In a more dangerous case, an attacker may be able to establish a connection from a public network through a vulnerable proxy service to an internal network. If a proxy service allows recursive connections, an attacker may be able to cause a denial-of-service condition by consuming resources
III. Solution
Secure Proxy Configuration
Examine the configuration of your proxy services to determine if they allow HTTP CONNECT method 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 HTTPS (44*/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.


Systems Affected
Vendor Status Date Updated
Squid Not Vulnerable *2-Apr-2002
Apache Not Vulnerable *2-Apr-2002
Check Point Vulnerable *7-May-2002
Junkbusters Not Vulnerable *2-Apr-2002
Trend Micro Vulnerable *2-Apr-2002
CacheFlow Inc. Unknown *2-Apr-2002
Finjan Software Unknown *2-Apr-2002
TIS Not Vulnerable *6-Apr-2002
CERN Unknown **-Apr-2002
Cisco Vulnerable *6-May-2002

Unregistered
05-24-2002, 08:51 PM
This is very nice story, but what the hell is the point jim ?