‏آسیب‌پذیری RCE تو زیرساخت پروداکشن گوگل کلاد

به گفتهٔ نویسنده، ماجرا از جایی شروع شد که یکی از ابزارهای فازینگ خودکارش به یه API گوگل کلاد به اسم cloudcrmipfrontend-pa.googleapis.com گیر داد؛ این API به چند اندپوینت دیباگِ عمومی جواب می‌داد که نباید باز می‌بودن. این آسیب‌پذیری بعداً با شناسهٔ CVE-2026-2031 ثبت شد.

خطرناک‌ترین اندپوینت، یه متد بود که تعریف پروتوباف (proto definition) هر پیامی رو تو مونوریپوی داخلی گوگل یعنی google3 برمی‌گردوند، حتی برای سرویس‌های نامرتبط مثل یوتیوب. چون تو گوگل عملاً همه‌چی با پروتوباف و gRPC تعریف می‌شه، این یعنی می‌شد ساختار درخواست و پاسخ تقریباً هر API داخلی رو کشف کرد؛ برای یه هدف بلک‌باکس مثل گوگل، این یه گنج حساب می‌شه.

نویسنده می‌گه با کمی بازی با پارامتر فیلتر، یه اندپوینت دیگه هم شروع کرد به لو دادن یه صف اجرای ورک‌فلوی داخلی. این صف شامل ورک‌فلوهایی بود که داده رو از Spanner به Salesforce سینک می‌کردن و حتی داده‌های نسبتاً حساسی مثل شناسه‌ها و وضعیت رکوردها توش دیده می‌شد. این گزارش خیلی زود از طرف گوگل به‌عنوان P0/S0 (بحرانی) علامت خورد.

ولی نویسنده متوقف نشد و رفت سراغ اندپوینت‌های ساخت ورک‌فلو، چون بین تنظیمات، رد پای یه تسک به اسم GenericStubbyTypedTask دیده می‌شد. Stubby زیرساخت فراخوانی از راه دور (RPC) داخلی گوگل ـه که نسخهٔ متن‌بازش همون gRPC ـه. ایدهٔ حمله این بود: اگه بشه با هویت سرویس پروداکشنِ این پلتفرم، کوئری‌های دلخواه Stubby زد، عملاً به بخش بزرگی از پروداکشن دسترسی باز می‌شه — و گوگل همین رو معادل RCE می‌دونه.

نویسنده توضیح می‌ده که این دسترسی بی‌حدومرز نیست. هر سرویس Stubby یه RpcSecurityPolicy با لیست مجاز per-method داره که تعیین می‌کنه چه هویتی با چه نوع اعتباری (مثلاً LOAS داخلی یا هویت کاربر نهایی) اجازهٔ صدا زدن هر متد رو داره، و چه پرمیشن IAM باید چک بشه. پس حتی با یه اهرم Stubbyِ دزدیده‌شده، فقط به همون RPCهایی می‌رسی که سیاست‌شون هویت تو رو قبول کنه؛ ولی همین هم سطح حملهٔ خیلی بزرگ‌تری باز می‌کنه.

نکتهٔ جالب اینکه ساختن ورک‌فلو اولش خطای «آرگومان نامعتبر» می‌داد، ولی نویسنده از همون داده‌های لو رفته (مقدار client_id برابر default) استفاده کرد و درخواست جواب داد. به گفتهٔ خودش، این باگ سه ماه بعد دوباره تکرار شد. درس اصلی ماجرا اینه که یه اندپوینت دیباگِ به‌ظاهر بی‌خطر که فقط «اطلاعات» لو می‌ده، تو یه معماری کاملاً مبتنی بر RPC می‌تونه به یه مسیر کامل تا اجرای کد تبدیل بشه.

نکات کلیدی:

• شروع ماجرا یه اندپوینت دیباگ عمومی تو API گوگل کلاد بود که با CVE-2026-2031 ثبت شد.
• یه متد نشتی، تعریف پروتوباف هر سرویس داخلی گوگل (google3) رو برمی‌گردوند.
• یه اندپوینت دیگه، صف اجرای ورک‌فلوی داخلی سینک Spanner به Salesforce رو لو داد.
• هدف نهایی، زدن کوئری Stubby با هویت سرویس پروداکشن بود که گوگل اون رو معادل RCE می‌دونه.
• سیاست RpcSecurityPolicy و اعتبار LOAS تعیین می‌کنن هر هویت به کدوم RPCها دسترسی داره.