Message-ID: <4D547AAC.1020604@coresecurity.com>
Date: Thu, 10 Feb 2011 20:54:20 -0300
From: CORE Security Technologies Advisories <advisories@...esecurity.com>
To: full-disclosure <full-disclosure@...ts.grok.org.uk>, 
	bugtraq <bugtraq@...urityfocus.com>
Subject: CORE-2011-0103 - ZOHO ManageEngine ADSelfService
	multiple vulnerabilities

Core Security Technologies - Corelabs Advisory
http://corelabs.coresecurity.com/

ZOHO ManageEngine ADSelfService multiple vulnerabilities


1. *Advisory Information*

Title: ZOHO ManageEngine ADSelfService multiple vulnerabilities
Advisory ID: CORE-2011-0103
Advisory URL:
http://www.coresecurity.com/content/zoho-manageengine-vulnerabilities
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
attempts.

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
desired.


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:1.9.2.13)
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

loginId=1501&Hide_Captcha=0&POLICY_ID=1&Confirm_Answer=1&SESSION_EXPIRY_TIME=5&LOGIN_NAME=alice&REM_SESSION_TIME=00%3A40&bAns=11111&bQues=PreDefined-2&bAns=22222&bQues=PreDefined-3&bAns=33333&bQues=PreDefined-4&bAns=44444&bQues=PreDefined-5&quesList=4&DIGEST=qodpgd&next=Continue&DIS_ALL_QUES=1

-----/
 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:

/-----
http://SERVER/accounts/ValidateAnswers?methodToCall=validateAll
-----/
 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/EmployeeSearch.cc?actionId=showList'. The server reflects
the contents of the 'searchString' field back to the user. An example of
such an injection would be:

/-----
http://SERVER/EmployeeSearch.cc?actionId=showList&searchString=alice%22%20onmouseover=%22alert%28%27xss%27%29&parameterName=name&searchType=contains
-----/
 This example would cause the following HTML to be presented to the user:

/-----
<option value="equals"  > Equals</option>
</select>
<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="&nbsp;Go&nbsp;" onclick="javascript:searchAD()">
</td>
<tr>
-----/
 The second cross site scripting vulnerability is present in the search
page at 'http://SERVER/EmployeeSearch.cc?actionId=Search'. This page
accepts the search parameters and then creates a new form to be sent to
'http://SERVER/EmployeeSearch.cc?actionId=showList'. During the creation
of the form, the unfiltered input is reflected to the user within a
javascript block as shown below.

/-----
<script>
  var searchValue = 'alice'; alert('xss'); var a='a';
  var paramName = 'name';
  var searchType = 'contains';
</script>
-----/
 The example above was caused by following a link to:

/-----
http://SERVER/EmployeeSearch.cc?actionId=Search&amp;parameterName=name&amp;searchType=contains&amp;searchString=alice%22+onMouseOver%3D%22javascript%3Aalert%28%27xss%27%29
-----/
 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/EmployeeSearch.cc?actionId=Search' causes a redirection
to 'http://SERVER/EmployeeSearch.cc?actionId=showList', 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
http://www.manageengine.com/products/self-service-password.
[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:
http://corelabs.coresecurity.com/.


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:
http://www.coresecurity.com.


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
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.



Download attachment "signature.asc" of type "application/pgp-signature" (261 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists