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/

Follow publication

Email and home address disclosure using unauthenticated API endpoint worth $500

--

Namaste hackers, I am back with a new bug bounty write-up. In this blog, I am going to show how a unauthenticated endpoint reveals email and home address of users. The company is having a public bug bounty program on Hackerone. I will be using redacted.com as the main domain.

The company is a technology platform through which customers book different types of services.

www.redacted.com and api.redacted.com are in scope. As usual, I fired up my burp suite and started capturing every request in the proxy tool burp suite. redacted.com is the main domain but all the traffic routes through api.redacted.com. I used the company in the past to book some services so I have some bookings in my account.

There is an option on the platform that allows you to use the SOS feature during your bookings if something goes wrong. The SOS feature is only active during your booking time and is disabled afterward. I opened one of my bookings and clicked on SOS, and I received a response stating that the Emergency Helpline will be available during your service delivery.

I reviewed the request for this call in Burp Suite. A POST request is sent to the endpoint https://api.redacted.com/api/v2/help-recovery/gethelp/getHelpFlow with the body:
{"user_type":"customer","flow_type":"request","request_id":"booking_id","group_key":"customer_sos_group","mode":"published"}. In the response, the email address, home address, and service details of users are being disclosed. I replayed the same request without an authentication token and was still able to view the email address, home address, and service details in the response.

The main problem is with the impact because the request_id is a randomly and uniquely generated hashed string. So, brute-forcing the request_id is not feasible. I explored the application but could not find any API endpoint that would allow me to fetch the multiple request_id of the other users.

I started looking for request_id values in Wayback URLs and on the Internet Archive. To my surprise, I found approximately 100 request_id values on the Internet Archive. Now, I have around 100 request_id values that can be used to fetch user’s email addresses, home addresses, and service details by using the vulnerable API endpoint https://api.redacted.com/api/v2/help-recovery/gethelp/getHelpFlow.

I quickly write a nice report to the security team through Hackerone. The Company fixed the issue and rewarded a bounty of $500.

Timeline:

November 20, 2024 — Reported

November 20, 2024 — Triaged

November 25, 2024 — Fixed

December 02, 2024 — $500 Bounty awarded.

Thanks for reading, hope you learned something new. Do clap and share if you like. Sayonara and Happy Hacking!

Twitter: 7he_unlucky_guy
Linkedin:
Vijeta

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

--

--

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/

Written by the_unlucky_guy

Security Engineer | Never Forgive Never Forget

Responses (5)

Write a response