3 poin oleh GN⁺ 2024-03-19 | 1 komentar | Bagikan ke WhatsApp

Percobaan pertama

  • Pemindai dasar yang ditulis dengan Python memeriksa variabel konfigurasi Firebase.
  • Operasi berhenti dalam satu jam karena masalah konsumsi memori.

Percobaan kedua

  • Pemindai yang ditulis ulang dalam Go tidak mengalami kebocoran memori.
  • Memindai lebih dari 5 juta domain memakan waktu lebih lama dari perkiraan.

Memeriksa semua domain secara manual

  • Setiap entri dalam file teks 550 ribu baris diperiksa secara manual.
  • 136 situs dan 6,2 juta catatan telah diverifikasi, tetapi disadari bahwa metode otomatis diperlukan.

Katalis

  • Daftar situs yang berpotensi terdampak diperiksa dengan pemindai pendamping bernama Katalis.
  • Akses baca ke koleksi Firebase umum pada situs atau bundle .js diperiksa secara otomatis.
  • Sampel 100 catatan dikumpulkan dan jenis informasinya diperiksa untuk menilai dampak data.
  • Supabase (pesaing Firebase open source) dipilih untuk menyimpan hasil.

Angka

  • Total catatan: 124.605.664
  • Nama: 84.221.169
  • Email: 106.260.766
  • Nomor telepon: 33.559.863
  • Kata sandi: 20.185.831
  • Informasi pembayaran: 27.487.924
  • Perlu dicatat bahwa angka-angka ini bisa lebih besar dari kondisi sebenarnya.

Daftar situs yang terdampak

1. Silid LMS

  • Sistem manajemen pembelajaran untuk siswa dan guru.
  • Paparan catatan pengguna terbanyak, memengaruhi 27 juta orang.

2. Jaringan judi online

  • Terdiri dari 9 situs, semuanya dengan desain berbeda.
  • Beberapa game dimanipulasi sehingga peluang menangnya 0%.
  • Saat mencoba melaporkan masalah, dukungan pelanggan justru mencoba merayu.
  • Paparan informasi rekening bank terbanyak, 8 juta data.
  • Paparan kata sandi plaintext terbanyak, 10 juta data.

3. Lead Carrot

  • Generator lead online untuk cold calling.
  • Salah satu dari 3 situs teratas dengan paparan informasi pengguna terbanyak, memengaruhi 22 juta orang.

4. MyChefTool

  • Aplikasi manajemen bisnis dan aplikasi point-of-service untuk restoran.
  • Paparan nama terbanyak dan email terbanyak kedua, masing-masing 14 juta dan 13 juta.

Hasil

  • 842 email dikirim selama 13 hari.
  • 85% email berhasil sampai.
  • 9% email memantul.
  • 24% pemilik situs memperbaiki kesalahan konfigurasi.
  • 1% pemilik situs membalas.
  • 0,2% (2) pemilik situs memberikan bug bounty.

Opini GN⁺

  • Riset ini menunjukkan betapa mudahnya salah konfigurasi pengaturan keamanan Firebase terjadi. Ini menjadi contoh penting untuk meningkatkan kewaspadaan pengembang terhadap konfigurasi keamanan.
  • Terlihat bahwa respons pemilik situs beragam ketika masalah keamanan ditemukan. Sebagian besar memperbaiki masalahnya, tetapi sebagian mengabaikannya atau tidak memberikan kompensasi yang layak.
  • Alat otomatis yang digunakan untuk menemukan kerentanan keamanan ini juga dapat berguna bagi peneliti keamanan lain. Alat dengan fungsi serupa antara lain OWASP ZAP dan Burp Suite.
  • Saat menggunakan layanan cloud seperti Firebase, penting untuk memahami dan menerapkan pengaturan keamanan dengan tepat. Konfigurasi yang salah dapat menyebabkan kebocoran data berskala besar.
  • Kasus ini dapat membantu saat mempertimbangkan layanan lain, termasuk alternatif open source seperti Supabase, dengan membandingkan fitur keamanan dan kemudahan penggunaan. Supabase berbasis PostgreSQL dan menyediakan fungsi serupa dengan Firebase, tetapi bersifat open source.

1 komentar

 
GN⁺ 2024-03-19
Opini Hacker News
  • Seorang pengguna yang telah lama bekerja di Firebase menyebutkan bahwa masalah terkait aturan keamanan selalu menghantui produk tersebut. Berbagai pendekatan telah dicoba, tetapi masih ditemukan banyak basis data yang rentan dari sisi keamanan. Hal ini karena aturan keamanan Firebase merupakan konsep yang baru dan kompleks, serta para pengembang cenderung tidak memperbarui aturan keamanan saat menambahkan data baru ke data yang sudah ada. Selain itu, karena tidak ada implementasi backend kustom, pemindaian massal menjadi mudah, dan penulisan aturan keamanan untuk realtime database sulit serta kurang skalabel. Namun, karena pemindaian otomatis sering kali hanya menemukan data yang terbuka, masalah ini tidak terjadi sesering yang dibayangkan. Tidak ada masalah teknis pada pendekatan Firebase itu sendiri, tetapi karena ini adalah salah satu dari sedikit backend yang sepenuhnya bergantung pada data yang disimpan dan aturan keamanan, ia rentan terhadap kesalahpahaman, penggunaan yang tidak tepat, dan masalah seperti ini.
  • Seorang pengguna mengatakan situasi ini mengingatkannya pada kasus peretasan jaringan restoran cepat saji di Amerika Serikat.
  • Pengguna lain menyoroti bahwa menurut bagian akhir postingan ini, 75% situs dengan kerentanan seperti ini masih menunggu data dump, dan menilai hal itu gila. Ia menambahkan bahwa ada hari-hari ketika ia merasa perlu ada sertifikasi untuk mengoperasikan komputer.
  • Seorang pengguna menunjukkan bahwa memilih sesuatu yang murah dan cepat adalah hasil yang tak terelakkan, dan kekhawatiran sebagian pelanggan/pengguna tidak muncul dalam percakapan, sementara data pribadi merekalah yang menjadi taruhannya. Ia memperingatkan agar berhati-hati terhadap perusahaan-perusahaan yang tercantum di sini jika kepemimpinannya belum berubah, karena sudah berulang kali terbukti bahwa banyak perusahaan tidak cukup peduli untuk melindungi pelanggan mereka.
  • Pengguna lain mengajukan pertanyaan mendasar apakah sebagian besar aplikasi yang disebutkan dalam postingan ini sepenuhnya diimplementasikan dengan JavaScript sisi klien yang di-host secara statis, dengan backend berupa konfigurasi Firebase yang 100% di-host oleh Google. Jika ya, ia mengatakan tidak menyadari betapa umum arsitektur seperti ini untuk situs dengan jutaan pengguna.
  • Seorang pengguna melontarkan lelucon: 900 situs, 125 juta akun, 1 kerentanan, 0 pacar.
  • Pengguna lain menyatakan bersyukur telah memilih password manager dan kartu virtual sejak lama karena situasi seperti ini. Ia mengatakan internet terasa makin menakutkan karena kebanyakan orang tidak tahu betapa rapuhnya web dan betapa rentannya mereka sendiri.
  • Seorang pengguna menemukan bahwa program Python dengan sekitar 500 thread menggunakan semakin banyak memori seiring waktu, lalu bertanya apakah ada informasi tambahan atau solusi untuk masalah ini. Ia menyebut scraper Python miliknya juga memiliki ratusan thread dan tampaknya menggunakan banyak memori.
  • Seorang pengguna memuji pekerjaan yang dilakukan dan ingin tahu bagaimana kesimpulan bahwa jumlah pengguna yang terdampak kemungkinan lebih besar bisa dicapai. Ia menduga beberapa situs yang disebutkan (perjudian, lead carrot) mungkin dipenuhi data akun palsu.
  • Terakhir, seorang pengguna berterima kasih karena dukungan pelanggan berhasil membuatnya tertawa.