Remote Code Execution On All Enterprise Workstations Simultaneously - A Vulnerability in Jetro Cockpit Secure Browsing -or-The Irony of Insecure Security Software

A Hebrew summary is available here.  
 
Update 1 (2014-09-02): The finding received a CVE listing number CVE 2014-1861
Update 2 (2014-24-02): Vendor response added as per their request.


Overview

Browsing the web is dangerous.

Hackers are constantly searching for vulnerabilities in popular software. Between the OS, browser, browser plug-ins, Java, Office, PDF Readers, etc., an average machine runs a lot of complex code which is never bug-free. It's no wonder then, that news of critical vulnerabilities are common, and being fully patched is a constant race. For a security-conscious organization with hundreds of workstations containing sensitive data, secure browsing becomes top priority.

Jetro Cockpit Secure Browsing's (JCSB) solution is network separation and browsing-by-proxy. The workstations are in a sealed-off inner network (intranet) with no direct outside access. For internet browsing, the workstation connects to a middle-man server in the DMZ (outside the intranet) to do the browsing on its behalf over a Remote Desktop Connection. The DMZ server running the browser, Java etc. is still at risk to the dangers mentioned above, but in the event it is compromised the workstation remains safe: The attacker's reach would be boxed off to the DMZ server which contains no sensitive data, and is firewalled off the intranet. The attack would be foiled.

However sometimes the solution creates the problem.
The vulnerability found breaks the basic value proposition of the security product in which it is found. With it the attacker, after compromising the DMZ server, can further inject malicious code into any workstation that is using it to surf the web. This would generally mean instant "pwnage" of all the enterprise's workstations.

Worse still, the malicious code can later "call home". Typically, malicious code that has reached the internal network somehow has a hard time connecting outside because the internal network isn't directly connected to the internet. However in this case JCSB itself is the connecting agent. Using the intermediate (previously compromised) Jetro server in the DMZ, the code can seamlessly have a 2-way connection with the attacker's server. This means the attacker can steal sensitive information, and establish an APT (Advanced Persistent Threat). Threat-wise, the enterprise is arguably better off using no protection at all as workstations browsing the internet directly could only be compromised one at a time.

This finding is unique as it combined several factors: A critical vulnerability allowing mass remote code execution, found in a security product, used by a large number of leading organizations, which has been in the product for a long time (possibly years), and the product is claimed to have been audited by several leading security companies. See last section for details.

The vendor has been notified and has responded swiftly. The company notified all their clients and is currently upgrading them to a new version patching the vulnerability. Clients that have not upgraded yet are advised to do so immediately as there is no known workaround.

Proof-of-Concept Video

The video demos a successful attack:

• The virtual machine is an enterprise workstation on the separated intranet. The user receives an email with a link to a remote malicious site.
• The user clicks the link, and the website is opened via JCSB (A tunnel to a remote terminal server is opened, and the browser runs remotely).
• A vulnerability is exploited in the browser to gain control of the terminal server (unrelated to JCSB).
• Reported vulnerability is used to run malicious code on the user's workstation (window titled Malicious Code).

Then, a more severe variant is shown:

• A second, unrelated user on another workstation is browsing Google via JCSB.
• The same attack takes place: The first user clicks malicious link. Attacker gains control of terminal server.
• Reported vulnerability is used: Both workstations are infected simultaneously.

Killing the JCSB client (the "J" icon) closes all remote windows. This shows that the malicious code is in fact running on the users' workstations in the local network.

Product Overview

Jetro Cockpit Secure Browsing is a popular enterprise-grade secure browsing solution developed by Jetro Platforms, a well known Israeli security company. The product is used by many leading companies in the Finance, Insurance and Government sectors, and has substantial international traction.
 

Similar to Citrix NetScaler, JCSB secures browsing by having workstations on a separated enterprise intranet connect to the internet via proxy using a terminal server located in the enterprise DMZ, instead of directly. The connection to the Jetro terminal server is done over RDC, and is firewalled off the inner network.

A somewhat simplified browsing session using JCSB

The Exploit

Attack scenario: A user on the local intranet causes the terminal server (using JCSB) to be compromised by an attacker. This can be done using an unpatched or zero-day vulnerability in any software on the server. For example, by browsing a malicious site (browser vulnerability), opening a malicious PDF (reader vulnerability), etc.

The research found that in this scenario:

• Obtaining admin level control of the terminal server (using a Privilege Escalation vulnerability for example), the attacker could run arbitrary code on all workstations in the enterprise that are using JCSB to browse the web at the time of the attack or later. This means that a user surfing completely unrelated to the attacked user could still be compromised.
  

• Obtaining only user level control of the terminal server, the attacker could run arbitrary code on the local workstation of the user that caused the attack.
  

The Vulnerability

The vulnerabilities were found in the print feature: JCSB allows a user to print to a local printer connected to the client's machine. This means "back-stream" data flow: From the terminal server to the local user's machine. Several vulnerabilities in the printing mechanism allowed abusing this reverse data flow for code execution.

When the user creates a printing job, the terminal server prints it to a postscript file, then converts it to PDF and sends the resulting file back to the workstation. Worth noting is that JCSB takes measures to secure the printing process: Original content never reaches the workstation as is  (the conversions assure any malicious code that might exist in the original material is discarded), generated files are randomly named, and deleted immediately after being transferred, etc.

However, these measures are irrelevant if the terminal server itself is compromised: The attacker can mimic/bypass any actions carried out by the real terminal server code. It is the client code that needs to be protected, but unfortunately it is not.

The printing is done via Remote Desktop Virtual Channels. This technology is intended for developing custom services atop the Remote Desktop Protocol. The terminal server prepares a PDF file with the printed content and transfers it to the client for actual printing. An XML is sent over the virtual channel similar to this:

where xxx.pdf is the PDF to be printed.

Note a flag called "Open In Reader". It tells the client to open the received PDF in a PDF Reader on the local machine instead of actually printing it. In turns out that in order to open the PDF reader, the client simply executes the received file with the intent of running the default handler for PDF files (such as Acrobat Reader).

To exploit these vulnerabilities an attacker can prepare a file called "malicious.exe" containing the malicious code to run. The terminal server then sends a modified XML similar to the one below. Note that the FileName is now xxx.EXE and OpenInReader is on. 

Upon receiving the file, the client will execute it assuming it's a PDF and that the default handler will kick in. Instead, being an EXE file, it will simply get executed. 

Workaround

A workaround was not found.

Printing as a feature can be disabled through the administration console, however doing this doesn't prevent the attack. Even though the regular printing dialogs are not displayed, the low-level processing of XML jobs (as shown above) continues to function. Similarly, uninstalling the printer drivers on the terminal server does not provide a countermeasure either.
Clients are advised to upgrade to the newest version by contacting Jetro Platforms.

Technicalities and Timeline

I conducted the research as an independent consultant for a client that was interested in assessing the risk of the print feature in the product. I've only tested the printing feature and not the entire product. The audit was entirely black-box.

Ultimately, the vulnerability found was straightforward. However the audit itself was quite challenging, requiring a complex setup of 5 virtual machines to mimic an enterprise deployment and plenty of code reverse-engineering.

The research was done using the 30-day evaluation version available from the company's website. All versions available for download were tested and found vulnerable. They are:

• Jetro Cockpit Secure Browsing 4.3.3 (latest version at time of research)
  
• Jetro Cockpit Secure Browsing 4.3.1 (released 2013-05-19)
  

Timeline

2014-01-02 Vendor contacted and informed about vulnerability.

2014-01-12 Vendor reported having informed all clients about vulnerability in an official email, and began upgrading customers with a new version.

2014-02-02 Coordinated disclosure after contacting vendor.


Final Thoughts

Interestingly, Jetro states having had its product reviewed and approved by several leading security consultancy companies. An endorsement by one such company can be found on many of Jetro's promotional materials. The actual report posted on their site states it was only a "design review with no actual security tests", however it still doesn't mention the possibility of this attack vector. This arguably gives customers a false sense of security as it seems the product is "tested and found secure". Details about the other audits were not found.

Thoroughly testing such products, especially black-box testing, is very time consuming and therefor expensive. An expense perhaps neither the company nor its clients wishes to bear. This raises interesting questions about the value of "overview" security reviews and their use as a promotional method for security products sales, and the surprising security risks introduced by security software.

All downloadable versions were tested and found vulnerable. The oldest version available for download (4.3.1) was released 2013-05-19, meaning customers were vulnerable for at least 8 months prior to this disclosure. However in its release notes it states "Print-jobs transfer, in previous COCKPIT versions, was accomplished in virtual channel." This makes it likely to assume that the vulnerability existed in previous versions of the product as well, perhaps going undetected for several years.

The idea of seamless remote browsing introduces plenty of tricky security problems that may prove difficult to solve. While this research focused only on the printing feature, further research might uncover other vulnerabilities in this, and other similar products.

Finally, I would like to commend Jetro's responsiveness, which was timely and honest.

Update (2014-24-02)
Vendor's Response

 Jetro Platforms requested I post their response on my blog:

As detailed in this post, contrary to the vendor's response users of the affected versions were, and still are exposed and are at real risk. The probability that an exploitation can occur in a real work environment is high. The vulnerability does not require an administrator user.

Before publishing the response, I contacted the vendor explaining the response is not accurate and does not portray the actual gravity of the issue. In response the vendor requested I publish the response as-is.

Judging from the response, it seems possible that users were not fully informed about the extent of the risks this vulnerability creates for them. This might cause users to delay upgrading, wrongly assuming they are not at any real risk. As stated, users in a normal production environment are at real risk, and should upgrade to the new version as soon as possible.

Users that wish to do so, may feel free to contact me about any questions regarding this vulnerability and its consequences.

As of this writing, the vendor has not issued a public announcement about the vulnerability on their website, and the latest version available for download is still vulnerable.