|Security Advisory ID SYMSA1319|
Initial Publication Date:
14 Apr 2015
HTTP 407 authentication challenges are passed through to clients by ProxySG by default. In an explicit proxy deployment, the client will complete the authentication handshake with the attacker. An attacker can use this default behavior to exploit weaknesses in authentication protocols such as NTLM to obtain proxy user credentials.
The following products are vulnerable:
All versions of ProxySG 5.x, 6.2 prior 188.8.131.52, 6.5 prior to 184.108.40.206, and 6.6 prior to 220.127.116.11 are vulnerable when used in an explicit proxy deployment that uses NTLM for user authentication.
No other products are vulnerable.
The following releases change the default behavior of ProxySG to block HTTP 407 challenges. This change may require additional steps to restore the required behavior. See Technical Alert 24584 for more information and CPL samples.
SGOS 6.6 - a fix is available in 18.104.22.168.
SGOS 6.5 - a fix is available in 22.214.171.124. Blue Coat recommends using 126.96.36.199 and later.
SGOS 6.2 - a fix is available in 188.8.131.52.
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 184.108.40.206. 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.
Microsoft statement on NTLM - https://msdn.microsoft.com/en-us/library/cc236715.aspx
Pass the Hash - https://en.wikipedia.org/wiki/Pass_the_hash
Rainbow Tables - https://en.wikipedia.org/wiki/Rainbow_table
2017-09-05 Corrected typo in list of vulnerable releases in Affected Products section.
2015-10-02 Marked status as final
2015-10-01 Fixes for SGOS 6.6 and 6.2 are avialable
2015-07-13 Title Update
2015-06-05 Added CVE number
2015-6-04 Recommend that customers use SGOS 220.127.116.11 and later; noted that this behavior has been in ProxySG since inception; clarified the scope of vulnerabiliy
2015-04-23 Changed name of the SA; clarified that this vulnerability is specific to ProxySG
2015-04-23 Clarified details of the vulnerability, stressed the need to upgrade from NTLM to more secure authentication protocols, added new references to pass-the-hash and rainbow tables
2015-04-14 Initial public release