💁 Exposed Invoice URLs - A Gateway to Customer / Client PII Leakage

I hope you're all doing well and actively searching for vulnerabilities! Today, I want to tell you about how I earned a three-digit bounty for reporting a critical bug related to Personally Identifiable Information (PII).

Are you eager to learn from the insights shared on https://twitter.com/BountyAdvice To begin with, let me explain what PII is, and then I'll provide you with details about the Vulnerability Report and share some screenshots of the Proof of Concept (POC).

PII - Personally Identifiable Information

Personally Identifiable Information (PII) refers to personal information about a person or an organization that becomes exposed without proper authentication. This information needs to be specific enough to distinguish one individual from others to be classified as PII.

For example, a first name alone is usually not considered PII since many people can have the same first name. However, a complete name that includes the first, middle, and last names is generally considered PII by most organizations. Other examples of PII include revealing details like mobile numbers, personal email addresses, PAN details, and Aadhar details. These types of information can also be considered as PII because they can uniquely identify someone.

The most common definition is provided by the National Institute of Standards and Technology (NIST)

It says that: PII is any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.

How I Discovered This Vulnerability

1. Collected subdomains using subfinder, a tool primarily employed for subdomain enumeration and the identification of passive subdomains on websites through the utilization of paid API keys integrated into subfinder

   subfinder -d domain.txt -o subfinder-output.txt
   

2. During the subdomain enumeration process with subfinder, I identified a unique subdomain, namely [http://invoice.abc.com].

3. To further investigate, I conducted fuzzing activities using the dirsearch tool, which led me to discover the endpoint /jsp/show_invoice.jsp?ref=xyz. The following command was used to perform this task:

   dirsearch -t 30 -e "*" -r -i 200 --full-url -u https://invoice.abc.com/
   

   Dirsearch offers an array of command flags, including:

   • -t for specifying the number of threads
   • -e for defining extensions (e.g., php, asp)
   • -r for recursive brute-forcing
   • -i to include specific status codes
   • --full-url for displaying full URLs in the output
   • -u for specifying the target URL(s)

4. For additional historical data and potential vulnerabilities, I explored the Wayback Machine via a browser-based approach: https://web.archive.org/cdx/search/cdx?url=*.abc.com/*&output=text&fl=original&collapse=urlkey or by utilizing the GitHub tool called waybackurls [https://github.com/tomnomnom/waybackurls]. The following command demonstrates how to use waybackurls effectively:

   cat domains.txt | waybackurls > urls
   

   By employing waybackurls, I successfully uncovered reference IDs associated with invoices. Subsequently, by applying these reference IDs to the 'ref' parameter, I identified invoices that were inadvertently disclosing Personally Identifiable Information (PII) of both clients and customers.

To Summerize, Invoices should not be publically accessible or there should be somekind of Authentication to access. Or else should not contain any PII of end Client/ Customer.

Proof of concept

Reported on 6th june 2023

Triged on 7th June 2023

Rewared on 9th june 2023