Revealing a Clever Website Vulnerability Discovered a Few Years Ago

---

ℹ️ℹ️ℹ️ The following content is translated by OpenAI.

Click here to view the original Chinese version. | 點此查看本文中文版

---

Revealing a Clever Website Vulnerability Discovered a Few Years Ago

Website security issues caused by the combination of multiple vulnerabilities

Photo by Tarik Haiga

Introduction

A few years ago, while still supporting web development, I was assigned the task of organizing a CTF competition for the internal engineering team; initially, I thought of organizing teams based on the company’s products for mutual attacks and defenses. However, as the organizer, I wanted to first understand the level of knowledge, so I conducted penetration tests on the various products under the company; I wanted to see how many vulnerabilities I could find to ensure the event would run smoothly.

However, due to limited competition time and significant differences between engineering areas, I ultimately decided to create questions based on common foundational knowledge and interesting directions. Interested friends can refer to my previous article “How to Create an Interesting Engineering CTF Competition,” which contains many creative questions!

Vulnerabilities Found

I found a total of four vulnerabilities across three products. In addition to the issues discussed in this article, I also discovered the following three common website vulnerabilities:

1. Never Trust The Client!
   This is a basic issue where the frontend directly sends the ID to the backend, and the backend accepts it without verification; it should be changed to verify a Token.
2. Password Reset Design Flaw
   I actually forgot the specifics, but I remember it was a programming flaw that allowed the password reset process to bypass email verification.
3. XSS Issue
4. The Vulnerability Discussed in This Article

The search method was entirely black-box testing, and the only product where I found the XSS issue was one I had participated in developing; I had no involvement with the code of the others.

Current Status of the Vulnerabilities

As a white-hat hacker, I reported all the issues I found to the engineering team immediately, and they have been fixed. Now that two years have passed, I think it’s time to make this public; however, considering the position of my former company, I will not mention which product had this vulnerability. Everyone can just refer to the process and reasons for discovering this vulnerability!

Consequences of the Vulnerability

This vulnerability allows an attacker to change the target user’s password at will and log in to the target user’s account using the new password, thereby stealing personal data and engaging in illegal activities.

Main Causes of the Vulnerability

As the title suggests, this vulnerability was triggered by a combination of multiple factors, including:

• Account login does not support two-factor authentication or device binding
• Password reset verification uses a serial number
• The website’s data encryption feature has a decryption vulnerability
• Misuse of encryption and decryption functions
• Incorrect design of the verification token
• The backend does not re-verify the correctness of the fields
• User email on the platform is public information

How to Reproduce the Vulnerability

Since user emails on the platform are public information, we first browse the target account to be hacked; after knowing the email, we go to the password reset page.

• First, enter your own email to initiate the password reset process.
• Then, enter the email of the account you want to hack and also initiate the password reset process.

Both of these actions will send out a password reset verification email.

Go to your own email to receive the password reset verification email.

The password change link has the following URL format:

https://zhgchg.li/resetPassword.php?auth=PvrrbQWBGDQ3LeSBByd

PvrrbQWBGDQ3LeSBByd is the verification token for this password reset operation.

However, while observing the verification code image on the website, I found that the link format for the verification code image is also similar:

https://zhgchg.li/captchaImage.php?auth=6EqfSZLqDc

6EqfSZLqDc reveals 5136.

So what happens if we plug our password reset Token into it? Who cares! Let’s try it!

Bingo!

But the verification code image is too small to obtain complete information.

Let’s continue to find exploitable points…

Coincidentally, the website, in order to prevent crawler interference, presents users’ public personal data emails as images, keyword: image presentation! image presentation! image presentation!

Let’s open it up and take a look:

Personal Information Page

Webpage Source Code Part

We also obtained a similar URL format result:

https://zhgchg.li/mailImage.php?mail=V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt

V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt reveals zhgchgli@gmail.com.

Again, who cares! Let’s try it!

Bingo!🥳🥳🥳

PvrrbQWBGDQ3LeSBByd = 2395656

After Decoding the Password Reset Token and Discovering It’s a Number

I thought, could it be a serial number…

So I requested a password reset again using the email to obtain the new token from the email, which turned out to be 2395657… what the fxck… it really is.

Once I knew it was a serial number, things became easier. That’s why the initial operation was to first request the password reset email for my own account, then for the target account; because I could already predict the next password request ID.

Next, I just need to find a way to convert 2395657 back to the Token!

Coincidentally, I Discovered Another Issue

The website only performs frontend validation for the email format when editing data; the backend does not re-verify whether the format is correct…

Bypassing the frontend validation, I changed the email to the next target.

Fire in the hole!

We got:

https://zhgchg.li/mailImage.php?mail=UTVRZwZuDjMNPLZhBGI

At this point, take this password reset token back to the password reset page:

Hacking successful! Bypassed verification to reset someone else’s password!

In the end, due to the lack of two-factor login protection and device binding features, once the password was overwritten, I could log in directly and impersonate the user.

The Root of the Issue

Let’s review the entire process.

• Initially, we wanted to reset the password, but found that the password reset token was actually a serial number, not a true unique identifier Token.
• The website misused encryption and decryption functions, not distinguishing between different uses; almost the entire site used the same set.
• The website had an online arbitrary encryption and decryption entry (equivalent to key compromise).
• The backend did not re-verify user input.
• There was no two-factor login protection or device binding feature.

Correction Methods

• Fundamentally, the password reset token should be a randomly generated unique identifier Token.
• The website’s encryption and decryption parts should use different keys for different functions.
• Prevent external arbitrary operations on data encryption and decryption.
• The backend should verify user input.
• To be safe, add two-factor login protection and device binding features.

Conclusion

The entire journey of discovering this vulnerability surprised me because many of them were basic design issues; although the functionality might seem to work at first glance and have minor holes that still seem safe, multiple small holes combined can create a big hole. It’s really important to be cautious during development.

Further Reading

• How to Create an Interesting Engineering CTF Competition
• APP Uses HTTPS for Transmission, but Data Still Gets Stolen
• The Security Issues of SMS Verification Codes for Password Recovery

If you have any questions or feedback, feel free to contact me.

---

This article was first published on Medium ➡️ Click Here

Automatically converted and synchronized using ZMediumToMarkdown and Medium-to-jekyll-starter.

Improve this page on Github.

Follow Me on Medium 999+ Followers

1,949 Total Views
Last Statistics Date: 2025-03-25 | 1,941 Views on Medium.