Listing all registered email addresses on Google’s Crisis Map thanks to IDOR and incremental IDs

The last write-up was about a security vulnerability on Google.org’s Crisis Map, and so is this one. 

In short, Google Crisis Map was quite an old project used for creating and sharing custom maps.
To do that, you need to log in with a Google account first.

Google Accounts login screen

Once you’re logged in, you can create new maps, manage existing maps, or manage your domain settings. Last time we created a new map; this time we will go to the domain settings.

Google Crisis Map Landing Page

There are multiple different domain settings.

Domain settings form

We will be interested in the Members part of the settings. It lists all the email addresses that have some access to your maps. You can invite other people to collaborate with creating and managing the maps.

List of members and permissions

Let’s add another email address as a member of the project.

Form with a new member email address

Once we click Save changes a POST request is sent to the following URL:
https://google.org/crisismap/example.com/.admin
with this body:

Table containing fields for adding a new member

In the request body, there are two important fields – new_user with the email address we want to add, and new_user.permission, which sets the permission level of the new user.

After the request is completed, we can see that the page has been updated with the new information.

List of members with their email addresses

We’ll take a look at how it looks like in the HTML:

HTML code of the list of members

We can see two important things in this part of the code. The email address and a number (123456) appearing twice in the name fields of the inputs. The number looks particularly interesting because it’s only a few digits long and appears to be associated with the new user’s email address.

Let’s try sending this form one more time and take a look at the request body.

Table containing fields with information about current members

It’s quite similar to the last request, except now instead of new_user there is a new item 123456.permission with the permission value.

This suggests that the member’s permissions are referenced not with an email address, but with an ID.

However, when we open the Members page, we can see the members are listed there with their email addresses.

List of members with their email addresses

So what would happen if we instead of 123456.permission send some different ID, for example 123457.permission?

Turns out we added a user with the ID 123457 as a member to our project. If we open the Members page once again, we can see this user is added to the members list, including their email address.

List of members with their email addresses, containing a different new member

This means just by changing the ID in the request when saving the project’s members, we are able to get this user’s email address just by knowing their ID.

So how do we get users’ IDs then? It’s easy — the first registered user has the ID 0, the second user has ID 1, and so on.

Since the IDs are incremental, we can easily get the email address of every registered user on Google Crisis Map just by adding each ID as a member of the project using this form. This is known as IDOR.

The latest ID was around 32000, therefore we would be able to get 32 thousand email addresses of all registered users.


Timeline
2018-12-12Vulnerability reported
2018-12-13Priority changed to P2
2018-12-13Looking into it
2018-12-13Priority changed to P1
2018-12-18Reward issued

Written by Thomas Orlita
Follow me on Twitter: @ThomasOrlita / Mastodon: @ThomasOrlita@infosec.exchange