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.
Previous article:Any user password reset (1): reset credentials leak
Case 1: The receiving end can be tampered. The request packet contains receiver parameters, and the certificate can be sent to the designated receiver.
On the password reset page, enter any ordinary account number and select the mobile phone method to retrieve the password. Click to get the SMS verification code on the identity verification page:
Intercept the request and find that the mobile phone number receiving the verification code is a parameter in the request packet:
Directly tamper with the attacker’s mobile phone number, successfully receive the SMS verification code, and after submitting the verification code, perform steps 3 and 4 normally to successfully reset the account password.
Case 2: The receiving end can be tampered.
The indirect related parameters of the receiving end appear in the request packet, and the certificate can be sent to the designated receiving end.
On the password retrieval page, use the attack account test0141 to try to reset the password of the target account 2803870097 (yes, the two accounts that look completely different are indeed from the same website).
Enter test0141 and the picture verification code on the first homepage to complete the first step “01 safety certification”:
The request is:
Enter the picture verification code to obtain the SMS verification code to complete the second step “02 Identity Verification”:
The request is:
The subsequent steps 03 and 04 do not involve user name information and are ignored.
After the whole process, the mobile phone number for receiving the SMS verification code was not directly submitted on the client. After many attempts, we can see that the user_name in step 02 is used to query the mobile phone number for sending the SMS, and it can be used to indirectly specify the receiving end, then, Is it only for this purpose and not used to specify the account to reset the password? Use the following method to verify, first set userName to 2803870097 to complete step 01 to tell the server the account that needs to be reset, and then set user_name to test0141 to complete step 02 to trick the server to send the SMS verification code to the attacker’s mobile phone, complete step 03, 04 may be able to reset the password of 2803870097. details as follows.
The first step is to use the ordinary account 2803870097 for security authentication:
The second step is to authenticate the ordinary account 2803870097:
Intercept the request to send SMS verification code:
Change user_name from 2803870097 to test0141, and control the server to send the verification code to the mobile phone number bound to test0141:
The phone number of test0141 successfully received the verification code 872502, fill in the verification code into the ID verification page of reset 2803870097 and submit:
The third step, enter the new password PenTest1024 and submit it, the system prompts that the reset is successful:
The fourth step, log in with 2803870097/PenTest1024, the verification is successful:
In terms of defense measures, it is necessary to compare the consistency of the mobile phone number/email address of the reset user with the mobile phone number/email receiving the reset voucher. Usually, the mobile phone number/email address is generated directly from the server instead of the client.