Pre-Seeding Trap Story: Exploiting PII Data Before It’s Logged

17 hours ago 8
BOOK THIS SPACE FOR AD
ARTICLE AD

Ahmed Elmorsi

بِسْمِ ٱللَّهِ ٱلرَّحْمَٰنِ ٱلرَّحِيمِ

Hello friend , it’s been a long time

Today we are talking about How I could exploit Pre-Seeding Trap to leaks Victim’s PII data and got $$$$ in a Private BBP on H1
Let us start with the target:
Basically it’s a Insurance Company that provides cash benefits and/or medical care for workers who are injured or become ill as a direct result of their job
The Story:

After spending 2 days looking for a program to hack I came across this program , I had already submitted multible bugs to this program the last year and This program’s team already know me
Started My work by testing every single function in the application

Looking for issues like Privillage managenet issues , server side issues and Client side based vulnerabilities

After 2 hours I came across this endpoint :
https://app.com/claim/auto/new/general-info

This was used in a condition that you are an injured worker you report your data and upload files related to you
I found out that this endpoint contains a critical PII data

So I know that if I focused on this endpoint I will have a good bug here
Let’s start with the flow of this function
First you have to fill the data of the customer using this request:

So Basically after filling the first form which is “Customer”
Your report will be assigned to a random ID with 6 digits , in that time I was not sure what was this ID used from . but after moving to the second section of the report I found out this :

As you see the application used this ID as an Identitifier for the report ,

I continued my testing noramlly and filled the whole report and I came to my burp history and found those 2 Requests

This request as you see is used in each form of your report to save your submitted data and use th ID as an Identitifier for your report
Here I tried to test for IDOR so I created another report form another account and tried to edit it and successfully did that !

Wanted a bit more step so I wanted to have the ability to read the victim’s report and it was a straight forward step:

Change Request method to GETsend the ID as a part of your GET request and check if you can retrieve it

Wanted to Report it here but wanted to test the last thing came to my mind then:
why do I remove the cookies ?
I did this and I could not believe my eyes

Honeslty I was Sure that I will face some problems with this bug with the triager and asked my self
How could no one before me found this bug ?

I reported it and after 2 hours , the triager said this :

After reading that carefully I knew that my mission will not be easy to find a way to get that Random ID

Literally I tried every single way I know to get that ID:

Javascript analysis but if you noticed the ID is comming back from the server so it’s not generated on the frontendWeb Archive , Virustotlal and Urlscan.io but with no resultsSearched if the app has a github report to search their for any leaked ID but also with no results

I spent the whole night thinking about this issue till I came across a Pre-Seeding Idea:
I Can create a claim and then send it to the victim and easilly after the victim fill the report and can reopen the claim again and get the victim’s data
But why would someone remove the data of a report and then fill it again
So why don’t I do the same scenario but instead of creating a normal report with my data , I can create a empty one
Let’s us try this:

Because this endpoint does not require Authentication we can access this report in the browser normally

So now we can trap the user by :

Creating an empty claimSend that claim to the victim :
https://app.com/file-claim/auto/pVn67V/general-infoReopen the claim after the victim fills it

Send these steps to the traiger and finally he respond with this

But eventuall he Triaged the report but after changing the severity to Medium But still I got $$$$.

See you in my Next Bug Story.

Thanks.

Read Entire Article