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=PreDef ined-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=cont ains -----/ 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="Go" 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&parameterName=name&a mp;searchType=contains&searchString=alice%22+onMouseOver%3D%22javasc ript%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.a sc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1UeqwACgkQyNibggitWa3dUwCghJG62z/CGN8GlczM+RlaIwne EXIAmgNEMQAwGBruywm662xmk9TqaCgZ =AakL -----END PGP SIGNATURE-----