Issue 127: Hidden OAuth attack vectors, Methodology for BOLA/IDOR 🗝️

Even authentication APIs may lead to direct remote code execution attacks (RCE).

Unit42 research team found an API flaw among the vulnerabilities actively exploited by a variant of the Mirai malware in the Internet of Things (IoT) devices. The vulnerability in question is  CVE-2021-22502 in Micro Focus Operation Bridge Reporter (OBR).

Quoting the report:

“The exploit works due to the unsanitized use of the “username” and “password” parameters in requests made to the LogonResource API. The vulnerability can be exploited to allow unauthenticated RCE as root on the OBR server.”

This is a reminder that any API inputs need to be strictly defined and enforced. For strings, that would mean using strict regular expressions and rejecting any calls that send parameters with unexpected characters.

OAuth and OpenID Connect (OIDC) remain key protocols for delegated access and authentication of many modern REST APIs.

Michael Stepankin posted a report on three hidden attack vectors on OAuth/OIDC – each with an example that he found in a real-life implementation.

1. Dynamic Client Registration – SSRF by design

This potential vulnerability stems from the protocol’s ability to register new clients. While some OAuth/OIDC implementations have client information in the local OAuth server configuration, others expose an endpoint to add new clients (for example, /register.)

Some of the OAuth client parameters are URLs. Attackers can try to set these to point to their malicious resources. Parameters used by the OAuth server itself can open it up to a Server-side request forgery (SSRF): logo_uri, sector_identifier_uri, jwks_uri, request_uris. A successful attack would supply a link to malicious content in one of these parameters with the hope of the server retrieving and executing this malicious content.

Even if the server does not execute the content directly, it might still send the content to the client: for example, include the content from logo_uri on the web pages. If no proper validation is done – this may lead to Cross-Site Scripting (XSS) attacks.

2. “redirect_uri” Session Poisoning

When an OAuth authorization request comes in, the server needs to validate the request parameters, authenticate the user, ask for the user’s consent, and redirect back to the external party.

These steps are often implemented in separate controllers passing the parameters in the session. Attackers can exploit the behavior by crafting a page that would post authorization requests for a “trusted” and then immediately for an “untrustworthy” client. That second request would replace the redirect_url value in the session and thus cause the token to get leaked to the URL supplied by the attacker.

3. “/.well-known/webfinger” makes all user names well-known

This is the OpenID endpoint that can be used to obtain information about a user or a resource.

The request has a resource parameter which itself is a URL containing the name of the user:

/.well-known/webfinger?resource=http://user&rel=http://x/user&rel=http://openid.net/specs/connect/1.0/issuer

This potentially exposes the OAuth server to SQL or LDAP injections when the server parses the request and performs the lookup.

Broken Object-Level Authorization (BOLA, also known as Insecure Direct Object Reference or IDOR) is one of the most dangerous and frequently found API vulnerabilities. It happens when API calls include an identifier of a resource and the API grants access to that resource without checking caller permissions.

Max Corbridge published a great article on the methodology for finding BOLA/IDOR vulnerabilities:

• Determine whether the resource being referenced is public (not a big deal) or private (should not be accessible).
• Find patterns in API route naming to discover new endpoints.
• Try adding IDs even to requests that don’t have them.
• Try replacing parameter names.
• Supply multiple values for the same parameter.
• Try different operations (HTTP verbs) on the same path.
• Try changing the request’s content type.
• Try using numeric instead of non-numeric IDs.
• Sites allowing to save credit cards or adding users (e.g., to chats) often have IDOR.
• Try changing the requested file types.
• APIs often implement a CRUD (create/read/update/delete) approach to resources, so try them all.
• Try using arrays instead of regular values.
• Try wildcards instead of values (e.g. *).
• See if error messages leak data.

And so on. Max provides useful explanations and examples for each of the tips – so definitely worth checking out.

Standards are making APIs safer. They enable a consistent approach to API security across different tools and stages of the API lifecycle: from design to development, testing, runtime protection, and monitoring.

Phuong Pham and Mark Boyd looked at the banking sector and found rapid adoption of the OpenAPI Specification standard in the industry:

• Globally, 75% of all open banking platforms design their APIs by using an OpenAPI Specification
• In Q4 2020, the use of OAS grew by 68% over adoption levels in Q3 2020.

They also found that the adoption differs across regions. Parts of the globe where Open Banking regulations have a long history (such as the UK and Europe) demonstrate wider adoption of the standard: