Login Google OAuth tidak bisa melindungi kasus saat seseorang membeli domain startup yang gagal

• Cacat keamanan pada Google OAuth menimbulkan kerentanan serius dalam proses autentikasi "Sign in with Google"
  • Setelah membeli domain milik startup yang gagal, penyerang dapat membangun kembali akun email pada domain tersebut dan masuk ke layanan SaaS
  • Dapat mengakses layanan yang berisi data sensitif:
    • Slack, ChatGPT, Notion, Zoom, sistem HR (termasuk nomor jaminan sosial)
  • Saat laporan awal diberikan, Google menyebutnya sebagai "perilaku yang dimaksud" dan menolak perbaikan
• Akar masalahnya: Google OAuth tidak dapat mendeteksi perubahan kepemilikan domain
  • Saat domain berpindah tangan, pemilik baru dapat masuk ke akun mantan karyawan dengan claim yang sama
• Informasi claim default yang digunakan:
  • hd (hosted domain): berisi informasi domain (contoh: example.com)
  • email: berisi alamat email pengguna (contoh: [e-mail])
• Jika penyedia layanan bergantung pada dua informasi ini, perubahan kepemilikan domain tetap akan mengizinkan akses ke akun yang sama
• Skala masalah
  • 6 juta orang Amerika bekerja di startup
  • 90% startup gagal
  • 50% startup yang gagal menggunakan Google Workspace
• Sekitar 100.000 domain startup yang gagal tersedia untuk dibeli
• Rata-rata, tiap domain memiliki 10 karyawan dan menggunakan 10 layanan SaaS → ada kemungkinan lebih dari 10 juta akun berisi data sensitif

Usulan solusi dan respons Google

• Solusi yang diusulkan ke Google:
  1. ID unik pengguna: menambahkan pengenal pengguna unik yang tidak berubah seiring waktu
  2. ID unik Workspace: menambahkan pengenal Workspace unik yang terhubung ke domain
• Respons awal Google:
  • Dilaporkan pada September 2024 → ditutup sebagai "tidak dapat diperbaiki"
  • Setelah dipresentasikan di konferensi Shmoocon pada Desember 2024, Google meninjau ulang masalah ini
  • Membayar bug bounty sebesar $1,337 dan mulai mengerjakan perbaikan
• Untuk saat ini, tanpa perbaikan dari Google, masalah mendasar ini tidak bisa diselesaikan
• Beberapa layanan bahkan mengembalikan daftar seluruh pengguna jika domain cocok, sehingga kerentanan makin parah
• Bahkan jika memakai kata sandi alih-alih login Google, akun tetap bisa diambil alih lewat reset
  • Startup cenderung mewajibkan SSO dan 2FA alih-alih autentikasi berbasis kata sandi
  • Penyedia layanan perlu meminta autentikasi tambahan saat reset kata sandi (kode SMS, verifikasi kartu kredit)

Kesimpulan: masalah mendasar pada keamanan Google OAuth

• Cacat dalam implementasi OAuth Google memungkinkan pengambilalihan akun saat kepemilikan domain berubah
• Google sudah mulai mengerjakan perbaikan, tetapi solusi mendasar masih belum selesai
• Untuk saat ini, data dan akun jutaan warga Amerika tetap berisiko terekspos

[sixmen]

Saya cenderung berpikir ini adalah kesalahan di pihak pengguna yang menggunakan email dengan domain tersebut sebagai sarana autentikasi, lalu melepaskan domainnya tetapi tidak menonaktifkan SaaS terkait dengan benar. Namun, apakah ini juga harus dianggap sebagai celah keamanan?

[kargnas]

Di layanan yang saya buat, saya sudah mencegah isu ini sebelumnya, tetapi meskipun begitu saya setuju dengan pendapat ini.
Kalau ini dianggap masalah, maka login dan pendaftaran lewat email biasa juga harus dianggap bermasalah. Semuanya menggunakan email sebagai ID unik, dan verifikasi untuk pemulihan kata sandi juga semuanya memeriksa kepemilikan lewat email.

Secara ekstrem, jika kita berasumsi bahwa domain terkenal seperti gmail.com atau hotmail.com diretas sehingga hak untuk mengatur DNS domain tersebut jatuh ke tangan peretas, maka sudah sangat jelas bahwa akun di semua layanan SaaS di seluruh dunia akan ikut berada dalam bahaya.

[GN⁺]

Komentar Hacker News

• Situasi ketika DankStartup tutup dan domainnya diambil alih orang lain sehingga bisa mengakses akun yang sudah ada tampaknya merupakan masalah tanggung jawab DankStartup, Microsoft, dan OpenAI

  • Menjelaskannya sebagai kerentanan OAuth tidaklah tepat

• Dalam implementasi OpenID Google, cara yang benar adalah mengautentikasi menggunakan klaim sub

  • Perlu ada alur untuk mengantisipasi jika klaim sub berubah
  • 'ID pengguna unik yang tidak berubah' yang diusulkan pada dasarnya tidak berbeda dari klaim sub

• Ini adalah masalah mendasar dari pendekatan yang bergantung pada DNS: setelah domain kedaluwarsa, pemilik baru bisa mendapatkan hak yang sebelumnya dimiliki pemilik lama

  • Ini adalah masalah yang bisa muncul pada sistem autentikasi yang bergantung pada alamat email atau DNS

• Tidak ada kerentanan pada Google OAuth; jika Anda mengambil alih sebuah domain, Anda akan memiliki semua alamat email pada domain tersebut

  • Hasil yang sama bisa terjadi bahkan tanpa menggunakan Google OAuth

• Berbagi pengalaman dari kasus thehunt.com di masa lalu, ketika setelah mengambil alih domain, semua layanan bisa diakses

  • Mengusulkan ide startup untuk memantau status domain guna mencegah ancaman keamanan

• Ini adalah masalah pada layanan yang tidak menggunakan field sub; field sub harus digunakan untuk identifikasi pengguna

  • Bisa menghasilkan uang dengan mengirimkan laporan kerentanan ke layanan yang tidak menggunakan field sub

• Usulan agar OpenID Connect Google mengimplementasikan dua pengenal yang tidak berubah

  • Klaim sub dan ID workspace unik yang terhubung ke domain

• Kasus klaim sub berubah di Google OAuth jarang terjadi, sehingga kemungkinan besar ini masalah implementasi layanan

• Berbagi kasus akses email setelah pengambilalihan domain

  • Masalah diselesaikan melalui koneksi internal dengan Google

• Klaim tentang "jutaan akun" didasarkan pada asumsi bahwa startup yang gagal tidak menonaktifkan akun SaaS