Issue 148: Microsoft Power Apps breach, BOLA on Topcoder portal, RFC 9101 released, API hacking guide

The big news this week is the data breach at the Microsoft Power Apps platform, leading to the disclosure of up to 38 million records with Personally Identifiable Information (PII). The details range from names and email addresses to COVID-19 vaccination status, and even Social Security numbers. The breach was discovered by researchers at UpGuard, who detail the underlying issue, the entities impacted, and the response from Microsoft in their recent blog.

Researchers discovered that an OData API that Power Apps used for accessing data publicly exposed sensitive user data which should have been private. The access to data is controlled with the setting called table permissions, which can be set to restrict access to sensitive records. Unfortunately, Microsoft had opted to switch off table permissions by default, meaning that they were publicly accessible unless users realized to switch it on. Microsoft did warn users on the impact of leaving this setting off, but as the breach shows, this might not have been the best call:

Upon their discovery, UpGuard notified Microsoft about the issue. The initial response was that this public accessibility was by design, not a vulnerability. Not the first time we see this excuse with reported API vulnerabilities, often dressed up in the guise of “improved user experience”.

UpGuard then proceeded to notify the impacted entities, many of whom took swift action to remove the leaked PII data. To add insult to injury, many core Microsoft portals were also affected, and subsequently Microsoft appears to have notified impacted government cloud customers of the issue.

Since the disclosure of the breach, Microsoft has changed their stance here:

• They have changed the default setting so that new lists enforce table permissions to protect underlying data.
• They have provided a dedicated tool, Portal Checker, for finding OData lists that allow anonymous access.

The lessons learned here include:

• This is a classic example of Broken Authentication on an API — the impact of having unauthenticated APIs can lead to unintended data disclosure. You could also argue that this falls under API7:2019 — Security misconfiguration, too.
• As a developer, always ensure you understand the full impact of your chosen default settings and permissions.
• As a platform designer providing API service, always ensure strict access restriction (deny-by-default, least privilege…). Allowing full anonymous access to data or other resources is not a sensible default, regardless of any warnings that you glue on top.

We’ve previously discussed Microsoft Power Apps causing problems in our issue 138.

In other vulnerability news this week,  we have the write-up and vulnerability disclosure (scoring a bounty for the researcher) on a BOLA vulnerability in Topcoder, a crowdsourcing company with a community of designers, developers, data scientists, and programmers.

BOLA is the number one issue on the OWASP API Security Top 10. Poorly implemented access control allows an attacker to assume the identities of victims and access resources belonging to them by manipulating the object identifier.

The researcher describes the exploit as follows:

1. Create an account on Topcoder.
2. Observe how the property for user IDs — often the likely candidate to modify when looking for vulnerabilities — is used.
3. Enumerate subdomains and confirm the presence of the same user ID.
4. Locate a request (here a POST) without an Authorization header .
5. Replace the user ID with the user ID of another account to get access to the victim’s data.

The lessons learned with this one:

• BOLA is the leading cause of API vulnerability and is often relatively easily exploited, as in this disclosure, so keep your eyes peeled for it.
• API designers need to ensure that all API endpoints are adequately protected with authorization controls. In this instance, a single unprotected API endpoint was all that was necessary to expose user PII.

This week also saw the publication of the OAuth 2.0 JWT-Secured Authorization Request (JAR) specification as RFC 9101. This is another one in the series of RFCs bringing OpenID Connect-defined functionality to OAuth 2.0.

OAuth 2.0  and OpenID Connect are currently considered the most secure methods of authentication and authorization in API security. It comes therefore as no surprise that among other applications, this specification is also used by the OpenID Financial-grade API (FAPI).

Tutorials are always welcome. Luke Stephens (aka hakluke) and Farah Hawaa have teamed up to create a guide on how to hack APIs in 2021.

The guide provides an excellent (and humorous) foundation into the growing need for considering API security right from the start. The advent of Single Page Applications (SPA) driving the proliferation of backend APIs is one important drive for this.

The guide covers, for example:

• The tools used (primarily PostMan)
• The common configuration and use of these tools
• A wide range of API vulnerabilities, with great explanations and sample code snippets and URLs.

Of particular use for players on the defender side are the remediation guides, offering clear and actionable advice for protecting APIs.

Highly recommended for both red and blue teams alike (or whatever color your jersey might be)!