Blog: Vulnerability Advisory

Free BrewDog beer with a side order of shareholder PII?

Alan Monie 08 Oct 2021

TL;DR

  • BrewDog exposed the details of over 200,000 ‘Equity for Punks’ shareholders for over 18 months plus many more customers
  • Every mobile app user was given the same hard coded API Bearer Token, rendering request authorisation useless
  • It was therefore trivial for any user to access any other user’s PII, shareholding, bar discount, and more
  • Disclosure was rather fraught. Instead of being ‘cool’ as we had hoped, given their reputation as being a bit counter-culture, BrewDog instead declined to inform their shareholders and asked not to be named. It took 4 failed fixes to properly resolve the problem.
  • It’s public knowledge that BrewDog are considering an IPO. We are concerned for future investors if BrewDog’s wider approach to security and disclosure is this weak.
  • But, best of all, shareholders get a free beer on the 3 days before or after their birthday under the terms of the Equity for Punks scheme. One would simply access an account with the required date of birth, generate the QR code and the beers are on BrewDog!

The detail

To make development easier, mobile applications are built on APIs, then a front end for iOS or Android is designed which calls those API endpoints. APIs are generally protected by some form of authentication – usually a token or key. Bearer Tokens are the most common way of authenticating to APIs protected by OAuth 2.0 and they are passed in the HTTP header like this:

Generally, there is an authentication process where a user submits their credentials, and a bearer token is returned which permits access to the endpoints in the context of that user.

What not to do

Given the sensitivity of these tokens they should only be provided after a successful authentication request. It would be a terrible idea to hard code them into a mobile application! If we look at the source code for the Android BrewDog application, we can see a hard-coded bearer token (in yellow) associated with three API endpoints (in green).

If we append a different customer ID to the end of the API endpoint URL, we are able to access sensitive Personally Identifiable Information (PII) for that customer. The customer IDs aren’t quite sequential, but certainly aren’t random. Several of us at PTP are BrewDog investors, so tried each others customers IDs with permission. We could easily retrieve all of the data that BrewDog was storing about us:

  • Name
  • Date of Birth
  • Email address
  • Gender
  • All previously used delivery addresses
  • Telephone number
  • Number of shares held
  • Shareholder number
  • Bar discount amount
  • Bar discount ID – used to create the QR code
  • Number of referrals
  • Type of beer previously purchased

Many of the data items breached would be considered PII under GDPR definitions and as such, companies have a legal obligation to keep PII data safe and secure. Hard-coding a bearer token into a mobile application which provides authentication to download the PII data of all BrewDog customers and shareholders is not secure!

What could an attacker do?

An attacker could brute force the customer IDs and download the entire database of customers. Not only could this identify shareholders with the largest holdings along with their home address, it could also be used to generate a lifetimes supply of discount QR codes! I have a 10% discount on beers, but I wouldn’t be surprised if other customers have higher discounts, or even free access.

How long has this been there?

We went back to APKpure and retrieved older versions of the BrewDog application. The first use of the hard-coded Bearer token was version 2.5.5 in March 2020 when they moved to React. There have been many releases since then and the latest version is currently version 2.5.11. So, for ~18 months it has been possible to download their customer database anonymously.

Have they been breached? Who knows!

An obvious question is whether the data has been accessed by unauthorised persons. Whilst BrewDog say that they can’t currently see any evidence of that, we’re not quite sure how they would validate this: every request will be coming from a valid account with a valid (but identical!) bearer token. How therefore would they prove that the request was from the valid user and not from persons unknown?

It will need a very thorough forensic investigation to prove for certain that a breach hasn’t occurred.

What did BrewDog do?

It took several days for BrewDog to respond properly, which was a fail in itself. We had to escalate via LinkedIn, as their social media team didn’t know what to do with the report.

After they were made aware of the issue, they finally did the right thing and took down the vulnerable API. However, they didn’t communicate what they had done and why with their customers. Hence, users of the app trying to get their bar discount QR codes at the weekend just saw the spin of death:

They took a LOT of criticism on Twitter, Google and Apple app stores. They didn’t say that they deliberately broke the app because of a security issue. They remained silent. Had they said it was taken down because of a security issue, that might have saved them some public criticism.

BrewDog starts fixing the app… and fails

BrewDog released a version of the app which allowed users to access their QR codes again on the 13th September (version 2.5.12). The release notes said “Background updates to address an issue where users could not log into or access the app”. A shame they didn’t mention ‘security fixes’…

Unfortunately, there was STILL a static key in that version too which allowed an attacker to download the bar discount codes for all users. I let BrewDog know and offered to help test the next version of the app for free.

They added me to their beta programme and pushed version 104 which didn’t show the bar discount or QR codes. Then they sent me version 105 which didn’t work… and 106… nope.

Finally, 107 worked and I let them know on the 23rd September. By the 27th September, version 2.5.13 was released to the app store. By this point I’d tested 6 different builds of their app and gave BrewDog feedback on each version.

‘Nothing too exciting’ indeed. We just fixed a critical data leak, that’s all.

What should BrewDog have done?

It’s really odd that the static bearer token wasn’t spotted before. Functional API testing should have revealed this issue, as would a thorough security review.

These bearer tokens are not the only keys that are present in the BrewDog source code. It doesn’t take much effort to search for “bearer” or “key” and identify hard-coded tokens.

When the API was being designed, did they think they would need a bearer token pre-authentication for some reason? This design decision should have been identified by an internal security team that should have been involved at the start of the project.

Endgame

The vulnerability is fixed. As far as I know, BrewDog have not alerted their customers and shareholders that their personal details were left unprotected on the internet.

I worked with BrewDog for a month and tested six different versions of their app for free. I’m left a bit disappointed by BrewDog both as a customer, a shareholder, and the way they responded to the security disclosure. I need a beer, but I’ve only got BrewDog in the fridge…

For interest, here’s the final exchange we had with BrewDog. It’s worth a read. We explained that we would be writing this issue up, though their tone definitely turned sour when we made it clear that we would be publishing. It’s also worth noting that it took BrewDog quite a while to even thank me for all the effort I put in to helping review their failed fixes. The vulnerability was finally fixed, so unless there are more vulnerabilities that are present that they are aware of but not sharing, there is no reason for us not to publish now. Their extended publication timeline is interesting – I wonder if that would fall the far side of a potential IPO date??

I also love the fact that they try to use ICO mandates as a reason not to inform shareholders, rather than doing the “cool thing” and proactively alerting the people who invested in and supported them:

While we have addressed the vulnerability you identified, our investigation into this has not concluded, nor has our imminent release of the security improvements we informed you of previously. One of the factors in user notification is evidence of a breach as mandated by the ICO. In our initial investigation, we found no evidence in the logs that the vulnerability was exploited or data exposed. We are working with our infrastructure partners to validate this conclusion. Our next phase of security improvements will be implemented over Q4. Any user notification, if appropriate, would happen once the latest improvements are in place to limit further risk to our users.

We are grateful that you informed us of the vulnerability and there is clear benefit in sharing the details of the vulnerability so others may avoid it in future. However, can you please confirm that you will not mention BrewDog by name or the nature of the data in your imminent blog? Doing so over this period would open our users up to increased risk as above for no further benefit to the development community.

BrewDog? BadDog! Come on James (Watt), sort it out.