In a web security incident, the account is usually the first point of contact presented to the attacker. If there are defects in the account-related functions, the attacker can obtain key information and important functions. For example, the error message of login failure can be used to determine whether the account does not exist, and it can also be used to enumerate valid accounts. For example, there is no limit on the number of login trials and errors, which can lead to password breaking. Another example is that the steps of the registration process are not strictly related, leading to batch registration of arbitrary accounts. Another example is that the steps of the password retrieval function are not strictly related, resulting in resetting the password of any account.
During my daily penetration, I encountered a website https://www.xxxx.com/ that has these types of problems at the same time. This website is an e-commerce platform. It reasonably combines several types of problems. At that time, I have obtained administrator rights and loopholes. The repair has been submitted and confirmed, and the ideas are shared with everyone.
Before we start, let’s talk about a habit. Many websites are divided into PC version and mobile version. The mobile version has weaker security defenses. Therefore, I will try to find the mobile version of the website first. Specifically, I’m used to use my mobile phone to directly access first, the server will automatically jump to the mobile version and extract the access address of the mobile version; if you find it troublesome to enter the URL on the mobile phone, you can install firefox’s useragent-switcher (https:// mybrowseraddon.com/useragent-switcher.html) extension to simulate mobile terminal access; of course, other means can also be considered, you can find similar through the subdomain enumeration tool Sublist3r (https://github.com/aboul3la/Sublist3r) https://m.xxxx.com/ mobile phone version, you can also find a mobile phone similar to https://www.xxxx.com/wap through the path enumeration tool dirsearch (https://github.com/maurosoria/dirsearch) Version, you can also find similar https://www.xxxx.com/mobile through google hacking (inurl:xxxx.com mobile terminal).
Account can be enumerated
Enter the account and password on the login page https://www.xxxx.com/Wap/User/login:
After submission, the request is intercepted. If the account does not exist, the server response is:
If the account exists, the server response is:
The analysis found that although the responses are very similar, there are still differences. The valid account has more “you” than the invalid account, or the length of the response body can also determine whether the account is valid. At the same time, the server does not restrict high-frequency access, so valid accounts can be enumerated.
Set the value of the mobile parameter as an enumerated variable, and use the common name top500 and common back-end account as a dictionary. In the enumeration result, the response packet length of 561 is all valid accounts:
Among them, there are common accounts such as chenying and chenyun, as well as back-end accounts such as admin and ceshi, and the result is saved as username.txt:
Password can be blasted
The server has a mechanism for the upper limit of password trial and error, and login is prohibited within one hour if there are 5 errors:
View login request:
The logintime parameter name and parameter value caught my attention. It just happened to be the upper limit of trial and error 5. After trying to change the value to 4, the server responded normally, or after deleting logintime, the trial and error restriction can also be bypassed.
Now, using the request package after deleting logintime, define mobile as an enumerated variable 1, use the previously generated username.txt as a dictionary, and define password as an enumerated variable 2, use the common weak password top1000 as a dictionary to perform password brute-force cracking :
Among them, the response packet length of 380 is a valid password, and it is saved as logined.txt:
Any account registration
On the registration page https://www.xxxx.com/Wap/User/register, enter the unregistered mobile phone number and click “Get Verification Code”, enter the received SMS verification code and submit, enter the password setting page:
Intercept the request after entering the password:
A simple analysis found that register_mobile is the registered user name. As long as the parameter value has not been registered, this request package can bypass the SMS verification and successfully create any account.
For example, the system originally only allowed the mobile phone number to be used as the user name for registration. Using this vulnerability, you can create the account yangyangwithgnu/abcd1234 and log in to confirm:
Retrieve any account password
On the password retrieval page https://www.xxxx.com/Wap/User/forgetpass, use the attacker account number 13908080808 to enter the password retrieval process, enter the SMS verification code and submit:
Enter the new password page, enter and submit, the interception request is as follows:
Among them, the two parameters PHPSESSID=p6nujg7itekpau6p1e9ibbpe86 and register_mobile=13908080808 caught my attention. This request is used to reset the password of the account 13908080808, so how does the server know to reset 13908080808 instead of 13908080807, 13908080809? One of the several parameters just mentioned must be used for this purpose. I tried one by one and found that PHPSESSID is it. In addition, boss_language and register_mobile can be deleted without affecting the result.
This brings me to the cookie confusion. The general idea of the attack: First, use the attacker account 13908080808 to enter the password retrieval process, check the reset verification code, and pass the verification; then, enter the new password and submit, intercept and interrupt the request, and not send it to the server temporarily. At this time, PHPSESSID is associated with the account 13908080808; then, close the burp proxy of the browser, open the home page of the reset process, and enter the ordinary account number 13908090133 in the page to obtain the SMS verification code. At this time, PHPSESSID has been associated with 13908090133; finally, let go The previously interrupted request is put on the server side, and logically, the password of 13908090133 can be successfully reset.
Try to reset the password of 13908090133 to PenTest1024 using the above ideas, and the front end shows that the reset was successful. Try to log in with 13908090133/PenTest1024 and successfully enter the system:
In the same way, the administrator account can be reset. To avoid affecting the business, no actual operation is required.
Generally speaking, the password retrieval logic contains four elements: user identification (user name, user ID, cookie), receiver (mobile phone, email), certificate (verification code, token), and current step. These four elements must Complete association, otherwise it may lead to any account password retrieval vulnerability. In addition, the server should limit malicious requests such as enumeration.