Assessment Report: BOLA Attack on Ghostbank API

Executive Summary

In October 2024 from 22:08:33 to 22:08:37, a series of automated requests were launched against the Ghostbank API, demonstrating a Broken Object Level Access (BOLA) vulnerability. BOLA flaws allow unauthorized access to resources based on user-controlled input. This attack permitted the unauthorized transfer of funds between accounts without necessary authorization checks, leading to potential financial losses and reputational damage for the organization. The attack employed simple HTTP POST requests targeting the /api/v3/transfer endpoint, successfully executing transactions by manipulating the account_from parameter.

Explanation of BOLA Attacks

A Broken Object Level Access (BOLA) vulnerability occurs when an application allows an attacker to access or modify objects without proper authorization, generally due to missing or ineffective access controls. The lack of authorization checks on user input permits attackers to manipulate sensitive data and access resources that should be restricted. BOLA vulnerabilities typically manifest in functionalities that rely on object identifiers, such as account numbers, user IDs, or document IDs. In this case, the Ghostbank API lacked verification to ensure that the user making the request was authorized to access the accounts involved.

Detailed Explanation

During the attack, the following patterns were observed in the 20 requests made against the Ghostbank API:

1. HTTP POST Requests: Each request utilized the HTTP POST method, indicating intent to perform actions that change state on the server (in this case, transferring funds).

2. Endpoint Targeted: All requests were directed at the /api/v3/transfer endpoint, with the same common structure and headers. The User-Agent header was consistently the same, suggesting the use of automated tools for the attack.

3. Manipulated Parameters: The crucial part of each request was the account_from parameter that was manipulated to different account numbers, seemingly repeated to verify access to accounts that did not belong to the authenticated user. The account_to parameter remained constant, indicating funds were redirected to a single account.

4. Successful Transactions: All requests received a successful HTTP 200 OK response with a JSON payload confirming the transaction. The consistent success status demonstrates a lack of verification of access rights for the specified accounts, leading to unauthorized transactions.

Given the successful execution of these requests, the BOLA vulnerability allows legitimate users to exploit their access as a means to interact with accounts that do not belong to them, significantly affecting the security and integrity of user accounts and the overall application.

Remediation Guidance

To address and mitigate the assessed vulnerabilities, the following actions are recommended:

Code and Logic Improvements:

1. Implement Access Control Checks: Ensure that all sensitive operations, particularly those affecting user account balances, have strong authorization logic. Validate that the active user is authorized to perform actions on the resource identified by account_from.

2. Use Object-Level Security Policies: Enforce policies that regulate which users can access which resources based on their roles. Consider implementing Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) methodologies to define clearer permissions.

3. Input Validation: Always validate user input in controller logic to ensure it corresponds with established user permissions. Ensure that parameters correspond to the user's assigned resources and not allow arbitrary access based on user input.

4. Audit Logs: Implement logging of all transactional requests, including the user ID executing the request, to enhance traceability and accountability for unauthorized actions.

Web Application Firewall (WAF) Measures:

1. Rate Limiting: Configure rate-limiting rules to restrict the number of requests an individual user can make over a given timeframe, preventing automated attacks.

2. Payload Inspection: Deploy context-aware security rules that inspect incoming traffic for suspicious patterns indicating parameter manipulation or unauthorized access attempts.

3. Blocking Known User-Agent Strings: If identified as part of an attack methodology, consider temporarily blocking requests from specific user-agent strings often employed by attackers.

These measures should significantly reduce the risk of BOLA vulnerabilities and enhance the security posture of the Ghostbank API, better protecting user accounts and financial transactions.

Appendix

The Request/Response Listing: