How I Prevented a Data Breach by Reporting an IDOR in a System Exposing over 500,000 US Passports

Facundo Fernandez
5 min readAug 14, 2024

--

If we haven’t connected on LinkedIn yet, go ahead and send a request!

Background: I had been working on a Tesla Target URL for over an hour trying to bypass their Web Application Firewall (Akamai) and I had made little to no progress. I knew I had found a parameter that was vulnerable to SSRF but I could not find a way to bypass Akamai. I thought to myself, I need to find another target that is using an API in a similar way to test this attack. With this in mind, I can proceed to explain how I found the largest IDOR vuln. in my career.

As part of my Reconnaissance strategy, I always do a quick Facet Analysis on Shodan.io. The facet analysis feature of Shodan.io is a powerful tool that allows users to quickly filter and summarize search results based on specific characteristics (facets) of the data. Facets are essentially categories or fields that provide aggregated insights into the data, such as operating systems, ports, cities, ISPs, HTTP titles, and more. I tend to do a quick overview of the http.title.

I found the target API via the Facet Analysis

Here’s a list of HTTP titles that are often associated with systems prone to vulnerabilities:

BIG-IP
Apache Tomcat
OpenVPN
Fortinet/FortiGate
Citrix Gateway (NetScaler)
Dashboard / Login
PHPMyAdmin
Cisco ASA
Oracle WebLogic
Microsoft Exchange
SolarWinds
Elasticsearch
Nagios
Drupal
Zimbra
Jenkins
Splunk
WordPress
Nginx
GlassFish
Palo Alto Networks
IBM WebSphere
SonicWall
VMware Horizon
MikroTik RouterOS
Check Point
Trend Micro
Atlassian Confluence
SAP NetWeaver
Kubernetes Dashboard

You can accomplish the same using httpx from Project Discovery:

cat domains.txt | httpx -sc -ip -server -title -wc 
Scan of indeed.com

While searching for a target similar to the Tesla one, I revisited a website I’d used 5–6 years ago. I can’t disclose the name of the organization but I had a pretty good idea of what to expect. However, I stumbled upon a title that caught my eye. It was something like “Submission System” — a pretty interesting title.

From shodan.io

I remembered using this application like 5–6 years ago and I had submitted my passport so I was given an option to print or download the file.

After I clicked Documents > Download, my file automatically downloaded, however, the download button would do an HTTP GET request to:

/production/api/v1/attachment?id=4550381&enamemId=123888

I caught it on Burp Suite and I had two juice parameters.

  1. id= [ID of the file]
  2. userID

Now it’s easy to guess what happened, by changing the file ID you can download different files without having to be the “owner” of the file.

An IDOR (Insecure Direct Object Reference) is a type of security vulnerability that occurs when an application provides direct access to objects (like files, database records, or URLs) based on user-supplied input (attachment?id=4550381&enamemId=123888) without properly verifying whether the user has permission to access those objects.

The result was hundreds of thousands of these:

Every ID was a different document. Absolutely insane.

I also found another endpoint named attachment-list”. Together with the parameter enamemIdI went to:

/api/v1/attachment-list?enamemId=123888

Among the files I had uploaded, I found:

Take a second to see that. Can you find the red flag? Remember the GET request to download the file?

/production/api/v1/attachment?id=4550381&enamemId=123888

Understanding the Vulnerability

  1. Absence of enamemId:
  • If the API endpoint returns data where enamemId is consistently null or not provided, it suggests that the endpoint might not enforce proper access controls based on user identification or ownership.

2. User Uploads:

  • If users are uploading files and those files do not have an associated enamemId, it could mean that the API lacks a mechanism to tie uploaded files to specific users or entities. This could potentially lead to unauthorized access to other users' files if there's no verification or association mechanism.

The files do not have an owner. Anyone can access them without having to be the legitimate owner.

Interestingly enough, I was not able to get the API to show me the files of user using by manipulating the param enamemId:

/api/v1/attachment-list?enamemId=xxxxxxx

As I was preparing the report for the organization, the following actions were recommended:

  1. Implement Access Control:
  • Ensure proper authorization checks are in place to verify that the requesting user has permission to access the requested resource.
  • Utilize user session information to confirm that the user is entitled to access the specific attachment.

2. Use Indirect References:

  • Replace direct references to objects (e.g., attachment IDs) with indirect references such as tokens or hashed values that are mapped to actual object IDs on the server side.

3. Input Validation:

  • Validate the id parameter to ensure it adheres to expected formats and values.
  • Implement rate limiting to prevent automated exploitation

4. Secure API Design:

  • Adopt security best practices for API design, including the use of OAuth, secure tokens, and ensuring all endpoints are protected by proper authentication and authorization mechanisms.

The issue was triaged and is now fixed.

If we haven’t connected on LinkedIn yet, go ahead and send a request!

STAY ETHICAL!

--

--

Responses (3)