API5:2019 Broken Function Level Authorization
Description
Authorization flaws are often the result of improperly implemented or misconfigured authorization. Implementing adequate authorization mechanisms is a complex task, since modern applications can contain many types of roles, groups, and user hierarchy such as sub-users and users with more than one role. This is further complicated with distributed application architectures and cloud-native design. Broken function level authorization (BFLA) shares some similarity to BOLA in this regard, though the target with BFLA is API functions as opposed to objects that APIs interact with as in the case of BOLA. Attackers will attempt to exploit both vulnerabilities when targeting APIs in order to escalate privileges horizontally or vertically.
Attackers discover these flaws in APIs since API calls are structured and predictable, even in REST designs. This can be done in the absence of API documentation or schema definitions by reverse engineering client-side code and intercepting application traffic. Some API endpoints might also be exposed to regular, non-privileged users making them easier for attackers to discover.
Attackers can exploit these flaws by sending legitimate API requests to an API endpoint that they should not have access to or by intercepting and manipulating API requests originating from client applications. As an example, an attacker could change an HTTP method from GET to PUT. Alternatively, the attacker might also alter a query parameter or message body variable such as changing the string “users” to “admins” in an API request.
Potential Impact
Attackers exploiting broken function level authorization vulnerabilities can gain access to unauthorized resources, take over another user’s account, create/delete accounts, or escalate privileges to gain administrative access.
Example
Real World Example
New Relic Synthetics users can escalate privileges to add or modify alerts
In 2018 Jon Bottarini found that a restricted user could make changes to alerts on Synthetics monitors without the proper permissions to do so. In fact, they could make changes with no permissions at all as a result of the privilege escalation weakness that was present in the product at that time. Exploitation involved submitting a legitimate request to an API endpoint that was otherwise not visible to the restricted user.
As part of his security research, Jon captured traffic of a privileged session using an intercepting proxy tool, Portswigger Burp Suite. In particular, this traffic included a POST request to an API endpoint and function that creates alerts on Synthethics monitors. He found that you could trap a GET request from the non-privileged session, retain the tokens and cookies for that restricted user, and alter the remainder of the trapped request to resemble the privileged POST request. This manipulation of API traffic to access functionality not visible in the UI (at all or to that user and their permissions) is a common technique attackers use to exploit function level authorization weaknesses and escalate privileges.
Why Existing Tools Fail to Protect You
Traditional security controls like WAFs and API gateways lack context of API activity and therefore do not know that the attacker in the example above should not be able to send a DELETE method. This API call would be seen as legitimate and would pass through these security controls. WAFs and API gateways sometimes support explicit, statically defined message filters, often referred to as a positive security approach. However, these approaches can inhibit or break business functionality, and most organizations find them difficult to operationalize at scale. Restricting HTTP methods is also an easier task than restricting API parameters and values, the latter of which requires deeper subject matter expertise on the design of the API.
The activity in the Facebook example above would be missed by WAFs and API gateways for the same reason. These security controls would not know that the 3rd party applications should no longer have access to the deprecated or restricted API functions. Tuning the controls would have required appropriate knowledge transfer between development, operations, and security teams to implement an appropriate static filter in the appropriate proxy within the overall enterprise architecture.
How to Protect Broken Function Level Authorization Vulnerabilities
API security solutions must be able to continuously baseline typical HTTP access patterns per API endpoint and per user. With this baseline, API security solutions can identify calls with unexpected parameters or HTTP methods sent to specific API endpoints such as in the DELETE example above. It is critical that the solution is capable of baselining continuously, as APIs may go through a high rate of change as a result of modern development and release practices. API security solutions must be able to identify and prevent attackers or unauthorized users from accessing administrative level capabilities or unauthorized functionality as in the Facebook example above.
Previous posts:
OWASP API Security Top 10 Explained
API1:2019 Broken Object Level Authorization
API2:2019 Broken User Authentication
API3:2019 Excessive Data Exposure
API4:2019 Lack of Resources & Rate Limiting
Next posts:
API7:2019 Security Misconfiguration
API9:2019 Improper Assets Management
API10:2019 Insufficient Logging & Monitoring
*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Michael Isbitski. Read the original post at: https://salt.security/blog/api5-2019-broken-function-level-authorization
