The following products are vulnerable:

ProxySG
All versions of ProxySG 5.x, 6.2 prior 6.2.16.5, 6.5 prior to 6.5.7.1, and 6.6 prior to 6.6.2.1 are vulnerable when used in an explicit proxy deployment that uses NTLM for user authentication.

No other products are vulnerable.

CVE-2015-4334 - CVSS v2 base score 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)

ProxySG allows HTTP 407 status codes (proxy authentication required) to be sent to the client from an upstream origin content server (OCS) by default.  This capability was added in 2001 to the early implementations of ProxySG to support proxy chaining - a situation in which traffic passes through more than one HTTP proxy before reaching the origin server.  In situations where multiple proxies in the chain require authentication, ProxySG allows challenges from all of the proxies without requiring all the proxies in the chain to be configured to know about each other.  The ability to use NTLM authentication for proxy users was added at the same time.

This feature is useful in many deployments and has been enabled by default in all versions of SGOS prior to 6.5.7.1.  Customers who were unaware of the behavior and how it could be used by a remote attacker may be vulnerable.  A remote attacker can use the default behavior to exploit other vulnerabilities in the authentication protocols used to authenticate proxy users in some deployment scenarios.  This Security Advisory applies only to the vulnerability in ProxySG wherein HTTP 407 status codes are sent to client by default.  Vulnerabilities in authentication protocols such as NTLM that can allow an attacker to recover authentication materials are covered by the vendors that implement and maintain the authentication protocols. 

Customers in an explicit proxy deployment are vulnerable to this ProxySG vulnerability if HTTP 407 status codes are not blocked for all HTTP and HTTPS traffic.  Customers not in an explicit proxy deployment are not vulnerable.

When a deployment is set up correctly for Integrated Windows Authentication (IWA), an upstream OCS presents the HTTP 407 status code and the browser automatically attempts to authenticate if the OCS is in the browser's Local Intranet or Trusted Sites zone and if the user is currently logged in to the Windows domain.  The browser uses the user's domain and credentials for authentication. ProxySG supports several ways of authenticating proxy users, one of which is NTLM. 

Authentication protocols do not send user passwords to the server.  Instead, cryptography is used to prove that the client has possession of the password.  A robust protocol with strong cryptography will not provide information about the user’s actual credentials even if the attacker is the server or a man-in-the-middle.  However, vulnerabilities in authentication protocols can be exploited by an attacker to obtain the user's password, or to obtain hashes or other artifacts (e.g., NTLM hashes) that allow the attacker to pose as the user to servers within the user’s environment.

This Proxy SG vulnerability can be exploited when the browser is configured for explicit proxy and one of the following scenarios is encountered:

Scenario 1:  The user is logged in to the domain.
The browser assumes the 407 challenge originated from the ProxySG.  Because the browser implicitly trusts the proxy, the user does not see an authentication prompt.  The browser attempts authentication with a malicious OCS or man-in-the-middle with the user's credentials. 

Scenario 2:  The user is not logged in as a domain user, or is using a workstation not in the domain.
The browser assumes the 407 challenge originated from the ProxySG and prompts the user for their credentials.  The user assumes the request is legitimate and enters their credentials.  The browser then attempts authentication with a malicious OCS or main-in-the-middle.

Blocking all HTTP 407 challenges from HTTP and HTTPS will address this vulnerability in ProxySG.  However, it will not address any underlying vulnerabilities in the authentication protocols being used.  NTLM is of particular concern.

NTLM uses weak cryptography in the creation of the hash that is used to authenticate the user.  There are known weaknesses in NTLM that allow an attacker to obtain the user’s credentials from the hash by using rainbow tables.  There are also known attacks against NTLM that allow an attacker to use the hash itself (without discovering the credential) to authenticate as the user using a technique referred to as “pass the hash.”  These attacks are specific to NTLM and are not possible with Kerberos or SAML.  Customers using NTLM are urged to upgrade to a more secure authentication protocol such as Kerberos or SAML for best protection. 

Microsoft no longer recommends use of NTLM.  Blue Coat strongly recommends that customers upgrade to a stronger authentication protocol such as Kerberos or SAML.

If that is not an option, set policies in ProxySG to limit access by an attacker based on your deployment type.  See Blue Coat Technical Alert 24584 for more information and CPL samples.  If ProxySG does not perform SSL/TLS interception, it has no visibility into HTTPS traffic and thus cannot detect 407 challenges.  To protect against an attacker using an encrypted session, SSL/TLS interception must be enabled.  If that is not possible, blocking unsafe categories will provide a partial workaround.