Among logic vulnerabilities, arbitrary user password reset is the most common, which may appear on the new user registration page, or the page for resetting the password after the user logs in, or the password recovery page when the user forgets the password. I analyzed the causes of vulnerabilities in the cases encountered in the daily penetration process. This time, I will focus on the problem of arbitrary user password reset caused by user confusion.
The password retrieval logic contains four elements: user identification (user name, user ID, cookie), receiver (mobile phone, email), credentials (verification code, token), current step, etc. If these elements are not completely related, then May cause arbitrary password reset vulnerabilities.
Case 1: Using cookies to confuse different accounts to reset any user password.
Password recovery page https://my.xxxx.com/pwd, use the attacker account yangyangwithgnu to complete the password recovery process.
Submit after entering the username and picture verification code:
After verifying as a valid user name, the system provides two ways to retrieve passwords: mobile phone and email. Choose email:
Log in to the email to view the reset verification code:
Enter the reset verification code:
Enter the new password page, enter the new password and submit, the intercepted request is as follows:
Among them, PHPSESSID=dcusc1ahkn4ioqeeav9c6e0bdq, USER_ACCOUNT=yangyangwithgnu, USER_APPID=1092 these three parameters attracted my attention. This request is used to reset the password of the account yangyangwithgnu, so how does the server know that the reset is yangyangwithgnu instead of yangyangwithgnu2, yangyangwithgnu3? One of the three parameters just mentioned must be used for this purpose. Try one by one and find that PHPSESSID is it.
This brings me to cookie confusion. The general idea of the attack: First, use the attacker account yangyangwithgnu to enter the password retrieval process, receive the reset verification code and pass the verification; then, enter the new password and submit it, intercept and interrupt the request, and not send it to the server temporarily. At this time, PHPSESSID is associated with the yangyangwithgnu account; then, close the burp proxy of the browser, reopen the home page of the reset process, and enter the ordinary account liuwei in the page and submit it. At this time, PHPSESSID has been associated with liuwei; finally, restore Send the previously interrupted request and put it on the server. In theory, the liuwei password can be successfully reset.
Try to reset the liuwei password to PenTest1024 with the above ideas, the front end shows that the reset was successful:
Try to log in with liuwei/PenTest1024:
Successfully enter the system:
In the same way, the administrator account can be reset. In order to avoid affecting the business, no actual operation is performed.
Case 2: The password of any user can be reset by tampering with the user name parameter in the request package.
The password retrieval page is http://www.xxxx.cn/getpass.html. Using the attacker’s account to complete the entire process of password retrieval, it involves a three-step request, in order: verify the existence of the user name, obtain the SMS verification code, submit the SMS verification code and the new password. The third step of request interception is as follows:
The following content is visible to members