IDOR I$ PUR3 L0V3
Just Exploration of my Best Exploitations
Hello guies , I am again back with one of my recent findings that have been patched but didn't got recognized(Long Story Short[People can be too selfish sometimes]). So here i will be disclosing the full description and Exploration of my finding.
So , Last month was a very good part of my life because many IDOR's were reported and rewarded and life was going very well when i encountered this particular IDOR where i actually learned some real-life lessons to be considered while reporting further.
So, it was again a fine day when i was testing some local web app like phpMyFAQ as one of my best research buddy (Ishaq Mohammed,@security_prince) was getting some good number of CVE's and i was thinking of getting some in my name too(Greed is a bottomless pit which exhausts the person in an endless effort to satisfy the need without ever reaching satisfaction, literally true) but when i opened and started checking out the local app , it gave some garbage error which was just going above my head.
So, i said to myself , what will even happen if i find some bug in it? Let's try some real-life web application based bug on a real time environment. So i started searching for some sites and than i got stuck with this site and while checking the site i saw that it's using PHP pages so first thing i tried was searching for some parameter to try SQLi , and found a injection point where i was getting a time based attack but than i said who cares(i am saying this because i am nowadays very weak with sql querries) about it and went ahead and created two accounts. so as i signed in and went to view my profile , i saw no user id and i was like...
if it's not showing in the url than it must be sending in POST parameter , so i went ahead and intercepted my request. I saw that ohh!!! hell yeah!!! i am half way there to find a nice bug...
The intercepted image looks somewhat like this:
I found that the web app is using a account_id to save the changes , i was feeling top of the world
okay , so now it's time to see if the account_id has some permission set or is it open to attack? , i went ahead and logged in to my 2nd account in incognito mode firefox and i checked on if IDOR is possible and Hell hydra!!! i mean Hell Yeah!!! it was a proper IDOR which was saving changes of my 1st account details in my 2nd account.
Most of us in this time will be so happy that we will go ahead and make a report and send it to the respective authorities but bang me i didn't , i just don't want a horizontal privilege escalation i want the total account to be taken over in a single shot , so i found the perfect thing in my line of sight
and I was in cloud nine....
Yes , you see it correct , there was no validation on password change , NO CURRENT PASSWORD Required!!! So, what you see here is a weak password policy implementation. See this is the reason why OWASP has included this as a security issue.
Okay, time to check the list of items in our basket. So what have we got actually? one IDOR , 1 password policy issue and a Big ACCOUNT TAKEOVER Vulnerability. Do you see what i did here???
IDOR+Weak password implementation = Account TAKEOVER!!!
So , i went ahead and change the account_id of 1st account with the 2nd account to change the user details and password of 2nd one with my 1st account , i was so happy to cry my heart loud once it changes the password but....but....... Nope it didn't instead it showed me an error that "email address is already in use" , damnit!!!!!!!!!
So here was the trick!!! while changing the account_id , we also need to change the email id of the user so that a new mail id will be registered in the web app DB(As the damn Vuln web app is somehow checking on the email id and not on big LoopHoles) , you will also see in the video POC that while intercepting the request with change of account_id i have also changed the email id so that it will be a proper and complete ACCOUNT TAKEOVER!!!
So with all set up correctly , i again repeated the steps and it worked , It was a complete account takeover by combination of two different bugs.
I was quite happy with my findings , i reported and they patched.
if it's not showing in the url than it must be sending in POST parameter , so i went ahead and intercepted my request. I saw that ohh!!! hell yeah!!! i am half way there to find a nice bug...
The intercepted image looks somewhat like this:
I found that the web app is using a account_id to save the changes , i was feeling top of the world
okay , so now it's time to see if the account_id has some permission set or is it open to attack? , i went ahead and logged in to my 2nd account in incognito mode firefox and i checked on if IDOR is possible and Hell hydra!!! i mean Hell Yeah!!! it was a proper IDOR which was saving changes of my 1st account details in my 2nd account.
Most of us in this time will be so happy that we will go ahead and make a report and send it to the respective authorities but bang me i didn't , i just don't want a horizontal privilege escalation i want the total account to be taken over in a single shot , so i found the perfect thing in my line of sight
and I was in cloud nine....
Yes , you see it correct , there was no validation on password change , NO CURRENT PASSWORD Required!!! So, what you see here is a weak password policy implementation. See this is the reason why OWASP has included this as a security issue.
Okay, time to check the list of items in our basket. So what have we got actually? one IDOR , 1 password policy issue and a Big ACCOUNT TAKEOVER Vulnerability. Do you see what i did here???
IDOR+Weak password implementation = Account TAKEOVER!!!
So , i went ahead and change the account_id of 1st account with the 2nd account to change the user details and password of 2nd one with my 1st account , i was so happy to cry my heart loud once it changes the password but....but....... Nope it didn't instead it showed me an error that "email address is already in use" , damnit!!!!!!!!!
So here was the trick!!! while changing the account_id , we also need to change the email id of the user so that a new mail id will be registered in the web app DB(As the damn Vuln web app is somehow checking on the email id and not on big LoopHoles) , you will also see in the video POC that while intercepting the request with change of account_id i have also changed the email id so that it will be a proper and complete ACCOUNT TAKEOVER!!!
So with all set up correctly , i again repeated the steps and it worked , It was a complete account takeover by combination of two different bugs.
I was quite happy with my findings , i reported and they patched.
IDOR IS PURE LOVE 💗💗💗
Here is the Video POC:
A Strict Note : Do not report them!!!
Greed is a bottomless pit which exhausts the person in an endless effort to satisfy the need without ever reaching satisfaction.
Read more at: https://www.brainyquote.com/quotes/quotes/e/erichfromm391095.html?src=t_greed
Read more at: https://www.brainyquote.com/quotes/quotes/e/erichfromm391095.html?src=t_greed
Greed is a bottomless pit which exhausts the person in an endless effort to satisfy the need without ever reaching satisfaction.
Read more at: https://www.brainyquote.com/quotes/quotes/e/erichfromm391095.html?src=t_greed
Read more at: https://www.brainyquote.com/quotes/quotes/e/erichfromm391095.html?src=t_greed
Greed is a bottomless pit which exhausts the person in an endless effort to satisfy the need without ever reaching satisfaction.
Read more at: https://www.brainyquote.com/quotes/keywords/greed.html
Read more at: https://www.brainyquote.com/quotes/keywords/greed.html
Greed is a bottomless pit which exhausts the person in an endless effort to satisfy the need without ever reaching satisfaction.
Read more at: https://www.brainyquote.com)
Read more at: https://www.brainyquote.com)
Hello,
ReplyDeleteis IDOR possible on ASP.net website where i got "__EVENTTARGET", "__EVENTARGUMENT", "__VIEWSTATE" etc parameters to prevent this all attacks?
IDOR is possible if you can check the parameters do not have proper permissions , those "__EVENTTARGET", "__EVENTARGUMENT", "__VIEWSTATE" , these are really used for CSRF attacks.
DeleteThis comment has been removed by the author.
ReplyDeleteGreat writeup bro
ReplyDelete