BOLA stands for Broken Object Level Authorization (BOLA), the top API security issue of the OWASP API Security Top 10. Some say it is similar in spirit to security issues once called Insecure Direct Object Reference (IDOR). As APIs become the predominant application to application communication protocol, there is a steady increase in the frequency of BOLA related data breaches.
Many incidents in the past have also shown that BOLA exploits do not show any consistent patterns that can be recognized by conventional security devices such as a Web Application Firewall or an API Gateway.
The most recent case is the John Deere API data leak (Read Here) that made the news a few days ago. Disclosed by a security researcher known as Sick Code (Read Here), the pair of API bugs are typical BOLA vulnerabilities. One of these vulnerabilities allows anyone who registered for the free John Deere management mobile app to invoke APIs repeatedly to obtain a list of usernames by pretending to check for username conflict.
A second, and potentially more damaging vulnerability allows the query of owner personal information using the VIN number of a John Deere equipment. According to Sick Code, once a valid VIN number is found (VIN numbers are not kept as secrets and apparently quite short and simple), attackers can gain access to information of a large number of owners because VIN numbers seem to be assigned sequentially. This is quite similar to the US Postal Office API BOLA vulnerability which lead to potential leaking of millions of user personal information records (Read Here). Another such BOLA incident was a successful hack of the BlackHat 2018 conference registration service (Read Here). All these vulnerable APIs have 3 things in common:
They are all APIs meant for seemingly simple, innocuous information retrieval.
The data object references were all casually assigned (probably from a database sequence). VIN number of a tractor, conference attendee number, and user recorder ID are not designed to be used as a secure object handle. Yet once exposed via an API for external access, they are subject to abuse.
BOLA exploits are hardly detected as they are business logic errors that are almost impossible to be discovered by security tests. The API calls include parameter values that are indistinguishable from legitimate requests.
One hope for detection of BOLA is runtime monitoring that can adapt to application specific data exchange. Specifically, such monitoring should detect the case when the boundary around data objects belonging to a single login user is crossed. Also, the determination of the boundary should be automated. The CloudVector solution includes BOLA detection. To learn more, contact us.