How BOLA Leads to Enumeration and ATO Attacks

Imagine it’s a Friday night and you are out with your friends to the club. At the door, the bouncer asks you for your ID and lets all of you in. You go to the bar and order some drinks – it’s a busy bar, so the bartender gives you a receipt with the number 30 on it to identify your order. After a while you are called to the bar, and you present your receipt, and the bartender hands you your drinks. You come back for a second round, and your friend decides it’s time to have some fun – they change the 0 on the paper to a 6. You go to the bar, present your receipt again, and to your surprise there is an order number 36. The bartender hands you a bunch of free drinks and bam! The party is turned up a notch.

The above story is an apt analogy for two application security concepts: authentication and authorization. Authentication is “Who am I?” and authorization, also referred to as access control is used to determine “What I can do?” The bouncer lets you in after looking at your ID, which is you being authenticated to the system (aka the club). Later, when you manipulate the receipt from the bar, you are modifying the bars’ authorization (what drinks you receive based on what you purchased). Security systems operate no differently.

In simple terms Broken Object Level Authentication can be defined as an authentication coding error that allows a rogue user to access objects that they should not have access to through manipulation of the object IDs. Broken Object Level Authentication (BOLA) gives attackers access to data they should not have and as such, ranks as the #1 threat in the OWASP Top 10 lists for both Web Application and API Security.

Broken Object Level Authentication and Enumeration Attacks

Most of the applications these days represent their resources in the form of a JSON, let’s say for example a telecom company has an API endpoint that stores information tied to a phone number in the following JSON format with corresponding details:

• phoneNumber: {”5857658402”}
• emailAddress: {”mattjones@yahoo.com”}
• firstName: {”matt”}
• SSN: {”885-383-9193”}
• isLinePortable: {”True”}
• physicalAddress: {”1 Memorial Drive, Rochester, New York”}

The API call related to accessing the information tied to the phoneNumber looks like this:

• GET /user/account-details/phoneNumber:{phoneNumber}

Each user will have details tied to their very own phone number which is the phoneNumber field in this case. The URL for an endpoint like this would be:

• mytelecom.com/user/account-details/phoneNumber:5857658402

There are many objects present in the JSON example above that a user can query. Let’s envision a scenario where a user visits the telecom website wanting to understand if their phone number is eligible for portability to their potential new carrier. Let’s assume the telecom API has strong authentication controls and only lets the user go through with this request if they authenticate themselves to the application. The application has deployed a 2FA following best security practices. Therefore, the user creates an account with their phone number, which then gets verified by the application through a One-Time-Password (OTP) and they are authenticated to the application. Now the user makes a series of calls to the API in order to update their information once authenticated:

• POST /user/account-details/emailAddress:{emailAddress}
• POST /user/account-details/firstName:{firstName}
• POST /user/account-details/SSN:{SSN}
• POST /user/account-details/physicalAddress:{physicalAddress}

There are multiple object IDs present which are linked to various objects. The most important question to answer here is which object IDs are protected by user access control mechanisms. This uncertainty is precisely where the attacker comes in and tries to leverage the cracks in architectural practices. The attacker sniffs the traffic between the web application and the API and finds the following call we discussed earlier:

• GET /user/account-details/phoneNumber:5857658402

The attacker then tries to change (enumerate) the phone number in the next call it makes to the API to 5857675959 and makes the following call:

• GET /user/account-details/phoneNumber:5857675959

The attacker then realizes the API responds with all the PII tied to the phone number mentioned above, including the email address, SSN, firstName, physicalAddress etc. This is an example of strong authentication but poorly implemented authorization. The user (attacker in this case) is allowed to specify the ID of any object they want to access, and the details are returned regardless.

Enumeration Leads to ATO

The motivated attacker then writes a script that iterates (enumerates) through a series of phone numbers, making the same API call over and over again. This allows the attacker to discover all the confidential information of the users by manipulating the IDs. We live in the information age – information is power – any phone number that responds with valid data represents a user whose personal information is leaked.

With the help of PII obtained via the BOLA vulnerability, the attacker can now easily execute an ATO against financial services, retail, telecom/mobile device user accounts. An extreme use of the BOLA vulnerability is a SIM swapping attack to acknowledge all the 2FA requests to further maintain persistence within victim accounts. The practice of displaying object IDs is feasible and generally acceptable in cases where the information on the website is open for public consumption as is the case for news articles: https://newyorktimes.com/news/919. You would likely get lucky and access another news article by changing the ID in the URI to https://newyorktimes.com/news/921.

But there is no proprietary information that represents a business risk if leaked. If the IDs are public facing, certain authorization checks need to be implemented where the application checks each client request if it is authorized to access the object ID it is willing to access. Code reviews can then be implemented to ensure authorization checks are in place where needed.

When a developer facilitates proper access control and authorization checks, vulnerable endpoints can be fixed by defining which users can access which object IDs. Finally, even the best code hygiene process may not find every vulnerability before an attacker does. Proper API security tools are critical for finding authorization and authentication coding errors before they are published while detecting anomalous behavior indicative of a BOLA vulnerability exploit – enumeration, ATO, content scraping.

Image 1: Breakdown of malicious traffic associated with BOLA vulnerability.

In an average week, the Cequence API Security Platform blocks roughly 11 million ATO attempts that are exploits of the Broken Object Level Authorization vulnerability. The attacks are commonly sourced from known Bulletproof Proxy vendors and target all industries as shown in the image.

Level Up Your API Security with Cequence

Schedule a personalized demo to see how Cequence can protect your APIs from ATOs and enumeration attacks that may be the caused by the BOLA vulnerability.