Due to the number of quantifiable parameters allowing a program to determine their presence, many security flaws are detectable by vulnerability scanners. On the other hand, logic flaws require a human understanding of the context and the functioning of the application, making their detectability by scanners very difficult, if not impossible.

Hello hunters, today I decided to talk to you about a type of vulnerability on which we have a biological advantage over scanners and some of my findings.

Definition from PortSwigger: Business logic vulnerabilities are flaws in the design and implementation of an application that allows an attacker to elicit unintended behavior. This potentially enables attackers to manipulate legitimate functionality to achieve a malicious goal. These flaws are generally the result of failing to anticipate unusual application states that may occur and, consequently, failing to handle them safely.

This happens when the developers of an application do not foresee all the uses of a feature, and, therefore, secure the functionality according to only initially foreseen uses, which usually only relates to normal use and behavior. From the moment the development team omits certain uses of a feature and the behavior of a potential attacker towards it, they do not put in place the appropriate security (filters, access controls…) which often leads to logic flaws.

An attacker will therefore use “legitimate” features in an unexpected way to perform actions or access data that would normally be inaccessible to them. As you have probably understood, the nature of the impact of the flaw and its severity will vary a lot depending on the application and more precisely, on the compromised feature.

Let’s try to see more clearly with some of my findings, as the program is private I will willingly change certain information in order not to compromise the security of the company.

⚙️ Context

It had been a few weeks since I had been hunting for bugs on a private program, I had already found several vulnerabilities and I was starting to think I was done and there wasn’t anything interesting left, of course, I was wrong.

The web application allows — among others — to post content, but also to comment and like the content of other users. It is possible to set its content as private so that it is not visible to other users.

I had played a bit with this functionality by trying to access the private content of my victim account — previously created for testing purposes — via an IDOR and different methods related to the large Broken Access Control vulnerability family but without success.

🏹 Outcome

I noticed that when commenting or liking content, the server sent back several data including the content in question. At that moment, I asked myself: “What if it was possible to comment or like private content?” This would allow me to access the private content, and therefore .. to have my new vulnerability!

So I retrieve the ID of the private content of my victim account, I create, then send my request with the ID in question and, .. it works! I was able to comment on the content of a user who had set his content as private and at the same time, retrieve the content in question. I reiterate the same thing with the likes, and .. same thing!

In addition to retrieving private information, the victim account is notified by email when a comment is posted on its content, which is not great — you will agree — given the confusion that this can cause … Naturally, one does not expect to be notified about content that is supposed to be private. This kind of detail should be mentioned in the report to increase the impact, which in this case, can harm the trust that users have in the platform.

🧩 Why was this vulnerability present?

The content set as private does not appear on the platform (unless you are logged in to the author’s account), starting from this postulate, the development team has — probably — thought that a user would not have the opportunity to perform these actions, because the user interface did not allow it (absence of private content).

By not putting oneself in the place of an attacker, who is not limited to sending requests from a browser (-> curl, proxy), they omitted to secure access to certain actions/features related to these cases. It was therefore possible to use legitimate features — in the first place — for bad purposes, which is what we call a business logic vulnerability.

The classic IDOR attack was avoided by restricting access to private content via their IDs, but failing to project further into the possible behaviors made this breach and its exploitation possible.

Scanners are of course very useful for automating the search for vulnerabilities that require little or no deep reflection, but logic flaws are far from their specialty. As we have seen, it is necessary to understand the context of an application to determine the expected behaviors and those that are not, and fortunately, this is something that we — humans — usually know very well.

Between the many automated scanners that run almost constantly on the programs and some researchers who act — almost — as such by sending payloads everywhere, the search for business logic vulnerabilities is an opportunity to seize and on which it is profitable to deploy efforts.

Spending several days on a program to master its context can lead to finding vulnerabilities that no one has found despite the age of the program!

Thank you for reading me, if you have any questions do not hesitate to let me know. Happy hunting 🏹

My Twitter account : https://twitter.com/blank_cold