Words in advance
This article introduces our research on a method named BOLABuster, which uses large language models (LLM) to detect object-level authorization damage (BOLA) vulnerabilities. Through large-scale automated BOLA detection, we will achieve encouraging results in identifying these vulnerabilities in open-source projects.
BOLA is a widely existing and potentially very serious vulnerability in modern APIs and web applications. Although manually exploiting BOLA vulnerabilities is usually simple, automatically identifying new BOLA is difficult for the following reasons:
1. The complexity of application logic;
2. The diversity of input parameters;
3. The state characteristics of modern web applications;
Due to these reasons, traditional methods such as fuzz testing and static analysis are unable to effectively detect BOLA, making manual detection the standard approach.
To address these challenges, we utilize the reasoning and generation functions of LLM to automatically execute tasks that were traditionally completed manually. These tasks include:
1. Understand the application logic;
2. Identify endpoint dependencies;
3. Generate test cases and explain the test results;
By combining LLM with heuristic methods, our approach can achieve large-scale automatic BOLA detection. Although our research is still in the early stages, we have already successfully discovered many BOLA vulnerabilities in both internal and open-source projects, including the following vulnerabilities:
1. Grafana (CVE-2024-1313)
2. Harbor (CVE-2024-22278)
3. Easy!Appointments (CVE-2023-3285 to CVE-2023-3290 and CVE-2023-38047 to CVE-2023-38055);
Challenges of Automated BOLA Detection
As previously revealed by research, BOLA occurs when the backend of an API application is unable to verify whether a user has the correct permissions to access, modify, or delete an object.
The following demonstrates a simple BOLA example. In this medical application, patients can use the following API to access their doctor's visit records:
api.clinic[.]site/get_history?visit_id=XXXX
Each patient can only access their own medical records. However, if the server fails to correctly verify this logic, malicious patients may manipulate the visit_id parameter in the request to access data of other patients. The following figure shows this type of operation in a malicious API call:
Although the concept of BOLA is simple, automating detection faces huge challenges. Unlike other common vulnerabilities (such as SQL injection, cross-site scripting (XSS), and buffer overflow), security testing tools such as Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are not effective in identifying BOLA. These tools rely on known vulnerability patterns and behaviors, which do not apply to BOLA. There are currently no automated tools available for detecting BOLA.
Additionally, there is no development framework that can help developers prevent BOLA. Therefore, security teams that need to audit BOLA must manually review applications and create custom test cases. Some technical challenges have exacerbated the difficulty of automating BOLA detection:
1. Complex Authorization Mechanisms: Modern API applications often have complex authorization mechanisms involving multiple roles, resource types, and operations. This complexity makes it difficult for auditors to determine which operations users should be allowed to perform on specific resources.
2. Stateful Attributes: Most modern web applications are stateful, meaning each API call can change the application's state and affect the results of other API calls. In other words, the response of calling an API endpoint depends on the execution results of other API endpoints. This complex logic is typically embedded within the web interface to guide end users in interacting correctly with the application. However, it is not easy to reverse-engineer logic from API specifications and track the application's state automatically.
3. Lack of Vulnerability Indicators: BOLA is a logical error without a known pattern that compilers or SAST tools can identify. At runtime, BOLA does not trigger any errors or exhibit specific behaviors that reveal the problem. Successful exploitation of inputs and outputs usually results in a successful request with a status code of 200, and they do not contain any suspicious payloads, making it difficult to discover vulnerabilities.
4. Contextual Input: BOLA testing involves manipulating input parameters of API endpoints to identify vulnerabilities. This process requires precise location of parameters referencing sensitive data and providing valid values to run the test. We are entirely dependent on API specifications to understand the functionality and parameters of each endpoint, making it difficult to determine if an endpoint will leak or manipulate sensitive data. Once the target endpoint and its parameters are determined, the next step is to send requests to these endpoints and observe their behavior. It is difficult to determine specific parameter values for testing, as only values mapped to existing objects in the system can trigger BOLA. Automatically generating such valid payloads using traditional fuzz testing techniques is both challenging and ineffective.
BOLABuster: AI-assisted BOLA Detection
Given the latest advancements in generative artificial intelligence (Gen-AI) and the challenges of automating BOLA detection, we have decided to address the AI problem by developing BOLABuster. The BOLABuster method utilizes the reasoning capabilities of LLMs to understand API applications and automatically execute previously manual and time-consuming BOLA detection tasks.
The algorithm of BOLABuster is shown as follows, which only requires the API specification of the target API application as input. BOLABuster generates all test cases based on the API specification, and BOLABuster currently supports OpenAPI specification 3, which is the most widely adopted API specification format:
The five main stages involved in the BOLABuster method
Identify potential vulnerable endpoints (PVE)
The first stage of our methodology is to identify API endpoints that may be vulnerable to BOLA attacks. We focus on authenticated endpoints that have input parameters that uniquely identify data objects in the system, such as username, email, teamId, invoiceId, and visitId. If the backend cannot verify the authorization logic, endpoints with these parameters may be vulnerable to BOLA attacks.
AI can assist in analyzing the functions and parameters of each endpoint to determine which endpoints reference or return sensitive data. The following figure shows a set of endpoints that may be vulnerable:
Discover endpoint dependencies
This stage analyzes the application logic to discover dependency relationships between API endpoints. Due to the state characteristics of modern web applications, it is crucial to understand the prerequisites of API endpoints before testing. For example, to test the checkout API of a shopping cart application, you must first add items to the shopping cart. This operation requires knowledge of itemId and customerId.
We will classify endpoints that output the required parameters for other endpoints as producers, and classify endpoints that consume these parameters as consumers, as shown in the following figure. Each endpoint can act as both a producer and a consumer at the same time. AI assists in analyzing the functions and parameters of each endpoint to determine whether one endpoint can output the value required by another endpoint:
Generate execution paths and test plans
This stage uses the outputs of the first two stages to build dependency trees for each PVE. Each node represents an API endpoint, and each edge from a parent node to a child node represents a dependency relationship, where the parent node is the consumer and the child node is the producer. The root of each dependency tree is a PVE, and the path from each leaf node to the root represents an execution path that can reach the PVE. Then, we create a test plan for each execution path, which consists of all the execution paths of the PVEs and their API calls. The following figure shows an example of a dependency tree with four execution paths:
Create test scripts
In this phase, LLM converts each execution path into an executable bash script. Each script performs a series of API calls on the target server, starting from logging in to retrieve the authentication token and ending with calling PVE. Each test script involves at least two authenticated users, one of whom attempts to access or manipulate the data of the other user. If a user can successfully access or manipulate another user's data, it indicates the presence of a BOLA. The following diagram demonstrates an advanced example of BOLA testing, involving two users Alice and Bob, who log into the system and receive unique authentication tokens. Alice created an article in the system and commented on it. The identifiers of the article and comment are then passed to Bob. Bob then attempts unauthorized operations - trying to delete Alice's comment. If the operation is successful, it indicates the presence of a potential BOLA:
Execution plan and analysis
At this stage, BOLABuster executes test scripts on the target API server and then analyzes the responses to determine whether PVE is vulnerable to BOLA attacks. We automate the user registration, user login, and token refresh processes to ensure that each test plan is executed uninterrupted.
BOLABuster runs the same PVE test cases in a specific order to minimize their dependencies on each other. For example, we avoid allowing one test case to delete an object required by another test case.
Essentially, we ensure that all API calls except those to PVE are successful within the execution path. The result of this call should indicate whether PVE is vulnerable to BOLA attacks.
Sorting algorithms ensure that necessary data is filled before any access attempts are made by the application. BOLABuster schedules test scripts that include operations such as updating or deleting users or resources at the end of the execution sequence to prevent attempts to access deleted or modified resources.
The logs and outputs of each test plan are analyzed by AI. When AI identifies a vulnerability in an endpoint, humans verify the results to assess the impact of PVE in the application environment.
Although we use artificial intelligence to automate as many tasks as possible, manual verification is still indispensable. Our experiments show that human feedback can continuously improve the accuracy and reliability of artificial intelligence.
Summary
Our research shows that artificial intelligence has great potential in fundamentally changing vulnerability detection and security research. By utilizing LLM to automatically perform tasks that were previously manual and time-consuming, we have demonstrated that artificial intelligence can act as a reliable assistant. This is not only applicable to coding but also to debugging and identifying vulnerabilities.
Although our research is still in the early stages, its impact is profound. The algorithms we developed for BOLA detection can be extended to identify other types of vulnerabilities, opening up new paths for vulnerability research. With the continuous development of artificial intelligence technology, we expect similar methods to make a series of previously impractical or impossible security research programs possible.
It is worth noting that this technology may be a double-edged sword. While defenders can use artificial intelligence to enhance their security measures, adversaries can exploit the same technology to discover zero-day vulnerabilities and escalate their cyber attacks more quickly.
The concept of using artificial intelligence to combat artificial intelligence has never been more important, as we strive to use more intelligent and precise artificial intelligence to drive solutions to defeat our opponents. The cybersecurity community must remain vigilant and proactively develop strategies to address the potential threats brought by artificial intelligence.
References
https://grafana.com/security/security-advisories/cve-2024-1313/
https://nvd.nist.gov/vuln/detail/CVE-2024-22278
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-3285
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-3290
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-38047
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-38055
https://unit42.paloaltonetworks.com/new-bola-vulnerability-grafana/
https://unit42.paloaltonetworks.com/bola-vulnerability-impacts-container-registry-harbor/
https://unit42.paloaltonetworks.com/bola-vulnerabilities-easyappointments/
Reference link
https://unit42.paloaltonetworks.com/automated-bola-detection-and-ai/
评论已关闭