API8:2023 Security Misconfiguration

Potential Impact of Security Misconfigurations

Attackers can exploit security misconfigurations to gain knowledge of the application and API components during their reconnaissance phase. Detailed errors, such as stack trace errors, can expose sensitive user data and system details that can aid an attacker during their reconnaissance phase to find exploitable technology, including outdated or misconfigured web and application servers. Attackers also exploit misconfigurations to pivot their attacks against APIs, such as in the case of an authentication bypass resulting from misconfigured access control mechanisms.

The many ways in which cybercriminals can exploit security misconfigurations to compromise API security explain why they’ve been listed in the OWASP API Security Top 10 both in 2019 and 2023.

Many automated tools can detect and exploit common or known misconfigurations such as unnecessary services or legacy options, though where you detect them in the technology stack varies greatly. Commonly used vulnerability scanners may only scan a running server for known vulnerabilities and misconfigurations in published software, usually in the form of CVE IDs.  However, these scanners don’t provide the full picture, since security misconfigurations can exist in underlying code, in third-party dependencies, or in integrations with other enterprise architecture. As a result, organizations will often employ a barrage of security testing tooling in build pipelines to catch as many misconfigurations as possible prior to production deployment.

There are certainly cases where security misconfiguration can be the result of something basic like a missing patch, but some misconfigurations are far stealthier and can be obscured by complex architectures.

What Does a Security Misconfiguration Look Like?

In the example above, the attacker modified the connectionId parameter of the GET request to an API,  causing the application server to respond with a detailed exception error with stack trace information. This type of error can include information about the application environment, such as software vendor names, software packages used, software versions, and lines of code within the backend server-side code that the error resulted from.  All of this information is invaluable to an attacker who is performing reconnaissance in order to gain an understanding of the infrastructure that serves applications and APIs, as well as the application code itself, in order to discover other exploitable vulnerabilities.

Real-World Example: The Capital One Cloud Misconfiguration Breach

The Capital One breach in 2019 was a chained attack that was the result of several issues, the primary vector being a misconfigured WAF. According to some media reports, Capital One was likely using ModSecurity, an open-source WAF, to protect certain Capital One web applications and APIs. The WAF was not appropriately configured or tuned for Capital One’s AWS environment and was overly permissive. As a result, an attacker was able to bypass the WAF’s content inspection and message filtering using a well-crafted injection that targeted the backend AWS cloud metadata service.

Harvesting metadata typically only available to running workloads, the attacker was able to pivot their attack and compromise other systems within the AWS cloud environment. This is commonly referred to as a server side request forgery attack.

Why Existing Tools Fail to Protect You Against Security Misconfigurations

Traditional security controls like WAFs and API gateways are not able to identify the modification to the connectionId parameter in the example above since it does not match a pattern of a typical attack. These tools also lack the context to know that the modified connectionId parameter does not match typical usage for this parameter or that it would result in an application server error and therefore would miss this attack.  

WAFs and API gateways would also not provide alerts on the excessive data sent in the API response, since these traditional security controls lack context about this information to know that data is potentially sensitive and should not be returned in error messages. It’s also not uncommon for traditional security controls to only check client requests to APIs, or inbound traffic, and not the server response back to the client, or outbound traffic.

How to Protect APIs Against Security Misconfiguration Vulnerabilities

An API security solution must be able to identify misconfigurations and security gaps for any given API and its serving infrastructure. It must suggest remediation steps when manipulation attempts are made, and the application server itself is not configured to reject the request or mask sensitive data in the response.

To identify excessive data and sensitive data sent in error messages, API security tools must be able to analyze all API activity and establish a baseline of typical API activity.  They also need to be able to identify the early activity of an attacker who is performing reconnaissance in order to look for security misconfigurations and learn more about the API structure and the business logic behind it.

Early detection can prevent a security incident from becoming a security breach, by enabling you to catch malicious behavior early on in the reconnaissance phase and stop it before an attacker is able to successfully exfiltrate data or compromise your systems.

To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.