First of all, I stumbled upon this vulnerability unintentionally, and its inherent risk is not particularly high. However, our college recently distributed an Excel file titled “Student-Mentor Allocation Table” in various class group chats, which included everyone’s birthdates. This significantly increased the exploitability of the vulnerability, prompting me to write this article analyzing the process of discovering this logical vulnerability. Since this is a logical vulnerability, let’s first introduce the concept.
What is a Logical Vulnerability?
A logical vulnerability arises when program logic is either too lax or overly complex, leading to certain logical branches being improperly handled or mishandled. These typically occur in the following areas:
- Arbitrary password modification (no verification of the old password)
- Privilege escalation
- Password recovery
- Transaction payment amounts
- …
When logging in, can CAPTCHA be bypassed to facilitate brute force attacks? Key points to consider in login mechanisms:
- The CAPTCHA is included in the response packet.
- The CAPTCHA is embedded in a hidden field on the returned page.
- Some login URLs do not require CAPTCHA verification.
- The CAPTCHA remains static and only changes when the URL is refreshed.
- The first request validates the CAPTCHA, but subsequent requests do not require it.
- Intercepting the CAPTCHA refresh request during login allows reuse of the first CAPTCHA before it expires.
- Are the CAPTCHA, username, and password submitted simultaneously?
- No verification for public accounts or apps. Source — Baidu
This is the web authentication page for our school’s China Unicom network. China Unicom assigns each of us a public IP address, which I find incredibly convenient for someone like me who enjoys tinkering with things. I even set up a server in my dorm room. But that’s not the focus here—let’s dive straight into the process of discovering this logical vulnerability.
I discovered this vulnerability when my China Unicom account suddenly stopped working a few days ago. I wasn’t sure if someone had changed my password or if there was a bug, but the authentication page kept telling me my password was incorrect. I tried all the passwords I had ever used, but none worked. A friend suggested I visit a China Unicom service center to reset my password, but it was a Saturday evening, and the service center was closed. Going the next day would take up a lot of time, so I decided to reset the password myself. Time to get to work.
Initially, I thought about brute-forcing the login form. Since the account ID is our student number and the default password is typically the last six digits of our ID card number, even if someone changed their password, most would still use a six-digit numeric password. However, I found that the login mechanism had strict limitations. If you entered the wrong password several times, the account would be locked for five minutes before you could try again. If you kept entering the wrong password, the lockout time would increase. So brute-forcing the login was nearly impossible. I decided to try a different approach and borrowed an account that was still functional.
After logging in successfully, I noticed there was a password modification feature on the web page. However, the user account was locked. Upon inspecting the webpage’s source code, I discovered…
At that moment, I had a hunch. I instinctively opened Burp Suite to start intercepting packets. Sure enough…
By intercepting packets, I found that the account field was user-controllable and lacked a token. This meant the account field could be replaced with someone else’s account.
The logical vulnerability lies here: to change the account password, you need to input the current password once and the new password twice. If the current password is incorrect, the modification fails. But what happens if you repeatedly enter the wrong current password? After repeated testing, I discovered that whenever the current password was incorrect, the response packet included a “fail” field, and if successful, it returned “success.”
It seems that the developers at China Unicom only considered limiting the number of incorrect password attempts during login but overlooked implementing a similar restriction on the password modification page. Since there was no restriction, the current password could be brute-forced.
I replaced the account field with my own account and used a six-digit dictionary in Burp Suite’s Intruder tool to brute-force the current password. Here, I’ll demonstrate using someone else’s account.
After configuring the payload, I increased the number of threads. Attacking…
Not only did I successfully brute-force the original password, but I also reset the password to “1.” The response status code should have been 302, with a length of 199. However, while reproducing the issue for this article, it seems the China Unicom authentication server encountered a bug. Although it returned a 500 error, the password reset was still successful.
Now, let’s use the reset password to log in to the China Unicom account.
Login successful!
I’ll discuss how this vulnerability can be cleverly exploited in the second part of this article.