Thinking outside the box: 3 creative ways to exploit business logic vulnerabilities in pentests
Business logic vulnerabilities aren’t new, but they often go untested (and unnoticed) because malicious actors can find flaws in the implementation of (almost) any web application.
These flaws are particularly dangerous because attackers exploit behavioral patterns by interacting with apps in different ways than intended. When exploited successfully, they cause serious disruption, including business processes impact and reputational damage.
So why should companies be concerned about business logic flaws and how can you find and report them?
Let's get to know these security vulnerabilities better.
Why business logic vulnerabilities matter - a real story
Let’s talk business logic. More specifically, how malicious actors use business logic flaws to compromise an organization’s critical and legitimate functions.
But, first, let me tell you a short story about a bank robbery in which malicious hackers are the main characters. I’m talking about the famous 2016 Bangladesh National Bank heist, when a group of black hat hackers got into the bank’s network through a phishing email. Their goal was to steal a billion dollars and get away. And they almost did.
They planned out the operation meticulously: hack into the network, get access to the SWIFT terminal to make the transfer, and disappear without a trace. If you’re familiar with the story of the heist, there are some important points in the attackers’ strategy worth mentioning: the timing, the printer, the SWIFT terminal, and more. But today we’ll focus on the printer and the SWIFT terminal.
These were the business logic vulnerabilities, which allowed adversaries to manipulate and use them in their attacks:
The printer (the one and only) was the failsafe mechanism for the SWIFT transactions. When a transaction was completed, the printer would quickly put it on paper. If there was something wrong with it, the transaction would’ve been flagged as suspicious and declined. But the attackers knew this – after observing the bank workflow – and compromised the printer. Their tampering caused it to malfunction and print blank pages of transaction records, eliminating the failsafe mechanism.
The second point is the SWIFT protocol. Everyone knows this protocol is very secure because it handles bank transactions, which is why SWIFT transactions are trusted to be safe. Well, malicious actors exploited this business logic flaw. They knew you can’t easily crack the SWIFT protocol which other banks trust, so they compromised the computer handling those SWIFT transactions. They hacked into this system and easily transferred funds into their money-laundering accounts.
What have we learned from this story?
Following this incident, the SWIFT messaging system urged banking institutions worldwide to better understand and reduce their attack surface to avoid large-scale cyberattacks.
This attack was an important reminder that cybercriminals are persistent and creative, especially when motivated to get access to high-value networks and steal a large amount of money. What’s more, this attack also highlights the need for getting ethical hackers’ perspectives on security controls and their implementation.
The key takeaway is that most organizations tend to take the security of their devices for granted. It’s always other people’s job to safeguard the hardware or software. In this case, the victim might say it’s the printer’s vendor responsibility. But it’s also the bank’s, which could have run vulnerability scans or done penetration tests with the printer’s IP address included in the scope. However, from experience, we know that we rarely come across clients who are open to these kinds of tests.
3 practical examples of business logic vulnerabilities
To put theory into practice, here are 3 examples of business logic flaws we saw during our ethical hacking engagements:
1. Client-side only validation
This occurs when the developer trusts that the users are the only ones using the application through the client-side controls. Often, an attacker uses the client-side as a starting point in their process to tamper with the data mid-traffic. A bad actor will use specialized tools such as Burp to intercept the data sent from the client-side to the server-side. In other words, they manage to bypass the validation process.
This allows the attacker to send data to the server and potentially damage the system, depending on the app’s functionality and what it’s used for.
A real-life account takeover story
One of our customers needed to perform a penetration test against a web application that managed transportation services.
The authentication seemed strong because it required 2FA authentication in the form of an OTP (one-time password) received by email.
The same flow applied to the password reset feature. The user asked for a password reset, they provided the username and, after that, they had to type in a valid OTP.
Now, you might think that such OTP values are sometimes guessable (poor implementation might help an attacker launch a brute force attack and find the valid OTP) or that they might be predictable, or not even validated.
This time, the issue was even more unexpected. Once the user requested either a password reset or a login authentication with a known username and password combination, the web application asked for an OTP but also provided it in the POST Response.
This serious misconfiguration enabled us to take over any account, including the ones with admin roles.
Account takeover replay steps for ethical hackers
Here are 6 steps the attacker can perform in an account takeover attack:
1. Mimic legitimate user behavior and ask for a password reset for the victim’s account:
2. Enter an invalid OTP and check the server's response. Notice that, in the next requests, we receive the valid OTP (see the “OriginalOTP Value parameter” below):
3. Submit the valid OTP and change the victim's password. Another problem here is that the user is not alerted in any way that their password has been changed (e.g. via email).
4. Log in with the new credentials.
5. Send an invalid OTP to get the valid OTP back (see the “Code Value parameter” below):
6. Log in with a valid OTP. The attacker is now logged in as the victim.
The main risk is that anyone can take over high-privilege accounts belonging to the client's application.
The example mentioned above is a business logic flaw hidden in plain sight. Despite that the purpose was to provide an extra layer of security, this feature actually helped the attacker compromise any user account, as long as they had a list of valid usernames, which a bad actor could find using OSINT techniques.
2. Privilege escalation via cookie manipulation
Here’s another type of business logic vulnerability that leads to privilege escalation.
In this use case, the web application supports 2 user roles: admin and user. The session cookies are URL encoded and they have a JSON structure where you can see the usertype parameter either set to “user” (for regular users) or set to “admin” (for administrator accounts).
Logged in as a regular user, you get access to a certain number of menus as described in the screenshot below (Customers, RMA, Files, Product, Quotes, Orders, Upload, and Profile):
After simply changing the usertype from user to admin, you suddenly find many extra options such as: Advance Report, Tax Exemption, Users, and Settings. As a result, we’ve elevated our privileges and gained user management capabilities.
Again, the main risk here is that any regular user may escalate their privileges by simply manipulating a single parameter within their session cookies.
This vulnerability could not be found by an automated scanner. This is why we urge businesses to engage offensive security pros for regular penetration tests because they’re the only ones who can identify these logic flaws, especially when it comes to web applications with several user roles in scope.
3. Broken Access Control through UI and API manipulation
Another application logic flaw we discovered during our pentest engagements is broken access control, where the attacker manipulates front-end limitations. These limitations are not further checked in the backend server, so regular users can perform administrative actions such as adding new users to the vulnerable web application.
Logged in as a read-only user, we notice that, under the “User Management” menu, the “Add User” button is disabled.
If you inspect the object and remove the “disabled” button’s attribute, the Add User form pops up:
In the backend, the request is the following:
Since the read-only user’s permissions are not validated, the new user is successfully added.
Usually, the web application can deny this action and allow it for admin user roles only.
In this case, the risk is that low-privileged users can perform actions, which only admin roles or users with user management privileges should be able to do. In terms of impact, such flaws might bring inconsistencies to users’ databases, allowing non-authorized actors to modify these DBs.
To prevent such a vulnerability, the web application should perform extra backend verifications and make sure that all the user’s attributes are consistent with the action it tries to perform. In our case, the read-only permission should not allow us to create a new user.
How to report business logic vulnerabilities to stand out as a pentester
The purpose of business logic is to enforce rules and restrictions in an application. This designed flow of actions is how the application reacts to the user input.
Let’s consider an ATM (automated teller machine) and a customer who wants to withdraw $100 from their personal account. To do this, they need to go through several security checks:
Does the customer have the right PIN code?
Does the balance cover the amount?
When considering logic errors in business applications, there are some key questions worth pondering:
What happens if the customer enters a random PIN code, and the transaction is still allowed?
Or if the customer asks for $100 and the ATM releases $500 instead (assuming the bill drawers have been misplaced)?
What other unexpected user actions can trigger the application to malfunction?
If organizations don’t recognize these as attack vectors, bad actors certainly do.
Logic-based vulnerabilities are complex and each application has its particularities, so, usually, you won’t find two applications with the same business logic flaw. That’s why full automation isn’t the right approach to detect and exploit these loopholes.
You need human perspective and expertise to identify, evaluate, and exploit these vulnerable entry points which are specific to the target’s context.
Penetration testers and bug bounty hunters come into play here because they possess the skills, knowledge, and ethical intent to detect and confirm high-risk vulnerabilities and help security teams or the development team prioritize and fix these flaws.
As offensive security specialists, we strive to deliver outstanding work because we use our know-how and subjective judgment to solve burning business issues. And that’s something full automation can’t do.
So here are 3 principles pentesters like us need to keep in mind when looking for business logic flaws:
Understand the purpose of the web application you test in-depth, along with how the users interact with it and what rights you need to perform specific actions.
Constantly ask yourself: am I allowed to perform this action? What if…? Do not set limits and always challenge your status quo.
Act like there is no obstacle in doing things to better know the target. In most cases, an error message is just a flag for a protection mechanism you can potentially bypass, which could be used in a business logic attack.
These principles can help identify less obvious cybersecurity vulnerabilities which, in the hands of an actor with malicious goals, can wreak havoc.
5 ways to prevent business logic flaws in your web apps
Design web applications with security in mind right from the beginning.
Use secure coding best practices when developing web apps.
Follow security testing methodologies and checklists when doing internal assessments (such as OWASP Top 10).
Make sure your application has a well-defined, maintained, and enforced matrix with all user roles and permissions and that all requests are validated in the backend, based on these users’ permissions.
Engage offensive security professionals to do regular penetration tests in the early stages, even before deploying the application to production.
Beyond the basics: what these pentest engagements taught us
After years of doing penetration tests for different customers, we learned that companies don’t always pay attention to business logic flaws. Our goal is to help them understand the risks and support them to enhance their web application security.
Using our hands-on experience combined with the hacker’s mindset and analytical thinking, we can assess the potential business impact of these types of loopholes and help CISOs and business decision-owners prioritize critical assets.
We hope this guide helps you incorporate tactics to search for business logic vulnerabilities in your security testing projects. If you’re interested in a particular example, we’d love to find out and add it to this list!
To wrap up, a reminder for executives: malicious hackers don’t play by your business rules. That’s why you need someone who does the same, but to help instead of hurting your organization.
