Core Security Technologies Advisory 2011.0103

Type packetstorm
Reporter Core Security Technologies
Modified 2011-02-10T00:00:00


                                            `Core Security Technologies - Corelabs Advisory  
ZOHO ManageEngine ADSelfService multiple vulnerabilities  
1. *Advisory Information*  
Title: ZOHO ManageEngine ADSelfService multiple vulnerabilities  
Advisory ID: CORE-2011-0103  
Advisory URL:  
Date published: 2011-02-10  
Date of last update: 2011-02-10  
Vendors contacted: ZOHO Corporation  
Release mode: Coordinated release  
2. *Vulnerability Information*  
Class: Protection Mechanism Failure [CWE-693], Authentication Issues  
[CWE-287], Cross-Site Scripting (XSS) [CWE-79]  
Impact: Code execution, Security bypass  
Remotely Exploitable: Yes  
Locally Exploitable: No  
CVE Name: CVE-2010-3272, CVE-2010-3273, CVE-2010-3274  
3. *Vulnerability Description*  
ManageEngine ADSelfService Plus [1] is a secure, web-based, end-user  
password reset management program. This software helps domain users to  
perform self service password reset, self service account unlock and  
employee self update of personal details (e.g. telephone numbers, etc)  
in Microsoft Windows Active Directory. Administrators find it easy to  
automate password resets, account unlocks while managing optimizing the  
expenses associated with helpdesk calls.  
The security question mechanism used for password recovery can be  
weakened by tampering the HTTP POST request containing the answers,  
allowing an attacker to pass the security check by guessing just one of  
the security answers. Additionally, the CAPTCHA mechanism can be  
bypassed in the same manner, enabling the automation of the guessing  
The security question mechanism can also be bypassed by changing the  
flow of the application, skipping the security question mechanism and  
sending a HTTP request requiring the password change immediately after  
declaring which user is to run the recovery procedure.  
Additionally, two cross site scripting vulnerabilities were found  
related to search functions.  
4. *Vulnerable packages*  
. ManageEngine ADSelfService Plus 4.4.  
. Older versions are probably affected too, but they were not checked.  
5. *Non-vulnerable packages*  
. ManageEngine ADSelfService Plus 4.5 Build 4500 and above.  
6. *Vendor Information, Solutions and Workarounds*  
Core would like to thanks Manikandan.T [2] for giving us the following  
detailed information about the way Zoho team has addressed the security  
vulnerabilities highlighted in this document.  
6.1. *Solution to the Weak security question mechanism*  
[CVE-2010-3272] In addition to the Security Questions, the latest  
version of ADSelfService Plus also includes an SMS Verification / Email  
Verification mechanism. This adds an additional security while password.  
Users must confirm the code sent to their mobile phones / email when  
they are to reset password / unlock accounts.  
The earlier Builds used URL based on Post Request which was considered  
vulnerable. This has been replaced by a more secure Tokenizer mechanism.  
This mechanism prevents "by-passing any process / steps involved in  
password reset / account unlock". The Tokenizer mechanism mandates the  
flow of addressing every process only in the defined sequence. This  
implies that the "Hide_Captcha / quesList" fields cannot be altered; if  
not, they do not follow the desired sequence.  
6.2. *Solution to the Security question bypass*  
[CVE-2010-3273] Earlier version of ADSelfService Plus checked the  
validation only at the page where the user was present. Now Each and  
Every step and also the previous steps are being validated. The  
"Tokenizer Method" ensures that no steps are bypassed. It also ensures  
that validation occurs at every level and also only in the sequence  
6.3. *Solution to Cross site scripting vulnerabilities*  
[CVE-2010-3274] Security Filters are used to prevent Cross Site  
Scripting vulnerabilities. ADSelfService Plus now checks every input  
provided by a user at all the pages including "Password Reset / Unlock  
Account", Employee Search pages.  
7. *Credits*  
This vulnerability was discovered and researched by Ernesto Alvarez from  
Core Security Technologies. The publication of this advisory was  
coordinated by Fernando Miranda from Core Security Advisories team.  
8. *Technical Description / Proof of Concept Code*  
8.1. *Weak security question mechanism*  
[CVE-2010-3272] The procedure to recover a lost password involves the  
user answering a series of security questions set during enrollment.  
After the recovery request and user ID have been sent, the system  
requires the user to answer a certain number of security questions,  
whose answers are then sent using a POST request, as seen below.  
POST /accounts/ValidateAnswers?methodToCall=validateAll HTTP/1.1  
Host: SERVER  
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:  
Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip,deflate  
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
Keep-Alive: 115  
Proxy-Connection: keep-alive  
Referer: http://SERVER/accounts/ValidateUser  
Cookie: JSESSIONID=8F93EB242EF06C51BE93EB0CEDA69085  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 294  
As seen in the HTTP POST above, the client has the ability to decide:  
1. Whether he wants to complete a captcha or not, by altering the  
"Hide_Captcha" field.  
2. How many security questions he has to answer, if he modifies the  
"quesList" parameter.  
Therefore, an attacker can choose to answer just one security question  
of his choice, and this procedure can be automated, since the captcha  
can be bypassed. The reason for this weakness is that most of the  
recovery logic is left to the client to execute. This allows the client  
to alter the recovery procedure, weakening the process.  
8.2. *Security question bypass*  
[CVE-2010-3273] The security question mechanism can also be completely  
bypassed, allowing an attacker to reset an arbitrary user password. In  
order to bypass the mechanism, an attacker must first select the user  
whose password is to be changed, an operation which does not require  
authentication, and then skip the security question mechanism, issuing a  
HTTP request to the URL that accept password changes.  
The normal recovery procedure in the ADSelfService Plus system consists  
of four steps:  
1. *Invoke the reset function.* By going to  
'//SERVER/accounts/Reset', the user is prompted to enter his user id.  
2. *Input the user id that needs a password reset.* By filling the  
form from step 1, the user id in sent to  
'http://SERVER/accounts/ValidateUser' using a HTTP POST. During this  
step, the user id is associated with the HTTP session (as shown in the  
JSESSIONID cookie). The user is prompted with the security questions.  
3. *Validate the security questions.* The answers are sent for  
validation to:  
If the answers are correct, a HTTP page with a form to input the new  
password is sent to the user. If the answers are wrong, the user is  
prompted again for the correct answers, and the step 3 must be redone.  
4. *Reset the password.* The new password is sent in a HTTP POST to  
'http://SERVER/accounts/ResetResult'. The server resets the password.  
While some of the logic (mostly requiring changes to server data) is on  
the server side, the order of the steps to be performed can be  
controlled by the user. By performing steps 2 and 4 while skipping step  
3, the user is able to change the password for another user of his  
choice. This flaw is due to the way the server acts on the information  
received. Step 2 associates a JSESSIONID to a user id (apparently  
necessary to perform step 3) while step 4 changes the password of  
whatever account is associated with the JSP session, setting it to the  
value posted. Since the server does not check whether step 3 has been  
completed, forging the appropriate HTTP POST requests necessary to  
perform the two steps mentioned is sufficient to change a user's password.  
8.3. *Cross site scripting vulnerabilities*  
[CVE-2010-3274] Two cross site scripting vulnerabilities were  
discovered, both related to the employee search function publicly  
available in the application. The first one involves the function used  
for listing matching usernames according to search criteria previously  
entered by the user, found in  
'http://SERVER/'. The server reflects  
the contents of the 'searchString' field back to the user. An example of  
such an injection would be:  
This example would cause the following HTML to be presented to the user:  
<option value="equals" > Equals</option>  
<input type="text" name="searchString" id="searchTextField"  
class="textfield" value="alice" onmouseover="alert('xss')"  
onkeypress="javascript:return searchOnKeyPressEvent(event)">  
<input type="button" name="search" id="search" class="button"  
value=" Go " onclick="javascript:searchAD()">  
The second cross site scripting vulnerability is present in the search  
page at 'http://SERVER/'. This page  
accepts the search parameters and then creates a new form to be sent to  
'http://SERVER/'. During the creation  
of the form, the unfiltered input is reflected to the user within a  
javascript block as shown below.  
var searchValue = 'alice'; alert('xss'); var a='a';  
var paramName = 'name';  
var searchType = 'contains';  
The example above was caused by following a link to:  
This reflection is not obvious at first sight, as the source code shown  
after the process is finished is the showList page source. This code can  
be easily viewed if captured on the wire using a proxy server, though.  
Additionally, since invoking  
'http://SERVER/' causes a redirection  
to 'http://SERVER/', entering any  
data capable of triggering a vulnerability in the latter page can be  
introduced in the former with the same results.  
It is important to note that since the cross site scripting  
vulnerabilities were detected while investigating the authentication  
bypass issues and were considered a secondary matter, the pages  
containing them were not thoroughly tested. This leaves the possibility  
of other similar cross site scripting vulnerabilities remaining undetected.  
9. *Report Timeline*  
. 2011-01-11:  
Initial notification to the vendor. Publication date set to February  
2nd, 2011.  
. 2011-01-13:  
The Zoho team asks Core for a technical description of the vulnerability.  
. 2011-01-13:  
Technical details sent to Zoho team by Core.  
. 2011-01-17:  
The Zoho team acknowledges reception of advisory draft and asks a  
contact phone number to discuss these flaws.  
. 2011-01-17:  
The Core team notifies its preference for keeping the whole  
communication process through email, in order to track all interactions,  
and involve all those interested in:  
1. the Core Security Advisories Team,  
2. the Zoho team and,  
3. the discoverer of the vulnerability.  
If there is something that cannot be resolved via email, Core team can  
eventually send a phone number to set up a conference call, but that is  
not necessary at the moment.  
. 2011-01-20:  
The Zoho team notifies that the vulnerabilities highlighted in the  
document will be addressed in the upcoming release of ADSelfService  
Plus, scheduled to be released before Feb. 11th.  
. 2011-01-21:  
Core notifies that the advisory was re-scheduled to Feb. 10th, and asks  
if any security bulleting is going to be released by Zoho team regarding  
these vulnerabilities.  
. 2011-01-28:  
The Zoho team notifies that they are on schedule for the release of the  
new version of ADSelfService Plus. Zoho have plans to publish a report  
regarding these vulnerabilities, including solutions and workarounds.  
. 2011-02-07:  
Core asks if Zoho team will be ready for disclosure next Thursday Feb  
10th in order to coordinate the advisory publication.  
. 2011-02-08:  
The Zoho team notifies that they are ready with the Engineering Release  
version ADSelfService Plus 4.5 Build 4500. This version of ADSelfService  
Plus has taken into consideration and also addressed all security  
vulnerabilities highlighted by this advisory. Zoho is going to make a  
public announcement by Tomorrow.  
. 2011-02-10:  
The advisory CORE-2011-0103 is published.  
10. *References*  
[1] ADSelfService Plus  
[2] Manikandan.T, Senior Program Manager, ManageEngine ADSelfService Plus.  
11. *About CoreLabs*  
CoreLabs, the research center of Core Security Technologies, is charged  
with anticipating the future needs and requirements for information  
security technologies. We conduct our research in several important  
areas of computer security including system vulnerabilities, cyber  
attack planning and simulation, source code auditing, and cryptography.  
Our results include problem formalization, identification of  
vulnerabilities, novel solutions and prototypes for new technologies.  
CoreLabs regularly publishes security advisories, technical papers,  
project information and shared software tools for public use at:  
12. *About Core Security Technologies*  
Core Security Technologies enables organizations to get ahead of threats  
with security test and measurement solutions that continuously identify  
and prove real-world exposures to their most critical assets. Our  
customers can gain real visibility into their security standing, real  
validation of their security controls, and real metrics to more  
effectively secure their organizations.  
Core Security's software solutions build on over a decade of trusted  
research and leading-edge threat expertise from the company's Security  
Consulting Services, CoreLabs and Engineering groups. Core Security  
Technologies can be reached at +1 (617) 399-6980 or on the Web at:  
13. *Disclaimer*  
The contents of this advisory are copyright (c) 2011 Core Security  
Technologies and (c) 2011 CoreLabs, and may be distributed freely  
provided that no fee is charged for this distribution and proper credit  
is given.  
14. *PGP/GPG Keys*  
This advisory has been signed with the GPG key of Core Security  
Technologies advisories team, which is available for download at