Kelemahan pembatalan yang tertangguh

Isu ini berpunca daripada cara perubahan kelayakan merebak di seluruh infrastruktur teragih Google. Apabila kunci dipadamkan, pembatalan tidak dikuatkuasakan serentak pada setiap pelayan yang mengendalikan pengesahan API. Sesetengah sistem menolak kelayakan dengan cepat, manakala yang lain mungkin masih menerimanya sehingga kemas kini pemadaman sampai kepada mereka.

Aikido menguji tingkah laku ini dengan menghantar permintaan pengesahan berulang kali selepas memadamkan kunci yang baru dibuat. Sepanjang sepuluh ujian, pengesahan yang berjaya berterusan sehingga penyebaran pembatalan selesai, menghasilkan tetingkap 8–23 minit yang diperhatikan dengan median kira-kira 16 minit.

Ini bermakna kunci yang kelihatan dipadamkan dalam antara muka Google Cloud mungkin masih berfungsi seketika pada bahagian platform yang lain.

Mengapa jurang ini mewujudkan risiko sebenar

Bagi organisasi yang bertindak balas terhadap kelayakan yang bocor, pembatalan segera adalah kritikal. Kelewatan yang ditemui oleh Aikido mewujudkan tempoh di mana penyerang boleh terus menggunakan kunci tersebut walaupun selepas pembela percaya ia telah dilumpuhkan.

Jika penyerang memiliki kunci yang terjejas semasa tempoh itu, mereka mungkin masih boleh:

• Mengakses API yang didayakan yang terikat dengan projek
• Menghantar permintaan API tambahan
• Menjana penggunaan awan yang tidak dijangka atau caj pengebilan

Para penyelidik mengesahkan tingkah laku dengan kunci yang dikonfigurasikan untuk Gemini, dan melihat pembatalan tertangguh yang sama untuk kunci yang disambungkan ke API Google Cloud yang lain seperti BigQuery dan Google Maps. Kelemahan ini terikat pada jenis kelayakan kunci API itu sendiri dan bukannya perkhidmatan tertentu.

Respons Google terhadap laporan

Menurut laporan dan pendedahan Aikido, Google pada mulanya menganggap tingkah laku itu sebagai kelewatan penyebaran yang dijangkakan dalam sistem teragih dan bukannya kelemahan keselamatan kritikal. Beberapa laporan mengatakan isu itu pada mulanya ditutup sebagai "tidak akan dibaiki."

Selepas semakan lanjut, laporan itu kemudiannya dibuka semula dan diklasifikasikan secara dalaman sebagai bug P0, menunjukkan keutamaan tinggi untuk siasatan.

Punca teknikal yang mendasari—kemas kini pembatalan yang merebak secara berperingkat merentasi infrastruktur—bermakna masa pembatalan yang tepat boleh berbeza-beza bergantung pada sistem bahagian belakang yang memproses permintaan.

Langkah berjaga-jaga praktikal untuk pembangun dan pasukan keselamatan

Sehingga tingkah laku pembatalan dijamin segera, pasukan keselamatan harus menganggap bahawa memadamkan kunci API tidak menyekat semua akses serta-merta.

Langkah berjaga-jaga yang disyorkan termasuk:

Anggap pemadaman sebagai langkah pembendungan yang tertangguh
Rancang untuk tempoh risiko sementara—kira-kira sehingga 30 minit—di mana kunci yang terjejas mungkin masih berfungsi.

Pantau log dan pengebilan selepas pembatalan
Panggilan API yang tidak dijangka atau lonjakan penggunaan secara tiba-tiba selepas pemadaman mungkin menunjukkan penyalahgunaan yang berterusan semasa tempoh penyebaran.

Hadkan kunci API di mana mungkin
Google mengesyorkan menggunakan sekatan seperti perujuk yang dibenarkan, alamat IP, atau API tertentu supaya kunci yang bocor mempunyai utiliti yang terhad.

Putar dan gantikan kelayakan
Daripada hanya bergantung pada pemadaman, putar kunci dan kemas kini perkhidmatan untuk menggunakan kelayakan yang baru dijana secepat mungkin.

Pengajaran yang lebih luas untuk keselamatan awan

Penemuan ini menyerlahkan realiti operasi penting sistem teragih yang besar: perubahan konfigurasi, termasuk pembatalan kelayakan, selalunya merebak secara beransur-ansur dan bukannya serta-merta.

Bagi pembangun dan pasukan keselamatan, pengambilannya adalah mudah—"dipadam" tidak semestinya bermaksud "tidak aktif serta-merta." Buku panduan pertahanan harus mengambil kira kelewatan penyebaran yang singkat apabila kelayakan sensitif dibatalkan.

Kelemahan pembatalan yang tertangguh

Isu ini berpunca daripada cara perubahan kelayakan merebak di seluruh infrastruktur teragih Google. Apabila kunci dipadamkan, pembatalan tidak dikuatkuasakan serentak pada setiap pelayan yang mengendalikan pengesahan API. Sesetengah sistem menolak kelayakan dengan cepat, manakala yang lain mungkin masih menerimanya sehingga kemas kini pemadaman sampai kepada mereka.

Aikido menguji tingkah laku ini dengan menghantar permintaan pengesahan berulang kali selepas memadamkan kunci yang baru dibuat. Sepanjang sepuluh ujian, pengesahan yang berjaya berterusan sehingga penyebaran pembatalan selesai, menghasilkan tetingkap 8–23 minit yang diperhatikan dengan median kira-kira 16 minit.

Ini bermakna kunci yang kelihatan dipadamkan dalam antara muka Google Cloud mungkin masih berfungsi seketika pada bahagian platform yang lain.

Mengapa jurang ini mewujudkan risiko sebenar

Bagi organisasi yang bertindak balas terhadap kelayakan yang bocor, pembatalan segera adalah kritikal. Kelewatan yang ditemui oleh Aikido mewujudkan tempoh di mana penyerang boleh terus menggunakan kunci tersebut walaupun selepas pembela percaya ia telah dilumpuhkan.

Jika penyerang memiliki kunci yang terjejas semasa tempoh itu, mereka mungkin masih boleh:

• Mengakses API yang didayakan yang terikat dengan projek
• Menghantar permintaan API tambahan
• Menjana penggunaan awan yang tidak dijangka atau caj pengebilan

Para penyelidik mengesahkan tingkah laku dengan kunci yang dikonfigurasikan untuk Gemini, dan melihat pembatalan tertangguh yang sama untuk kunci yang disambungkan ke API Google Cloud yang lain seperti BigQuery dan Google Maps. Kelemahan ini terikat pada jenis kelayakan kunci API itu sendiri dan bukannya perkhidmatan tertentu.

Respons Google terhadap laporan

Menurut laporan dan pendedahan Aikido, Google pada mulanya menganggap tingkah laku itu sebagai kelewatan penyebaran yang dijangkakan dalam sistem teragih dan bukannya kelemahan keselamatan kritikal. Beberapa laporan mengatakan isu itu pada mulanya ditutup sebagai "tidak akan dibaiki."

Selepas semakan lanjut, laporan itu kemudiannya dibuka semula dan diklasifikasikan secara dalaman sebagai bug P0, menunjukkan keutamaan tinggi untuk siasatan.

Punca teknikal yang mendasari—kemas kini pembatalan yang merebak secara berperingkat merentasi infrastruktur—bermakna masa pembatalan yang tepat boleh berbeza-beza bergantung pada sistem bahagian belakang yang memproses permintaan.

Langkah berjaga-jaga praktikal untuk pembangun dan pasukan keselamatan

Sehingga tingkah laku pembatalan dijamin segera, pasukan keselamatan harus menganggap bahawa memadamkan kunci API tidak menyekat semua akses serta-merta.

Langkah berjaga-jaga yang disyorkan termasuk:

Anggap pemadaman sebagai langkah pembendungan yang tertangguh
Rancang untuk tempoh risiko sementara—kira-kira sehingga 30 minit—di mana kunci yang terjejas mungkin masih berfungsi.

Pantau log dan pengebilan selepas pembatalan
Panggilan API yang tidak dijangka atau lonjakan penggunaan secara tiba-tiba selepas pemadaman mungkin menunjukkan penyalahgunaan yang berterusan semasa tempoh penyebaran.

Hadkan kunci API di mana mungkin
Google mengesyorkan menggunakan sekatan seperti perujuk yang dibenarkan, alamat IP, atau API tertentu supaya kunci yang bocor mempunyai utiliti yang terhad.

Putar dan gantikan kelayakan
Daripada hanya bergantung pada pemadaman, putar kunci dan kemas kini perkhidmatan untuk menggunakan kelayakan yang baru dijana secepat mungkin.

Pengajaran yang lebih luas untuk keselamatan awan

Penemuan ini menyerlahkan realiti operasi penting sistem teragih yang besar: perubahan konfigurasi, termasuk pembatalan kelayakan, selalunya merebak secara beransur-ansur dan bukannya serta-merta.

Bagi pembangun dan pasukan keselamatan, pengambilannya adalah mudah—"dipadam" tidak semestinya bermaksud "tidak aktif serta-merta." Buku panduan pertahanan harus mengambil kira kelewatan penyebaran yang singkat apabila kelayakan sensitif dibatalkan.