All your files belongs to Me (An IDOR Story)
This is small story about IDOR bug in private bug bounty program, I do bug bounties as a hobby in my free time and this lead to an interesting IDOR bug in one of the private bug bounty program, As you might have aware about the norms of bug bounty world we will using “https://www.test.com” instead the real URL to adhere the private bug bounty guide lines but this should impact out story at all.
IDOR is short form of Insecure direct object references which is widely known vulnerability in web application. I am not going to waste your time in IDOR definition, I know you can google it too ;). It is hard to block IDOR attacks with WAF.
About Application that I was testing
The web application I was testing is related to financial data collected by the organization and process them internally so that they can remain complaint in terms of taxation of the country. User can login to web application and submit or upload the financial documents with PII details. Also web application is having front which utilizing api server to full fill the requirements of the user which is very normal for any new/modern web application you might have seen bunch of web application which utilize APIs now days.
What went wrong with application
As website allow user to upload the financial documents and save them in the user’s account. but what if attacker can change any user’s uploaded file with attacker’s define file? sounds interesting ……. this will be serious security issue for the user and the organization as the uploaded data contains financial information and this information required for the organization to remain in complaint so you can imagine the impact of this bug.
Craft the Attack
- You need to create account in the web application.
- Login to account and try to upload any test document via upload functionality. (Yes I tried for RCE but failed :P)
- Use the burp suit proxy to read the traffic/request.
- You can see the Request look like below
PUT /files/42 HTTP/1.1
Accept: application/json, text/plain, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Authorization: Bearer
Content-Type: multipart/form-data; boundary=---------------------------15499173327838136101963296492
Content-Length: 577139
Connection: close-----------------------------15499173327838136101963296492
Content-Disposition: form-data; name="file"; filename="test.pdf"
Content-Type: application/pdffile content here-----------------------------15499173327838136101963296492
Content-Disposition: form-data; name="vendorId"62
-----------------------------15499173327838136101963296492
5. As you have noticed here 2 values are interesting /files/42 and vendorId 62
6. What if we can use burp intruder and send the same request but keep changing the these 2 values (mentioned in step 5) from 0 to 1000 ?
7. This will upload the attacker’s define file to all user’s account in the web application and replace their original uploaded document. no user interaction is required here.
In the end
It was interesting bug for me because It allow me to change any user’s file with my own define file, what is the impact ? well it all depends on attacker imagination attacker can embed malware in pdf and replace all user file or embed XSS code inside the PDF and much more.
Yes it was the P1 :)
