APIsecurity.io - APISecurity.io Newsletter: Issue 149

Cisco Systems has released a total of six security patches for API vulnerabilities this week. The patches were related to their high-end networking equipment, as detailed in this article from Threatpost. The most serious of these was rated as critical with a severity of 9.1 and allowed possible overwrite of the target filesystem. The vulnerability is detailed in NIST CVE-2021-1577 as well as by Cisco themselves.

Cisco provides no details of the vulnerability, or how it was discovered. The vulnerability originated in improper access control in the device Application Policy Infrastructure Controller (APIC) API, which could allow an unauthenticated remote attacker to read or write arbitrary files on the target system. An attacker with sufficient knowledge of the target system could use this ability to exploit the target, up to and including even the possibility of re-writing the device firmware if this was not protected adequately.

The lessons learned here are:

• This is an example of API2:2019 Broken Authentication — ensure that all API endpoints are protected.
• The ability to manipulate a target filesystem is dangerous at the best of times, but for an embedded system this can lead to the compromised control and full takeover of the target.

In a wonderfully written blog post, Robert Heaton reveals how a combination of API vulnerabilities and poor backend design decisions allowed an attacker to determine the precise location of a user of the app. The exploit is definitely non-trivial but Heaton humorously describes it in great detail.  This discovery led to a $2000 bounty for him and the introduction of platform restrictions to mitigate future attacks.

The exploit relies on a technique called trilateration which allows a precise location to be determined if three other locations are known with sufficient precision. This is best illustrated by this diagram:

Heaton had previously described this technique relating to the Tinder app, which was subsequently mitigated by performing distance calculations on the server rather that relaying high-precision information to the client. Keeping user’s exact locations secret is relatively easy to get wrong — as Heaton puts it: “As one of the trailblazers of location-based online dating, Tinder was inevitably also one of the trailblazers of location-based security vulnerabilities.” 

Obviously, the location of the target cannot be manipulated by the attacker. However, the attacker is able to fake their own location, and by using a poorly implemented API endpoint, then determine three different distances to the target. What Tinder had already fixed, but Bumble had not, was the rounding of distances, so that the accuracy of trilateration was not precise enough to allow pinpointing the exact location of a user.

The exploit was possible by two additional weaknesses in the API implementation on the Bumble backend:

• It was possible to use an unprotected API to generate the beeline view to determine the target’s location without actually being in their their “feed”.
• The API endpoint relied on an MD5 hash to protect payload manipulation but performed the calculation on the client-side, making it easily reverse-engineered.

Bumble has since fixed the issues. The lessons learned here are:

• Never rely on obfuscation or client-side protections to secure an API endpoint — Bumble was found lacking on both counts here.
• It was possible to access random users’ profile information without being in their feed — another case of BOLA.

If all this sounds somewhat familiar to our regular readers, similar vulnerabilities in Bumble were already discussed in our issue 110. Looks like the fixes done at that time left room for improvement.

Security Boulevard featured the impact of the adoption of a Zero Trust model toward securing APIs. The same topic was covered in further detail by Forrester in this article.

The principle of Zero Trust is as simple as the name implies: in an environment where the network boundary has largely been eliminated and where all devices are untrusted, it is vital that software is designed to authenticate and authorize all access to all systems, continuously. Assume the network and devices are hostile at all times.

From an API perspective, this means dispelling the concept of internal-only APIs: all APIs should be considered to either be externally facing, either already or in the future. All APIs should be regarded as first-class citizens and fully protected with adequate authentication and authorization controls. Security Boulevard concludes by suggesting the following high-level approach:

• Understand your API inventory: who has access, and at what level.
• Utilize Role-Based Access Control (RBAC) to eliminate unnecessary access.
• Enforce the principle of least privilege.

Forrester lead with the view that the first step toward securing APIs is to perform an exhaustive inventory of which APIs exist in the organization, and which of those endpoints are secured. This also allows for the discovery of so-called ‘rogue endpoints’  originating from shadow IT practices —  an unquantified risk in an organization. Once an inventory is established, the focus can then move toward an API governance model integrated with the DevOps practice.

To wrap up this week, we have an interview with Jason Kent, hacker-in-residence at Cequence, courtesy of Threat Post. He suggests that the root cause of insecure APIs is the same fundamental issue that has plagued web applications for decades: lack of input validation.

Kent’s experience reveals his top three API vulnerability classes:

• Broken Object Level Authentication (BOLA/IDOR) aka API1:2019: Attackers substitute the ID of their own resource in the API call with an ID of a resource belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource. This attack vector features regularly in this newsletter, a recent high-profile case being the Peloton API breach (and this week’s Bumble).
• Broken User Authentication aka API2:2019:  Poorly implemented API authentication allows attackers to assume other users’ identities.
• Improper Assets Management aka API9:2019: This API flaw results from “insufficient environment segregation and management”, allowing attackers to access under-secured API endpoints. This was discussed earlier in the Zero Trust article — assume all APIs are external facing and secure them adequately.

He recommends organizations start with a training initiative to ensure developers tasked with writing APIs are adequately skilled and aware of the risks. Focusing on the OWASP API Security Top 10 is usually the best place to begin.