This TA discusses a change to a default behavior on the ProxySG appliance, introduced in SGOS 6.5.7.x. The change was made to address a security vulnerability with how the appliance handles 407 authentication challenges. Although this vulnerability exists in any proxy deployment, the scope of this TA is limited to describing how to configure the ProxySG appliance to maintain current functionality in the following cases:
The vulnerability affects only explicit proxy deployments where enterprise credentials are at risk of being forwarded to a malicious upstream origin content server (OCS) that sends a 407 authentication challenge. This issue applies to deployments with:
SGOS 6.5.7.x addresses the vulnerability by changing the proxy's default behavior to block proxy 407 authentication challenges; please refer to Security Advisory SA93 for further details. After an upgrade to SGOS 6.5.7.x, depending on your network topology, you might have to perform additional steps to restore the required behavior. If you cannot upgrade to a version with the fix, you may have to configure the proxy to address the vulnerability. Refer to the Resolution section of this TA to determine if and how this issue affects your deployment and the steps you must take to resolve the issue.
Note: See the Additional Information section in this TA if the ProxySG appliance is an explicit proxy that does not intercept SSL.
In a deployment set up correctly for IWA authentication, if an upstream OCS presents HTTP status code 407 "Proxy authentication required", the browser automatically attempts an NTLM or Kerberos authentication when the site is in the browser's Local Intranet or Trusted Sites zone and the user is currently logged in to the Windows domain. The browser uses the user's domain and credentials for authentication. The vulnerability can be exploited when the browser is configured for explicit proxy, as follows:
Scenario 1: The user is logged in to the domain
The browser assumes the 407 challenge originated from the ProxySG appliance. Because the browser implicitly trusts the proxy, the user does not see an authentication prompt and the browser attempts authentication with the user's credentials.
Risk: The browser forwards credentials to the malicious OCS without the user’s knowledge.
Scenario 2: User is not logged in as a domain user, or is using a workstation not in the domain
The user receives an authentication prompt.
Risk: The user could be misled into thinking that the malicious 407 challenge is legitimate (originating from the ProxySG appliance) and enter their credentials.
All versions of SGOS 5.x and 6.x prior to 6.5.7.x are vulnerable when used in an explicit proxy deployment that uses NTLM for user authentication.
Determine which solution you require:
SGOS 6.5.7.x provides a fix for the security issue. After upgrading to this version, all upstream 407 challenges are blocked by default. As a result, users no longer see any upstream 407 challenges; they receive exception pages instead. Depending on your deployment and your organization's requirements, upgrade to SGOS 6.5.7.x for best security; after the upgrade, you might have to perform additional steps (described in the following solutions) to maintain your network behavior.
Determine which solution you require:
Upgrade solution 1: No authenticating upstream proxies
If there are no authenticating upstream proxies (or there is only one ProxySG appliance between the client and OCS), block all upstream 407 challenges. Upgrade to SGOS 6.5.7.x.
To download the Blue Coat system image (*.bcsi) file and Release Notes, log in to BlueTouch Online (BTO) and click Downloads.
Upgrade solution 2: Authenticating upstream proxies
In a proxy chain, if the downstream explicit ProxySG appliance forwards user requests to upstream proxies that issue 407 challenges, allow 407 challenges that originate from the known upstream proxies and block all others.
Upgrade solution 3: Transparent proxy with upstream explicit proxies
If the downstream ProxySG appliance is configured as a transparent proxy and there are explicit proxies upstream that might issue 407 challenges, allow all 407 challenges. Note that in this deployment, the transparent proxy cannot determine whether a 407 challenge originated from a legitimate upstream proxy or from a malicious website.
If you cannot upgrade to SGOS 6.5.7.x, you can create policy to address the security issue. Determine which solution you require:
Policy solution 1: No authenticating upstream proxies
If there are no authenticating upstream proxies (or there is only one ProxySG appliance between the client and OCS), block all upstream 407 challenges. Refer to the following CPL sample: