ProxySG in transparent deployments intercepting HTTP/HTTPS traffic

Advisory Date

March 2, 2009

Advisory Severity

Moderate

Details

This impacts ProxySG in transparent deployments intercepting HTTP/HTTPS traffic.

An attacker may compromise a browser plug-in (Flash, Java Applet etc) to insert an HTTP Host header in an HTTP/HTTPS request. By default, ProxySG relies on the HTTP Host header to determine which upstream host to connect to and so will end up connecting to the host indicated in the forged Host header. This might allow the attacker to access any servers that proxy can access to including servers that were not exposed to external users, rather than being limited to the server the plug-in or applet was downloaded from.

Workaround:

This is not a deficiency in ProxySG. Its choice to always resolve the hostname in Host headers by default is in fact a security feature to prevent clients from connecting to unauthorized hosts. However, in transparent deployments it does allow the attacker to attempt this attack. The ProxySG provides the following features that enable administrators to either limit the impact or completely avoid this vulnerability:

·        Use ProxySG policy controls to restrict proxy access to servers. Following are some policy examples that are relevant to this attack.

o       Restrict HTTP requests going to non-standard http port

      <Proxy>

             DENY url.scheme=http url.port=!80

o       Restrict HTTPS requests going to non-standard https port

<Proxy>

             DENY url.scheme=https url.port=!443

o       Deny HTTP requests going to an external address where the Host header contains an address in internal subnet

<Proxy>
 DENY proxy.address=!internal_subnets url.address=internal_subnets
 

define subnet internal_subnets

    10.0.0.0/8
    192.168.0.0/16
end subnet
 

·        Enable the trust-destination-ip setting (only available on SGOS 5.2 onwards). This can be done through configuration or policy. Enabling this setting will cause the ProxySG to trust the destination IP over the host specified in the Host header, thus completely ignoring the forged Host header that the attacker inserted.

Caveat: If your deployment is using a content-filtering solution to restrict user access, enabling trust-destination-ip may cause an attacker to bypass this restriction – if an attacker sends an HTTP request with destination IP of a blocked site and a Host header containing a hostname of a non-blocked site, the ProxySG will end up allowing such a request since content filtering uses the Host header. Enabling trust-destination-ip is not recommended in this type of deployment.

Affected Versions:
All

Reference:

US-Cert Vulnerability Note VU#435052

 

Severity: 
Moderate
Advisory Date: 
March 2, 2009
Advisory Publish Time: 
03/02/2009 - 00:45