🎨
Findings
  • Discovered Vulnerabilities
  • Finding Security Vulnerabilities in Android Applications
  • API Endpoints lead to Sensitive Information Disclosure and PII leakage of Employees
  • HTTP Dangerous Methods Enabled - P1
  • Subdomain Takeover
    • Subdomain Takeover
  • XSS
    • XSS on error page
    • Interesting XSS
  • 2FA Bypass
    • Brute-force Protection Bypass
    • Response Manipulation
  • Crazy Account Highjack
  • OAuth Misconfiguration
  • Open Redirect
    • Open Redirect >> XSS
    • Automation
Powered by GitBook
On this page

Was this helpful?

API Endpoints lead to Sensitive Information Disclosure and PII leakage of Employees

Read how I used my own tool and bash skills to detect API Endpoints and extract sensitive data from it

PreviousFinding Security Vulnerabilities in Android ApplicationsNextHTTP Dangerous Methods Enabled - P1

Last updated 3 years ago

Was this helpful?

I picked up a cryptocurrency Web App as a target to test functionalities on the main application and business logic flaws. But before that I enumerated the subdomains using my own tool: which uses a bunch of other pre-existing tools for subdomain enumeration and sorts & filters them along with other such as CVE detection, URL extraction, fuzzing and much more. I then passed the text file containing target subdomains through one of my other tools: which enumerates API Endpoints of multiple targets.

Upon visiting the endpoints, I realized these were showing gitlab account details of the employees working in the Gitlab Infrastructure of this company. The following data was leaked: 🤐 "name"; "username"; "Gitlab account URL"; "email id"; "linkedin"; "skype id"; "twitter"; "organisation name"; But wait, there's more.

Since the tool only showed the first 4 users, I thought of bruteforcing the id from 1 to 150. Obviously this can be done using BurpSuite but the geeky hacker inside me loves using CLI. 1. I created a bash script to loop though 1 to 150 and return the endpoints. for i in {1..150} do echo "https://gitlab.infra.target.com/api/v4/users/$i" done output: https://gitlab.infra.target.com/api/v4/users/1 https://gitlab.infra.target.com/api/v4/users/2 . . . https://gitlab.infra.target.com/api/v4/users/150 . saving the users found in a file: ./loop.sh >> users.txt 2. To find which of these users are valid: cat users.txt | httpx -silent -status-code |grep 200|cut -d " " -f1|sort -u >vaildusers.txtcounting number of valid users: cat validusers.txt | wc -l This returned 120. This means the information of 120 employees was leaked !!! 😯

Now I wanted to check if the leaked Gitlab accounts of the employees had any sensitive repositories.

Extracting the Gitlab user URLs from 120 endpoints could take a lot of time and effort. This is where my bash skills came in handy. 😎

I created another bash file that took input from "validusers.txt" that we created earlier and curled each endpoint and returned the response of each. Then I saved all the responses in one file. cat vaildusers.txt | while read line do curl $line printf "\n" done ./read.sh >> responses.txt . This file contained the sensitive data of all the 120 employees. Since it was of the form: "name":"john";"email":"john@gmail.com";"URL":"https://gitlab.infra.target.com/john" (just an example) . I thought of extracting the Gitlab account URL using the "cut" operation

cat responses.txt | cut -d '"' -f22 >> gitlab.txt . Now this file contains the URLs of the accounts of the employees of this company's Gitlab instance. Along with the other leaked data, this is also considered sensitive and must be accessible only internally.

I went through all the accounts and found a few personal projects that leaked information which was not supposed to be accessible without authentication. I will talk about how I did this in a separate blog some other day.

So this was how I was able to find sensitive information of employees and their Gitlab accounts on the company's Gitlab instance which contained more sensitive information. 💯

Once again, feedback is most welcomed. 😄 Feel free to use my tool: to enumerate API endpoints. Alternatively, you may also use , but the reason I made get-api is to avoid entering the commands, wordlists and options every single time. Just pass the target file though get-api ./getapi.sh target.txt and it takes care of the rest for you.

get-api
ffuf
VulnHunt
Features
get-api
(Click to zoom in)