Google Puji 'Nice Catch', Kemudian Nafi Bounty Untuk Kelemahan Kritikal Yang Masih Berleluasa

Bagaimana Config Connector Berfungsi dan Di Mana Ia Runtuh

Config Connector ialah pengendali Kubernetes yang membolehkan organisasi mengurus sumber GCP — seperti storan awan, pangkalan data dan dasar IAM — melalui arahan Kubernetes . Ia direka untuk menyatukan alat: anda boleh mencipta, mengemas kini dan memadam sumber awan menggunakan kubectl, alat baris arahan Kubernetes yang biasa .

O'Leary mendapati bahawa pendekatan bersatu ini datang dengan kesan sampingan yang berbahaya. Kelemahan ini membolehkan mana-mana pengguna namespace Kubernetes memintas kawalan Identity and Access Management (IAM) Google Cloud Platform. Seorang pemaju dengan akses asas kepada hanya satu namespace Kubernetes boleh mengeksploitasi ini untuk mendapatkan kawalan pentadbiran penuh ke atas persekitaran GCP seluruh organisasi — dengan berkesan memiliki keseluruhan akaun awan . O'Leary memberitahu The Register bahawa eksploitasi itu boleh dilaksanakan dalam masa kira-kira lima saat, tanpa meninggalkan sebarang jejak audit .

Mekanisme Teknikal: Eskalasi Keistimewaan Merentas Namespace

Walaupun Google tidak mengeluarkan penerangan teknikal yang terperinci, pelbagai sumber dan laporan O'Leary menunjukkan bahawa kelemahan itu terletak pada cara Config Connector mengendalikan kebenaran IAM merentas namespace Kubernetes yang berbeza .

Dalam kluster GKE multi-penyewa yang dikonfigurasi dengan betul, namespace yang berbeza sepatutnya diasingkan — pengguna dalam namespace A tidak sepatutnya dapat mengurus sumber dalam namespace B atau memberikan diri mereka peranan GCP yang tinggi. Penemuan O'Leary menunjukkan bahawa jenis sumber IAM Config Connector tidak menguatkuasakan sempadan namespace ini . Dengan mencipta atau mengubah suai sumber dasar IAM melalui Config Connector dari dalam satu namespace, pengguna dengan kebenaran Kubernetes yang minimum boleh memberikan diri mereka peranan roles/owner pada projek GCP — atau keseluruhan organisasi .

Ini adalah pelanggaran prinsip keistimewaan paling rendah dan pintasan terus lapisan kebenaran IAM GCP. Ia bukan salah konfigurasi yang boleh diperbaiki oleh pentadbir; ia adalah kelemahan peringkat reka bentuk dalam cara Config Connector mewakilkan kuasa IAM .

Garis Masa: Dari 'Nice Catch!' ke 'Berfungsi Seperti Yang Dimaksudkan'

Menurut laporan eksklusif The Register pada 18 Jun 2026, dan sumber yang menyokong, garis masa berlaku seperti berikut:

• Akhir Mac / awal April 2026 (anggaran): O'Leary menemui kelemahan itu dan menghantar laporan terperinci kepada Program Ganjaran Kerentanan Awan Google (Cloud VRP). Laporan itu termasuk bukti konsep yang menunjukkan bagaimana penyerang boleh meningkat daripada pengguna namespace kepada pemilik organisasi GCP .
• Penilaian awal: Pasukan bug bounty Google menyemak penghantaran itu, mengkategorikannya sebagai kelemahan keutamaan tinggi, keterukan tinggi, dan wakil Google secara peribadi membalas dengan 'Nice catch!' .
• ~Mei/Jun 2026: Tanpa mengeluarkan pembetulan, Google membatalkan keputusannya. Syarikat itu menutup laporan itu, mengisytiharkan bahawa kelakuan itu 'berfungsi seperti yang dimaksudkan' — bermakna ia tidak layak sebagai kelemahan di bawah peraturan Cloud VRP. Tiada ganjaran dikeluarkan .
• Sehingga 18 Jun 2026: Kelemahan itu masih belum diperbaiki. Laporan pepijat O'Leary, walau bagaimanapun, masih ditandakan sebagai 'keutamaan tinggi' dan 'diterima' dalam sistem penjejakan Google — satu percanggahan yang jelas . Kes ini telah dibuka selama hampir tiga bulan .

Mengapa Google Mungkin Menafikan Bounty

Google tidak secara terbuka menjelaskan pembalikannya, tetapi beberapa faktor mungkin dimainkan berdasarkan peraturan Cloud VRP dan konteks perubahan program Google 2026 yang lebih luas.

Peraturan Cloud VRP rasmi menyatakan: “Laporan kerentanan Google Cloud di mana sumber milik pelanggan diuji tidak layak untuk ganjaran.” Skop program terhad secara eksplisit kepada kelemahan dalam infrastruktur dan perkhidmatan milik Google, bukan dalam komponen yang boleh dikonfigurasi oleh pelanggan . Jika Google menganggap kelakuan Config Connector sebagai masalah konfigurasi pelanggan dan bukannya kelemahan produk, ia secara teknikal boleh menafikan bounty di bawah bahasa ini — walaupun jika kelakuan itu memintas kawalan IAM yang dijangka.

Kemungkinan lain: peraturan Cloud VRP menyatakan bahawa program itu meliputi “kelemahan pengesahan atau kebenaran” dalam item skop, yang sepatutnya meliputi penemuan O'Leary . Tetapi Google sebelum ini telah berhujah dalam konteks lain bahawa eskalasi keistimewaan tertentu bukan pepijat jika ia memerlukan kebenaran khusus untuk dicetuskan — pendirian yang mendapat kritikan daripada penyelidik . Dalam kes O'Leary, kebenaran awal yang diperlukan (akses peringkat namespace kepada sumber Config Connector) adalah minimum dan biasanya diberikan kepada pemaju, menjadikan eskalasi itu nyata dan berbahaya .

Faktor ketiga berkaitan dengan pengubahsuaian Program Ganjaran Kerentanan 2026 Google untuk Chrome dan Android. Pada akhir April dan awal Mei 2026, Google mengumumkan bahawa ia memotong pembayaran Chrome dan menyusun semula ganjaran, dengan alasan lonjakan dalam penghantaran berkualiti rendah yang dijana AI . Syarikat itu menyatakan bahawa ia “mengurangkan beberapa jumlah ganjaran dan bonus merentas Android dan Chrome” untuk memberi tumpuan kepada “kualiti dan kesan dunia sebenar berbanding jumlah semata-mata” . Walaupun kes O'Leary berada di bawah Cloud VRP yang berasingan, bukan program Chrome atau Android, pendirian umum syarikat untuk mengetatkan pembayaran mungkin telah mempengaruhi keputusan itu — terutamanya jika Google melihat isu Config Connector sebagai pilihan reka bentuk dan bukannya pepijat .

Reaksi Penyelidik Yang Semakin Meningkat

Insiden ini telah mencetuskan kritikan daripada komuniti penyelidikan keselamatan, dengan beberapa pihak berhujah bahawa Google menggunakan naratif penghantaran AI sebagai alasan untuk menafikan kelemahan yang ditemui secara manual dan sah . Komen PC Perspective memanggil keputusan itu “menjadi kedekut pada bug bounty” dan mencatatkan percanggahan antara pujian awal Google dan penafian akhirnya . Cyber News Live menyerlahkan bahawa kelemahan itu boleh membolehkan pengambilalihan lima saat tanpa sebarang rekod yang ditinggalkan .

Kes ini juga datang pada masa Google pada masa yang sama meningkatkan ganjaran teratas untuk kategori tertentu pepijat Android — sehingga $1.5 juta untuk eksploitasi klik sifar Titan M yang berterusan . Pendekatan dua peringkat ini — memberi ganjaran yang murah hati untuk eksploitasi perkakasan yang mendalam sambil menafikan walaupun pengakuan untuk pintasan IAM awan yang teruk — telah menyemarakkan persepsi bahawa program bug bounty Google memperuntukkan belanjawan secara strategik dan bukannya menilai risiko secara jujur .

Apa Maknanya Untuk Organisasi Yang Menggunakan Config Connector

Organisasi yang menjalankan Config Connector dalam kluster GKE multi-penyewa atau kongsi harus menganggap ini sebagai risiko yang mendesak dan tidak ditambal. Tanpa tampung rasmi daripada Google, langkah-langkah pengurangan berikut boleh mengurangkan pendedahan:

• Hadkan penciptaan sumber iam* di peringkat namespace menggunakan dasar RBAC Kubernetes. Jangan berikan kebenaran create, update, atau Delete pada sumber tersuai IAMPolicy, IAMPolicyMember, atau IAMPartialPolicy kepada namespace yang tidak dipercayai.
• Gunakan Config Connector mod namespace dengan akaun perkhidmatan keistimewaan rendah yang berbeza bagi setiap namespace. Dokumentasi Google menyokong konfigurasi ini, yang mengehadkan radius letupan .
• Pantau perubahan IAM GCP dari asal Config Connector. Dayakan log audit dan sediakan pemberitahuan untuk sebarang panggilan setIamPolicy yang berasal dari kluster GKE anda.
• Pertimbangkan untuk melumpuhkan Config Connector dalam persekitaran di mana pengasingan multi-penyewa diperlukan, sehingga Google menyelesaikan kelemahan itu.

Dokumentasi rasmi Google mengenai mendapatkan akses kepada sumber dengan IAM menerangkan konfigurasi yang disyorkan tetapi tidak menangani vektor pintasan merentas namespace yang menjadi teras laporan O'Leary . Organisasi harus menganggap bahawa penggunaan Config Connector mereka mungkin terdedah.

Kesimpulan Utama

• Kelemahan eskalasi keistimewaan dalam Config Connector Google (CVSS 10.0) membolehkan mana-mana pengguna namespace Kubernetes mendapat pemilikan penuh projek GCP.
• Pasukan bug bounty Google pada mulanya menerima laporan itu sebagai keutamaan tinggi, kemudian membatalkan keputusan, mengisytiharkannya 'berfungsi seperti yang dimaksudkan' dan menafikan ganjaran.
• Hampir tiga bulan selepas laporan awal, kelemahan itu masih belum diperbaiki tanpa garis masa pembetulan daripada Google.
• Insiden ini berlaku di tengah-tengah perubahan program 2026 Google yang lebih luas yang memotong pembayaran Chrome sambil menaikkan ganjaran Android, merumitkan hubungan syarikat dengan penyelidik keselamatan.