Prevent NTLM credentials from being forwarded to a malicious OCS
search cancel

Prevent NTLM credentials from being forwarded to a malicious OCS

book

Article ID: 185093

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

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:

  • You have applied the fix in SGOS 6.5.7.x 
  • You are unable to upgrade to SGOS 6.5.7.x 

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:

  • Explicit proxies with IWA/NTLM authentication
  • Appliances running SGOS 6.5.6.x and earlier

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.
 

Environment

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.

Cause

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.

Resolution

Determine which solution you require:

Upgrade Solutions

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.

  1. Upgrade to SGOS 6.5.7.x. To download the Blue Coat system image (*.bcsi) file and Release Notes, log in to BTO and click Downloads.
  2. Allow 407 challenges using the #(config)http allow-upstream-407 command. See the Additional Information section in this TA.
  3. Verify that appliance policy includes conditions for making forwarding decisions. If needed, modify these conditions to allow 407 challenges only from the known upstream proxies. See the content policy language (CPL) sample in Additional Information section in this TA.

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. 

  1. Upgrade to SGOS 6.5.7.x. To download the Blue Coat system image (*.bcsi) file and Release Notes, log in to BTO and click Downloads.
  2. Allow 407 challenges using the #(config)http allow-upstream-407 command. See the Additional Information section in this TA.
  3. On the upstream proxies, block 407 challenges from malicious servers:
  • See the CPL sample in Additional Information section for steps to allow 407 challenges only from known upstream proxies.
  • The highest upstream proxy in the hierarchy should block all 407 challenges by default; you do not have to make changes on this proxy.

Policy Solutions

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:
 

<Proxy> 
    http.response.code=407 force_exception(policy_denied, "Blocked upstream 407 from OCS")

where policy_denied is the exception ID and the text in quotation marks provides details for the exception. You can put any text, including CPL substitution patterns, in the details.
 
When the proxy receives a 407 challenge, the challenge is blocked and the user receives an exception. For more information on the CPL in this sample or policies appropriate to your setup, refer to the Content Policy Language Reference.
 
Policy solution 2: Authenticating upstream proxies
In a proxy chain, if the downstream ProxySG appliance forwards user requests to upstream proxies that issue 407 challenges, allow 407 challenges only from those known upstream proxies. On the ProxySG appliance, verify that appliance policy includes conditions for making forwarding decisions. If needed, modify these conditions to allow 407 challenges only from the known upstream proxies. See the CPL sample in Additional Information section in this TA.

Policy solution 3: Transparent proxy with upstream explicit proxies
 If the downstream ProxySG appliance is a transparent proxy and there are explicit proxies upstream, allow all 407 challenges on the downstream proxy. 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. On the upstream proxies, create policy to block 407 challenges from malicious servers. See the CPL sample in Additional Information section in this TA.

Additional Information

Important Note About Proxy Without SSL Interception

The solutions in this TA apply to HTTP and SSL intercepted/decrypted HTTPS 407 challenges. If your appliance does not perform SSL intercept/decryption, it has no visibility into HTTPS traffic and thus cannot detect the 407 challenges. You can resolve this using either of the following methods: CPL Sample for Handling 407 Challenges

This CPL sample represents a possible use case for handling 407 challenges. When the downstream proxy receives a 407 challenge, the following policy checks to see if the request had been forwarded. If the request was forwarded, the 407 challenge is allowed; otherwise, the user receives an exception.

Note: The following sample includes upstream_407_rejected, a built-in exception introduced in SGOS 6.5.7.x. If you are not upgrading to SGOS 6.5.7.x, use another built-in exception or define your own. The sample uses policy_denied exception and provides details in quotation marks for previous SGOS versions.

Blue Coat recommends that you write and test policy that is appropriate to your deployment; for information on CPL usage and creating exceptions, refer to the Content Policy Language Reference.
 
<Forward>
    condition=should_forward forward(some_forwarding_host)
 
<Proxy> http.response.code=407
    condition= should_forward
    ; Use the following for 6.5.7.x
    force_exception(upstream_407_rejected)
     ; Use the following for pre-6.5.7.x
    force_exception(policy_denied, "Blocked upstream 407 from OCS")
 
define condition should_forward
    ; Insert conditional checks here
end 

CLI to Allow and Block Upstream 407 Challenges

The following CLI was added in SGOS 6.5.7.x:

#(config) http allow-upstream-407
Allow upstream 407 challenges.
 
#(config) http no allow-upstream-407
(If previously set to allow) Do not allow upstream 407 challenges.
Powered by Wolken Software