APIsecurity.io - APISecurity.io Newsletter: Issue 155

The big news item this week is the vulnerability in the BrewDog mobile app disclosed by Pen Test Partners. This vulnerability has potentially exposed the personal details of over 200,000 ‘Equity for Punks’ shareholders over the last 18 months. It is currently unclear if the vulnerability has been exploited, but it certainly is not insignificant in its potential impact.

The researchers discovered that the developers of the mobile app had hard-coded API bearer tokens into the application source code. This meant that any user of the application could retrieve information for arbitrary users simply by guessing their user IDs. Worse still was that this information included clearly Personally Identifiable Information (PII) under the GDPR definitions.

When the user is interacting with the mobile app, each call the app makes to consume the API behind it includes a bearer token as part of the authentication process. Typically, these tokens should be short-lived session tokens and unique to each app user. The tokens are usually obtained through an authentication protocol — commonly OAuth2 — following successful authentication. This makes a bearer token a sensitive asset because it represents the user’s delegated identity. As such, it should be safeguarded in the app, and disposed of when a session is ended. Definitely these bearer tokens should never ever be stored in source code of the app, even if they were encrypted.

Remarkably, this is exactly what the researchers discovered when reverse-engineering the BrewDog app, with clear evidence of three hardcoded bearer tokens:

Moreover, by manipulating the user ID in API calls, it was possible to retrieve information about other users, including their PII like name, email, date of birth, addresses, and telephone numbers. There was also a ‘Bar discount ID’ that is used to create QR codes for discounts on beers! Although the user IDs weren’t sequential it would be easy enough for an attacker to brute-force and download the full details for all users. Free beers, everyone!

The response from BrewDog  has been somewhat inadequate: they sought to initially avoid the issue, and then somewhat clumsily removed the vulnerable API which rendered the app somewhat dysfunctional. It took several attempts before the issue was properly remediated, with the release notes slightly ironically stating “nothing too exciting”.

The lessons to be learned here are numerous and important, namely:

• Authentication is a complex process fraught with potential traps. Application developers are advised to use a robust, industry-proven framework, such as OAuth2 ,rather than some woefully inadequate method, like hardcoding the credentials.
• A rudimentary machine search (like using grep) can identify hard-coded bearer credentials in the codebase and ensure they are eliminated before they are committed to a code repository. That they in this case were present as long as they did suggests that app developers were aware of them and relied on wishful thinking that they were never discovered. Attackers are a very clever bunch.
• The ability to enumerate user IDs suggests the BrewDog API was vulnerable to API1:2019 — Broken object level authorization, although this could have been simply the result of broken authentication in the first place.
• Savvy organizations should have an established process for breach management and vulnerability disclosure, something that was clearly lacking in this instance.

Kudos to the researcher Alan Monie on this discovery and write-up — have a beer on us!

This week sees the conferences KubeCon and CloudNativeCon 2021 taking place virtually — as well as in-person again. Of interest to API security practitioners is Cisco’s Vijoy Pandey (VP in Cisco’s Cloud Platform and Solutions Group) announcing a new open-source program called APIClarity. The project aims to address issues relating to API security and observability, namely configuration drifts, zombie (deprecated), and shadow (undocumented) APIs, to name but a few.

APIClarity — available on GitHub — is described as “Wireshark for APIs” and is maintained by Cisco, 42Crunch (read more here), and APIMetrics. A quick overview of the solution is available in this video:

Next, we take a look at API attacks and Open Banking in the second part of a comprehensive report from F5 on reported security incidents at financial organizations.

The most telling statistic here is the increase in the number of incidents that relate to APIs. From 2018 to 2020, only about 6% for incidents were API-related, whilst in 2020 APIs accounted for a whopping of 55% of the incident!

A similarly telling statistic is the fact that the financial sector is far more likely to suffer an API-related incident(a total of 50%) compared to the average of 4% across all industries.

The key takeaways from the report include:

• Open Banking is likely to become increasingly reliant on APIs, and decreasingly reliant on Open Financial Exchange (OFX).
• Two-thirds of API incidents in 2020 were caused by combinations of no authentication, no authorization, or failures in either.
• The combination of the two points above suggests an increasing attack surface for attackers to exploit Open Banking implementations.

Finally, Expedited Security has published an extremely comprehensive and easily consumable mega guide into API security best practices.

This guide should prove invaluable to both novices and experts alike and covers several key topics, such as:

• Distributed Denial of Service (DDoS) attacks
• Data breach attacks
• OWASP Top 10 vulnerabilities
• API security controls
• API authentication and authorization
• Secure API design guidelines
• Security procedures