Exploiting Misconfigurations with Google Identity Platform

There are four things I absolutely love: music, puzzles, lore, counting poorly, and going places I 100% should not be.

On the music front, I’ve lately been super into this band called Milkblood – their music absolutely slaps and they’ve got some fun creepypasta-esque stuff happening in the background.

Milkblood fed into my other passions when they started building an ARG alongside their music, and when they (unintentionally) made a basic website really easy to break into.

For those not in the know, alternate reality games, or ARGs, are games that interact with real life in different areas – most often you need to solve some sort of mystery and will have to visit various locations to do this. These locations might be physical places, or in the case of this post, a website.

So, after some scrolling around on Reddit, I found a site that‘s a part of Milkblood’s ARG – a website related to a company in their fictional universe called “Zeus Advanced Research”. The website looks pretty simple; it’s a logo and a login prompt. When you try to enter any random credentials, you get a simple “Wrong credentials” or ”Something went wrong” message. Now the correct way to go about entering this website is undoubtedly to go to some other locations, find some puzzles, find out the proper credentials, etc. And don’t get me wrong, that’d still be fun – but I couldn’t resist poking the thing in front of me. I mean look at that login, it just screams mystery. And I needed to get in right away.

Something about the message that’s displayed when incorrect credentials are input just rubbed me wrong, and that was what really pushed me to take a deeper look at how the authentication works. So of course, I put on my mandatory ski mask and asked the question “how are they authenticating these credentials?” A quick look at the request being sent shows me this app is going and talking with Google’s Identity Toolkit API, and looking at the URL something immediately jumps out at me:

https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<BIG_STRING_HERE>

Bruh. There’s no way that key is useful for anything... right? I mean that’d just be too silly to have something confidential exposed in a crazy obvious way like that.

“When you use API keys in your applications, ensure that they are kept secure during both storage and transmission."

Well, I guess someone was just a silly goose, huh?

After a quick look at the documentation on API keys, I don’t think I’m supposed to have this, which makes me very happy. Google does go a little further to give solutions to how one should manage an exposed API key, and that’s by adding API key restrictions. By default, API keys are unrestricted – they can be used by anyone from anywhere and shouldn’t be put into production like this. Restrictions would, for instance, look like locking that key to where it can only access the v1/accounts:signInWithPassword endpoint, keeping it from being used in any other API calls.

So, that begs the question: how deep does this misconfiguration go? Did the owner of this website restrict the permissions on their API key? To test this, I threw the request the site made into BurpSuite, and first made sure the basic request was repeatable – which it was.

Cool, let’s review the documentation (it physically hurts to say that), and see if there are any other interesting API calls I can make. What I would love to do is get a list of all accounts in this project – unfortunately, the endpoint to do that doesn’t accept API keys, but rather OAuth2 tokens or credentials. So, I can’t get that information out of this it seems, but I can make use of a different endpoint that does allow API keys: /v1/accounts:signUp

I think you can see where this is going.

I went ahead and used the exposed API key and was able to sign up with a new account to this site.

testattack@test.test was now a valid user, and when I tried it…

*click*

Then I just deleted the account afterwards using the same API key, wrapping it all up.

Wow. That was easy... and possibly illegal... I reached out to Milkblood via Instagram in November of 2022, let them know about the issue, and they confirmed that wasn’t how the ARG was meant to be played. Whoops. At least they know there’s an issue now.

Looking at the situation, it looks like this isn’t a mistake made by the hosting platform. This site is hosted on a platform called Vercel, which allows the user to create a repository with the code for their website on it and the platform will host the site. I spoke with someone from Vercel who confirmed to me that this website was not made from any Vercel template, and was custom made by the author – meaning this mistake isn’t one propagated to other sites, but rather a mistake made by a developer of a single website. That’s good news.

If that site looked cool to you (like it did to me) and you’re curious about Milkblood, I recommend you check them out. Pretty dope band, and I appreciate them putting this ARG on.

Alex Adams