This time, I will focus on any user password reset problems caused by unverified reset credentials.
Password retrieval needs to identify the user’s legal identity and prove that you are you. There are usually two methods. One is that the website sends the reset verification code to the user’s mailbox or mobile phone number, and the user uses the reset verification code to prove it. The second is that the user enters the answer corresponding to the password protection question. Among them, the verification code and the secret answer are important credentials for resetting the password.
In the daily attacks on the password retrieval function, most of my energy is focused on whether the verification code can be broken, whether the mobile phone number or email receiving the verification code can be hijacked, whether it can be confused to reset other accounts, and whether it can be bypassed In terms of verification steps, even guessing the generation rules of reset tokens, the easiest method is ignored—the server does not verify the reset credentials. This means that no matter whether the reset verification code or password answer you entered is correct, as long as the request format is correct, you can successfully reset any account password. Let me cite two real cases.
Case 1: Any account password can be reset because the server has not verified the token
Password recovery page http://www.omegatravel.net/users/retrievePassword/, use the attacker account email@example.com to enter the password recovery process, enter the picture verification code and submit:
Then I received an email with a password reset link with token:
Among them, key:FqvICT and userEmail:firstname.lastname@example.org caught my attention. Normally, after submitting the URL, the server will verify whether the key matches the userEmail. If it matches, it will enter the new password submission page. If it does not match, it will report an error. Now, I try to change the key from FqvICT to xxxxxx and then visit. I expected to see an error page, but I didn’t expect to enter the new password submission page, so the so-called reset token is useless?
I found an account to try. Take the email@example.com I found during information collection as an example (for more background accounts, see the description below). Refer to the reset link format received earlier and simply assemble it as http://www.omegatravel.net/users/retrievePasswordReset/key:xxxxxx/userEmail:firstname.lastname@example.org, yes, I just write the value of the key casually , Visit the link, and actually entered the new password submission page:
After entering the new password PenTest1024 and submitting it, the website prompts “Password changed successfully”. Try to log in with email@example.com/PenTest1024 and successfully enter the system:
How to get other accounts? As you can see from the registration page, the website can only be registered by email, which is the account. I care about two types of accounts (ie mailboxes) for ordinary users and internal employee users. Make a mailbox dictionary for ordinary users, and combine common names with common mailbox suffixes (@qq.com, @163.com, etc.) to quickly generate a simple mailbox dictionary; about making an internal employee mailbox dictionary, I check the domain name registration information of this website The contact person is firstname.lastname@example.org, indicating that the company uses the email suffix @omegauk.net. I combined common names and common back-end accounts with @omegauk.net mailbox suffixes to quickly generate a mailbox dictionary; in addition, I found a large number of internal employee mailboxes and partner mailboxes from pages such as “Contact Us”, “Recruitment”, and “Company Profile” , Such as email@example.com, firstname.lastname@example.org, etc.:
Save the above types of mailbox dictionaries as mail.txt, which is the user name.
In this way, I can not only reset the password of the ordinary account, but also hijack the accounts of a large number of internal employees and partners. In order to avoid affecting the business, I no longer operate it.
Case 2: Enumerate unsecured user names, resulting in any secret answer to reset the password
The following content is visible to members
[wc_pay_can_read id=’2026,2029,2030′ tishi=’You do not have permission to read this content, click here to become a member and refresh this page to read it’]
On the password retrieval page http://www.hzpzs.net/u_findPassword.asp enter a valid user name yangyangwithgnu and intercept the request package:
I guess that the data packet is used to verify the validity of the user name and put it in the repeater for analysis.
Since the image verification code is not used, valid user names can be enumerated. I found three types of situations. One is that the user name exists and the password protection problem is set, and the response is similar:
The second is that the user name exists but the secret security question is not set, and the response is similar:
Third, if the username is invalid, the response is similar:
Use common user names and names as dictionaries to enumerate, filter out the responses that contain the keyword <td width=”65%”></td> in all the results, and get all the UserName parameter values that are not set security questions User name. Such as: aaron, admin, adolph, alisa, chenchen, esther, jones, etc.
Follow the normal process to reset chenxin’s password. Enter any secret answer to reset the password:
The password reset credential must be strictly verified. It is forbidden to retrieve the password through the secret security when there is a problem with the blank security; the server should restrict malicious requests such as enumeration.