How We “Forced” Our Client To Fix A Low Severity Security Bug And Still Got Appreciated!

We at DefCore Security intend to provide great visibility to clients while working on the pentest engagement. We give our clients the freedom to oversee every stage of testing activity. One of the ways is by sharing the Daily status of findings which highlights the scope of asset/application covered during that day, Findings, Feedback, etc.

During one of our recent Engagements for a major ECommerce Client, we found an IDOR that allowed an attacker to view very limited order details of victims by providing their Email Addresses. The information leak was sensitive. However, some details were masked like Order ID apart from the Order Value & non-enumerable “accountID” (UUID) of the intended customers of this site. This makes this a low severity issue.

Non-enumerable Account ID leakage of other users isn’t a major issue by itself, however one can use this info to create an attack chain and escalate this to a major security flaw.

As always, we added this to our observation and daily findings report and shared it with the customer. The next day, client got back to us with feedback, that they could consider hiding order value but won’t consider hiding “accountID” unless we show them an attack chain that would leverage this info.

From our experience, we knew low severity issue like this could be chained into an interesting attack chain and need to be fixed. Its our responsibility to provide client with necessary input to make them understand the possibility of a major flaw, after all, there is a reason why client made the “accountId” non-enumerable.

We Took The Challenge

Gonna do it anyway.

During the Content Discovery phase, One of the ways by which we find new hidden endpoints is through endpoints alteration and fuzzing with permutations. As part of this process, we make a custom wordlist based on the application which contains the endpoints, paths, ID’s, interesting words/parameters, etc and using alterations/permutations, we form a fuzzing list of endpoints. Just like Altdns for subdomain enumeration.

Using this technique, we found an Endpoint through which we were able to change any other user's email address by providing their “accountID”.

Bonus — No Email change confirmation of any form is required. This endpoint wasn’t available in JS files, source code or in burp suite history.

Now, this issue alone wouldn’t have had a high impact as attackers cannot guess the victim “accountId” but since we already identified a way to leak any other user’s “accountID”, we can now complete the chain and perform a perfect No Interaction Account Takeover.

Proof Of Concept

1. Get victims “accountId” from order details endpoint using victim's email.
2. Use the “accountId” for changing victim's email to attacker's controlled email address through email change endpoint.
3. Since there isn’t any email change confirmation required on this endpoint, the attacker can use the password reset functionality and get the link on his email address.
4. Use the password reset link to change the password and take over the victim's account without his interaction or knowledge.

So just by knowing someone’s Email Address, we were able to Take Over their Account.

By escalating account ID leakage to an Account Takeover, we were able to showcase to our client to fix a low severity bug for good.

We recommended the client to only accept logged-in users’ email addresses in order details endpoint so that they don’t have to hide any other sensitive parameter if introduced in future releases.

In the end, Client was happy and so were we.

Want Us to have a look, test and secure your App? Reach out to us @ DefCore Security to know more.