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

This article is a summary and translation to Hebrew of the original report as posted earlier this month.

פרסום זה הינו תקציר ותרגום לחשיפה שפורסמה באתר זה מוקדם יותר החודש.

עדכון (9.2.2014) הממצא קיבל מספור רשמי  CVE 2014-1861

עדכון (24.2.2014) פרסום תגובת החברה לבקשתה בסוף המסמך.

תקציר הממצא

פירצה חמורה התגלתה במוצר "גלישה מאובטחת" של חברת ג'טרו פלאטפורמס  (Jetro Cockpit Secure Browsing  להלן JCSB של Jetro Platforms). הפירצה מאפשרת לתוקף שהשיג שליטה בשרת הגלישה החיצוני של המערכת, להמשיך ולהשתלט על כל מחשבי הארגון ברשת הפנימית (המשתמשים במוצר) בבת אחת. בכך התוקף בעצם עוקף ואף מנצל את מוצר ההגנה כסוכן להרצת קוד זדוני במחשבי הארגון. התקפה מוצלחת נותנת לתוקף גישה מלאה מתמשכת ומוסתרת (advanced persistent threat) לרשת הפנימית של הארגון. הדבר עשוי לאפשר, בין היתר, גישה למידע רגיש, ביצוע פעולות בבסיסי נתונים, איסוף סיסמאות ועוד.

המוצר מותקן בארגונים מובילים בארץ בתחומי הבנקאות, אשראי, ממשלה, בריאות, תשתיות ועוד. (לרשימת לקוחות ראה פרסום באתר החברה כאן או כאן).

החשיפה נמצאה בכל הגירסאות הניתנות להורדה של המוצר. הגירסה המוקדמת ביותר הינה מתאריך 05-2013 , כלומר 8 חודשים מתאריך הדיווח, אך יש יסוד סביר להניח שהמוצר היה חשוף גם בגירסאות קודמות (כלומר מספר שנים).

על-פי דיווח החברה, המוצר נבדק ע"י מספר חברות אבטחת מידע בעבר.

הסבר כללי

האקרים מחפשים (ומוצאים) כל הזמן פרצות בתוכנות פופולריות. הפרצות החמורות ביותר הינן כאלה המאפשרות השתלטות מרחוק (Remote Code Execution). מחשב מודרני מריץ מספר רב של תוכנות כאלה בהם: מערכת הפעלה, דפדפן, קורא PDF, ועוד רבים. (הקישורים מפנים לרשימת הפרצות מסוג זה במוצרים אלו שדווחו ותוקנו בשנים באחרונות. רק משלושת הדוגמאות הללו עולה ממוצא של פירצה קריטית פעם ב-3 ימים). בין גילוי הפרצה לתיקונה עשויים לעבור שבועות רבים, ובנוסף קיים שוק שלם של פרצות שמתגלות ולא מדווחות אלא נמכרות לכל המרבה במחיר. לכן עבור ארגון המכיל מידע רגיש מחד ומאות משתמשים הצריכים גישה לאינטרנט מאידך,  מדובר בבעיה של ממש.

אחד הפתרונות לבעיה זו עבור ארגונים הינו גלישה דרך שרת ביניים. כך פועל JCSB. המשתמש בארגון נמצא ברשת פנימית אשר לא מחוברת באופן ישיר לאינטרנט. בכדי לגלוש, מחשב המשתמש מתחבר לשרת ביניים אשר מריץ את הדפדפן, קורא ה-PDF וכו. השרת החיצוני עדיין בסיכון כפי שתואר לעיל, אבל במקרה בו תוקף מנצל פירצה בדפדפן למשל, הוא משיג שליטה רק בשרת החיצוני המנותק, שלא נמצא ברשת הפנימית ולכן לא מכיל מידע רגיש. ההתקפה נכשלת.

אולם לעיתים הפתרון מייצר את הבעיה. הפירצה שנמצאה מאפשרת לתוקף בתרחיש המתואר לעקוף את ההגנה שמספק המוצר ולהשתמש בחיבורים שהמוצר מייצר בין המחשבים ברשת הפנימית לשרת, בכדי להריץ קוד עוין על כל מחשב ברשת הפנימית המשתמש במוצר בכדי לגלוש באופן מאובטח.

גרוע מכך, הקוד הזדוני יכול לשלוח מידע החוצה. לרוב, קוד עוין שהגיע לרשת הפנימית המנותקת מהאינטרנט לא יכול להתחבר לשרתי התוקף. אולם במקרה זה, התוקף שוב מנצל את התשתית של המוצר בכדי לשלוח מידע מהרשת הפנימית לאינטרנט. דבר זה מאפשר בעצם גישה מרוחקת מלאה ומתמשכת של התוקף לרשת הפנימית של הארגון.

סרטון הדגמה

הסרטון מדגים התקפה מוצלחת:

• החלון הינו מחשב וירטואלי ברשת הפנימית. המשתמש מקבל דוא"ל עם קישור לאתר זדוני.
• המשתמש לוחץ על הקישור והאתר נפתח דרך מוצר JSCB. האתר נפתח בדפדפן הרץ בשרת החיצוני.
• האתר מנצל פירצה בדפדפן בכדי להשתלט על השרת (ללא קשר למוצר)
• הממצא המתואר מנוצל: קוד זדוני מגיע מהשרת אל תחנת המשתמש ורץ עליה.

לאחר מכן דוגמא חריפה יותר:

• החלון השני הינו מחשב נוסף ברשת הפנימית. המשתמש בו הגולש ללא קשר למשתמש הראשון
• אותה התקפה מתרחשת: המשתמש הראשון מגיע לאתר הזדוני.
• ניתן לראות כי הקוד הזדוני מגיע לכל המחשבים המשתמשים במוצר, לא רק למשתמש שגרם לתקיפה.

סגירת JCSB (האייקון של האות J) הורג את כל החלונות הרצים בשרת. הדבר מראה שהקוד הזדוני אכן רץ על המחשבים ברשת הפנימית.

פירוט ההתקפה

להלן תרשים פשוט של אופן פעולת המוצר.

תרחיש ההתקפה: תוקף השיג שליטה בשרת החיצוני של המערכת המחובר לאינטרנט. דבר זה עלול להתרחש כאשר התוקף מנצל חולשת Remote Code Execution בתוכנה כלשהי שרצה בשרת (unpatched או zero-day). כאמור זו יכולה להיות חולשה בדפדפן, בקורא PDF, ב-Java ועוד. דוגמא אחת נראית בסרטון בו משתמש גולש לאתר התוקף וזה מנצל חולשה בדפדפן. 

כאמור, זהו התרחיש המסוכן אותו המוצר מנסה למנוע.

נמצא כי:

• אם התוקף משיג הרשאות מלאות בשרת (privilege escalation), הוא יכול להזריק קוד לכל תחנה ברשת הפנימית העושה שימוש במוצר.
• אם לתוקף הרשאות ברמת משתמש בשרת, הוא יכול להזריק קוד לתחנת המשתמש אשר גרם להתקפה.

לפירוט טכני מלא על הפירצה, ראה מאמר באנגלית כאן.

אחרית דבר

על אף שהבדיקה עצמה היתה יחסית מורכבת ודרשה יצירת רשת וירטואלית של מספר מחשבים בכדי לדמות סביבת עבודה אמיתית, והנדוס לאחור של קוד המוצר, החשיפה שנתגלתה לבסוף הינה פשוטה יחסית. זוהו דוגמא טובה לאבטחה באמצעות עמימות (Security Through Obscurity).

על-פי דיווח החברה, המוצר נבדק ונמצא תקין ע"י מספר חברות אבטחה בארץ. פרסומי החברה מצטטים לפחות חברה אחת כזו (למשל כאן). דו"ח הבדיקה עצמו נמצא אף הוא באתר החברה כאן. יש לציין שכתוב בו שלא התבצעה בדיקת עומק אלא רק בחינת איפיון: "design review with no actual security tests", עם זאת האפשרות לכיוון התקיפה המתואר כאן לא עולה בו.

כל הגירסאות שנבדקו ונמצאו חשופות:

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

אך יש יסוד להניח שגירסאות קודמות היו חשופות גם כן (ראה פרסום באנגלית להמשך דיון בנקודה זו).

תאריכים:

2.1.2014 - דיווח הפירצה לחברה

12.1.2014 - החברה מדווחת שהוציאה מייל רשמי ללקוחות ומתחילה בעדכון

2.2.2014 - פרסום הממצא לאחר תאום עם החברה

עדכון (24.2.2014)

תגובת החברה

להלן תגובתה של חברת ג'טרו פלאטפורמס כפי שביקשה שאפרסם אותה:

למען הסר ספק, בניגוד לכתוב משתמשי המוצר היו והינם עדיין חשופים בפועל בשימוש בגירסה הלא מעודכנת של המוצר. הסיכוי שהכשל הדרוש לניצול הפירצה ייווצר או קיים כרגע בסביבת עבודה אמיתית הינו גבוה. אין צורך במשתמש administrator, ו-firewall  לא יחסום את ההתקפה כפי שמוסבר בפירוט במסמך זה.

לפני פרסום התגובה פניתי אל החברה והסברתי שוב את פרטי החשיפה וכיצד התגובה אינה מדוייקת ואינה משקפת נאמנה את חומרת הפירצה, אך החברה שבה ודרשה שאפרסם את התגובה כלשונה.

מהכתוב עולה חשש כי משתמשי המוצר לא יודעו על מלוא חומרת הפירצה. דבר זה עלול לעכב ארגונים בתהליך עדכון הגירסה מתוך מחשבה מוטעת שהם אינם בסיכון. כאמור משתמשים בסביבת ייצור רגילה הינם חשופים ובסיכון. ישנה חשיבות רבה לעדכון המוצר במהירות האפשרית. זאת מכיוון שניצול הפירצה מאפשרת השתלטות רחבת היקף שעלולה להיות קשה מאוד לאיתור ולהסרה באופן מלא לאחר מעשה.

משתמשים המעוניינם בכך, מומזנים לפנות אלי לשאלות או התייעצות בנוגע לממצא זה והשלכותיו.

נכון לזמן כתיבת שורות אלו, החברה לא פירסמה תגובה רשמית באתרה והגירסה להורדה הינה גירסה המכילה את הפירצה.

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.