Lebih dari setahun yang lalu, di pos kami berjudul Akun Google Oauth dan Phantomkami membahas bagaimana menggunakan opsi “Masuk dengan Google” untuk layanan perusahaan memungkinkan karyawan untuk membuat akun Phantom Google yang tidak dikendalikan oleh Admin Google Workspace perusahaan, dan terus berfungsi setelah lepas lepas. Baru -baru ini, itu telah menemukan Bahwa ini bukan satu -satunya masalah dengan Oauth. Karena kelemahan dalam mekanisme otentikasi ini, siapa pun dapat memperoleh akses ke data banyak organisasi yang tidak berfungsi dengan mendaftarkan kembali domain yang mereka tinggalkan. Dalam artikel ini, kami mengeksplorasi serangan ini secara lebih rinci.
Bagaimana otentikasi bekerja dengan “Masuk dengan Google”
Beberapa organisasi mungkin percaya bahwa “Masuk dengan Google” menyediakan mekanisme otentikasi yang andal yang didukung oleh teknologi canggih Google dan kemampuan pemantauan pengguna yang luas. Namun, pada kenyataannya, pemeriksaan otentikasi Google OAuth cukup mendasar. Umumnya berujung pada memverifikasi bahwa pengguna memiliki akses ke alamat email yang ditautkan ke Google Workspace organisasi.
Selain itu, seperti yang disebutkan dalam artikel kami sebelumnya di Google OAuth, ini tidak harus menjadi alamat GMAIL – akun Google dapat ditautkan ke alamat email apa pun. Oleh karena itu, keamanan mengakses layanan perusahaan melalui “Masuk dengan Google” hanya sekuat keamanan email yang ditautkan ke akun Google.
Sekarang mari kita masuk ke detailnya…
Saat mengautentikasi pengguna dalam layanan perusahaan, Google OAuth mengirimkan informasi berikut ke layanan itu:

Secara teori, token ID Google OAuth mencakup parameter unik yang disebut sub untuk setiap akun Google. Namun, dalam praktiknya, karena masalah dengan penggunaannya, layanan sering hanya memeriksa domain dan alamat email. Sumber
Google merekomendasikan agar layanan itu menggunakan sub Parameter, mengklaim bahwa pengidentifikasi ini unik dan konstan untuk akun pengguna – tidak seperti alamat email. Namun dalam kenyataannya, sub Parameter tidak selalu konstan; Untuk sejumlah kecil pengguna, itu berubah dari waktu ke waktu, yang dapat menyebabkan kegagalan otentikasi. Akibatnya, layanan cenderung tidak menggunakannya, dan sebaliknya hanya memverifikasi domain dan alamat email – bertentangan dengan rekomendasi Google.
“Masuk dengan Google” menggunakan domain yang ditinggalkan
Dengan demikian, penyerang dapat memperoleh akses yang tidak sah ke layanan perusahaan dengan hanya memiliki akses ke email dalam domain perusahaan itu. Ini sangat mudah dilakukan jika perusahaan telah menghentikan operasi dan meninggalkan domainnya: siapa pun dapat mendaftarkannya sendiri.
Penyerang kemudian dapat membuat alamat email apa pun di bawah domain ini, dan menggunakannya untuk masuk ke salah satu layanan yang kemungkinan digunakan perusahaan. Beberapa layanan ini dapat menampilkan daftar pengguna nyata yang terhubung ke ruang kerja organisasi – bahkan jika alamat yang dimasukkan oleh penyerang tidak pernah benar -benar digunakan.
Dengan daftar ini – dan kendali penuh atas semua alamat email dalam domain yang ditinggalkan – penyerang dapat merekonstruksi ruang kerja Google asli dari perusahaan yang mati. Dengan cara ini, penyerang dapat memperoleh akses ke profil mantan karyawan dalam layanan yang menggunakan Google OAuth untuk otentikasi.
Seberapa serius masalah ini?
Dylan Ayrey, peneliti yang menemukan kerentanan Google OAuth ini (dan masalah sebelumnya dengan Akun Phantom), bertujuan untuk menunjukkan keparahan konsekuensi potensial. Menggunakan data dari Crunchbase, Ayrey menyusun daftar lebih dari 100.000 startup yang dihentikan yang domainnya sekarang dijual.
Ayrey membeli salah satu domain yang ditinggalkan ini dan menguji kelayakan serangan itu. Di antara layanan perusahaan yang berhasil ia akses menggunakan kerentanan ini adalah sistem yang malas, zoom, gagasan, chatgpt, dan SDM.
Dengan demikian, dengan serangan yang relatif sederhana ini membutuhkan sumber daya minimal, penyerang dapat memperoleh akses ke banyak informasi rahasia, mulai dari korespondensi karyawan dan catatan hingga data pribadi dari sistem SDM.
Menurut perkiraan Ayrey, sekitar 50% startup menggunakan Google Workspace. Jika kita mengira bahwa startup yang tidak berfungsi rata -rata memiliki sekitar 10 karyawan, kita bisa berbicara tentang ratusan ribu orang dan jutaan akun yang rentan.
Siapa yang bertanggung jawab, dan apa yang bisa dilakukan?
Ayrey dengan patuh memberi tahu Google tentang kerentanan ini melalui program hadiah bugnya. Dia juga menyarankan solusi jangka panjang: menciptakan pengidentifikasi yang benar-benar permanen dan unik untuk akun Google dan ruang kerja Google. Namun, laporannya pada awalnya ditolak, dengan komentar “tidak diperlukan perbaikan” dan diberi label sebagai “penipuan atau penyalahgunaan”!
Namun, beberapa bulan setelah Ayrey mempresentasikan temuannya di konferensi peretas (!) Laporan itu dibuka kembali, dan ia dianugerahi $ 1337. Khususnya, ia menerima hadiah minimal yang sama untuk penemuan sebelumnya tentang kerentanan akun Google Phantom.
Menurut Ayrey, Google berjanji untuk memperbaiki kerentanan di Google OAuth, tetapi tidak menentukan kapan atau bagaimana tepatnya mereka berencana untuk melakukan ini. Oleh karena itu, masalah dengan mekanisme “masuk dengan Google” tetap merupakan masalah yang belum terselesaikan, yang tidak ada yang bersedia mengambil tanggung jawab. Potensi korban serangan ini termasuk mantan karyawan perusahaan yang tidak berfungsi yang tidak lagi memiliki kendali atas akun mereka. Lebih buruk lagi, tidak ada yang bertanggung jawab atas keamanan akun ini lagi.
Langkah bijak di sini adalah bagi perusahaan untuk mengambil langkah -langkah pencegahan terlebih dahulu. Namun, sangat sedikit startup yang secara serius merencanakan kematian mereka sendiri – apalagi apa yang akan terjadi sesudahnya.
Untungnya, membela terhadap kerentanan Google OAuth ini relatif mudah. Ada dua opsi eksklusif non-mutual:
- Gunakan kombo login-dan-password tradisional alih-alih “Masuk dengan Google”, dan selalu aktifkan otentikasi dua faktor.
- Jika perusahaan Anda berhenti beroperasi, jangan meninggalkan ruang kerja di layanan perusahaan; Hapus saja. Ini cukup mudah dilakukan; Misalnya, berikut adalah instruksi untuk Kendur Dan Gagasan.