900 situs, 125 juta akun, 1 kerentanan

 (env.fail)
3 poin oleh GN⁺ 2024-03-19 | 1 komentar | Bagikan ke WhatsApp
  • Satu aturan keamanan Firebase yang salah konfigurasi menyebabkan data pengguna dari ratusan situs terekspos, dengan skala yang terverifikasi saja mencapai sekitar 124,6 juta record
  • Investigasi dimulai dengan mencari variabel konfigurasi Firebase di situs web dan bundle JavaScript yang dimuat, lalu ditulis ulang ke Go karena masalah memori pada pemindai Python
  • Pemindai pendamping Catalyst secara otomatis memeriksa apakah koleksi Firebase dapat dibaca, lalu memperkirakan jenis dan skala informasi yang terekspos berdasarkan data sampel
  • Item yang terekspos dalam agregasi mencakup 84.221.169 nama, 106.266.766 email, 33.559.863 nomor telepon, 20.185.831 kata sandi plaintext, dan 27.487.924 informasi pembayaran
  • Tim peneliti mengirim 842 email pelaporan selama 13 hari, tetapi hanya 24% pemilik situs yang memperbaiki konfigurasi, 1% yang membalas, dan hanya 2 situs yang menawarkan bug bounty

Pemindaian eksposur Firebase skala internet

  • Setelah kasus pelanggaran Chattr.ai, dimulailah pemindaian skala internet untuk mencari PII yang terekspos melalui instance Firebase yang salah konfigurasi
  • Pemindai Python pertama memeriksa variabel konfigurasi Firebase di situs web atau bundle .js yang dimuat, tetapi penggunaan memori terus meningkat saat berjalan dengan sekitar 500 thread dan mengalami OOM dalam waktu kurang dari satu jam
  • Pemindai yang kemudian ditulis ulang dalam Go dijalankan terhadap 5,5 juta domain, dan memerlukan waktu 2–3 minggu, lebih lama dari perkiraan awal sekitar 11 hari
  • Hanya dari tinjauan manual awal saja sudah ditemukan 136 situs dan 6,2 juta record, tetapi daftar kandidat yang sangat besar membuat otomasi penuh menjadi perlu

Catalyst dan estimasi skala eksposur

  • Catalyst menerima situs kandidat atau bundle JavaScript sebagai input, lalu secara otomatis memeriksa apakah ada akses baca ke koleksi Firebase umum maupun koleksi yang disebut langsung di JavaScript
  • Jika menemukan koleksi yang dapat dibaca, alat ini mengumpulkan sampel 100 record untuk mengidentifikasi jenis informasi yang terkandung, lalu mengalikannya dengan ukuran total koleksi untuk memperkirakan dampak
  • Sebagai penyimpanan hasil, dipilih Supabase, produk open-source berbasis PostgreSQL yang bersaing dengan Firebase, dan data yang telah dirapikan diunggah ke tabel database privat
  • Angka agregatnya adalah sebagai berikut, dan skala eksposur sebenarnya masih mungkin lebih besar daripada angka yang ditampilkan
    • Total record: 124.605.664
    • Nama: 84.221.169
    • Email: 106.266.766
    • Nomor telepon: 33.559.863
    • Kata sandi: 20.185.831
    • Informasi pembayaran: 27.487.924, termasuk informasi bank dan invoice

Situs dengan dampak terbesar

  • Silid LMS

    • Sistem manajemen pembelajaran untuk siswa dan guru
    • Menjadi kasus terbesar dengan 27 juta record pengguna yang terekspos, termasuk nama, email, dan nomor telepon

  • Jaringan judi online

    • Terdiri dari 9 situs yang saling di-reskin
    • Beberapa spin dimanipulasi agar peluang menang menjadi 0%
    • Detail login lengkap akun bank yang terekspos mencapai 8 juta, yang merupakan jumlah terbesar
    • 10 juta kata sandi plaintext juga terekspos, terbesar di antara situs-situs yang terdampak
    • Saat mencoba melaporkan masalah tersebut, dukungan pelanggan justru menggoda peneliti di tengah percakapan

  • Lead Carrot

    • Layanan pembuatan lead online untuk cold call
    • Menempati peringkat ketiga dalam jumlah data pengguna yang terekspos, memengaruhi 22 juta orang

  • MyChefTool

    • Aplikasi manajemen bisnis dan aplikasi POS untuk restoran
    • Menempati peringkat pertama untuk jumlah nama yang terekspos dan kedua untuk email, masing-masing sebanyak 14 juta dan 13 juta

Respons setelah pelaporan

  • Tim peneliti mengirim 842 email selama 13 hari
    • 85% berhasil terkirim dan 9% memantul
    • 24% pemilik situs memperbaiki konfigurasi yang salah
    • Hanya 1% pemilik situs yang membalas
    • 2 pemilik situs, setara 0,2%, menawarkan bug bounty

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-19
Komentar Hacker News

  • Saya sudah lama bekerja di Firebase, dan masalah security rules terus menghantui produk ini
    Berbagai pendekatan sudah dicoba, seperti aturan bawaan yang kedaluwarsa otomatis dan peningkatan edukasi, tetapi pada akhirnya masih banyak database yang terlihat tidak aman
    Alasannya rumit: security rules ala Firebase masih merupakan konsep yang asing, dan pengembang baru yang menambahkan data ke lokasi yang sudah ada sering kali tidak ikut memperbarui aturan agar sesuai dengan perubahan kebutuhan privasi data
    Selain itu, “security through obscurity” yang dulu diberikan oleh backend buatan masing-masing jadi hilang, sehingga pemindaian skala besar menjadi mudah
    Khususnya, aturan Realtime Database sulit ditulis dan kurang bagus skalabilitasnya, tetapi pemindaian otomatis biasanya hanya mencari data yang terbuka, jadi aturan yang sedikit lebih baik daripada read write true saja sudah cukup untuk mencegahnya
    Secara teknis, pendekatan Firebase sendiri bukan sesuatu yang salah, tetapi karena ini adalah salah satu dari sangat sedikit backend yang memakai model berpusat pada data tersimpan dan security rules, sistem ini mudah disalahpahami, disalahgunakan, dan rentan terhadap insiden seperti ini

    • Sejujurnya, model di mana frontend bisa langsung menulis data ke database selalu terasa meragukan bagiku, bahkan dengan adanya security rules
      Di backend, validasi dan aturan keamanan terlihat sebagai bagian dari spesifikasi, tetapi security rules Firebase adalah proses terpisah sehingga mudah terlupakan dan perlu dievaluasi ulang setiap kali membuat fitur baru
    • Saya mencoba menghubungi kanal dukungan Google dan meminta bantuan atau agar mereka bisa memberi tahu situs-situs tersebut tentang masalah ini, tetapi jawabannya hanya bahwa mereka bisa membuatkan feature request jika saya mau
      Rasanya perlu eskalasi cukup tinggi di internal Firebase untuk menarik perhatian orang yang bisa memberi tahu pemilik proyek
    • Jika melihat https://firebase.google.com/docs/rules/basics, saya penasaran apakah simple security mode yang hanya memilih template security rules yang sudah ditentukan bisa praktis
      Misalnya, apakah template seperti “hanya pemilik konten yang boleh mengakses” atau “akses berbasis atribut/peran” bisa mencakup pola sebagian besar aplikasi, atau apakah benar-benar tetap butuh banyak aturan kustom
      Masalah besar dalam menulis security rules adalah hampir semua kesalahan menjadi masalah keamanan, jadi kalau tidak perlu, orang tentu tidak ingin menyentuhnya
      Jika aturan terlalu ketat, aplikasi langsung tidak berjalan dan itu langsung terlihat, tetapi jika terlalu longgar, akses berlebihan sering tidak terlihat sampai seseorang benar-benar mengujinya
      Terkait itu, mungkin layak juga memaksa pengembang menulis test case contoh penolakan akses untuk setiap security rule
    • Kami punya satu trik sederhana yang sangat membantu: rules transpiler bernama fireplan menambahkan aturan default "$other": {".read": false, ".write": false} ke semua properti
      Dengan begitu, field baru harus ditambahkan secara eksplisit, sehingga hampir mustahil nilai baru tanpa sadar “mewarisi” aturan yang sudah ada
      Saya sudah memakai Firebase lebih dari 10 tahun, jadi saya tidak tahu apakah alat rules terbaru juga melakukan hal seperti ini
      Hal yang benar-benar membantu adalah dukungan bawaan untuk mengganti nama field atau mengubah struktur data saat ada banyak versi klien yang sulit dikendalikan, cara ringan untuk menguji rules tanpa menjalankan database, dan informasi debugging yang lebih baik saat rules gagal di lingkungan produksi
      Setiap kali gagal, seharusnya semua nilai yang diakses oleh rules ikut dicatat, agar kegagalan sementara akibat data yang berubah bisa di-debug
    • Saya cukup sering membela Firebase dan Firestore, tetapi saya setuju dengan semua poin di atas
      Ini adalah model konseptual yang belum dijelaskan dengan cukup baik
      Dalam proyek, saya biasanya mengatakan bahwa setiap collection harus punya profil keamanan seperti publik, data pengguna, publik hanya untuk pengguna terautentikasi, atau khusus admin, lalu memaksakan kategori-kategori itu lewat fungsi security rules alih-alih menulis kondisi kustom untuk tiap collection
      Jika keamanan dipikirkan pada tingkat collection, bukan tingkat field, kemungkinan tercampurnya niat keamanan yang berbeda dalam satu dokumen bisa dikurangi
      Jika sebuah collection bersifat publik, maka ia tidak boleh memuat field yang tidak publik; jika perlu, data bisa disalin dari konteks sensitif ke konteks publik lewat trigger Firestore, tetapi tidak untuk arah sebaliknya
      Masalahnya, niat dari aturan itu sendiri harus didokumentasikan di luar rules, sehingga mudah diterapkan secara keliru, dan dulu menulis pengujian juga sangat menyakitkan, walaupun sekarang sudah jauh lebih baik

  • Ini mengingatkan saya pada “How I pwned half of America’s fast food chains, simultaneously.”: https://mrbruh.com/chattr/
    HN: https://news.ycombinator.com/item?id=38933999

    • Kedua tulisan itu saya yang menulis, dan tulisan kali ini adalah lanjutan dari posting blog tersebut
    • Benar. Kata keenam di posting blog itu adalah tautan ke tulisan tersebut
      After the initial buzz of [pwning Chattr.ai] had settled down, […]

  • Kalau saya tidak salah baca, artinya pada akhir tulisan itu 75% situs yang punya kerentanan seperti ini masih tetap terbuka dan masih bisa di-dump, bukan?
    Gila
    Kadang saya merasa harus ada lisensi untuk boleh menyentuh komputer

    • Banyak perusahaan tidak punya pengembang penuh waktu
      Mereka mengalihdayakan pembuatan situs ke agensi, lalu agensi itu terus mengganti pengembang: awalnya menempatkan pengembang yang bagus, kemudian menyerahkan kontrak ke pengembang yang kurang berpengalaman selama perusahaan klien tidak mengeluh
      Email soal kerentanan kemungkinan diabaikan sebagai spam, atau diteruskan lalu dibiarkan, atau masuk ke antrean rapat PM sebagai item yang akan diperbaiki sambil menagih klien semaksimal mungkin
      Bahkan di bidang yang mewajibkan lisensi profesional pun banyak pemegang lisensi yang tidak kompeten
      Dokter juga punya persyaratan pendidikan dan lisensi yang sangat berat, tetapi dukun medis dan praktisi pengobatan alternatif berlisensi tetap tidak sedikit
    • Sedih, tapi benar, dan jumlahnya mungkin jauh lebih banyak
      Saya sudah berusaha sebaik mungkin dengan mengirim email kustom ke tiap situs, berisi dampak yang mereka alami, cara memperbaikinya, dan cara menghubungi saya
    • Ya. Karena itu saya tidak bisa mempublikasikan daftar situs yang terdampak, agar pelaku jahat tidak langsung mengeksploitasinya
    • Kecuali kebocoran data pribadi bisa membuat perusahaan bangkrut, bagi mereka itu hanya biaya bisnis, dan biaya itu akan dibebankan ke pengguna

  • Ini adalah konsekuensi yang nyaris tak terelakkan dari pilihan murah dan cepat dalam segitiga cheap-fast-good milik PM
    Sayangnya, kekhawatiran sebagian pelanggan dan pengguna tersisih dari pembahasan, dan data pribadi merekalah yang menjadi biayanya
    Dari perusahaan-perusahaan yang tercantum di sini, saya akan berhati-hati terhadap tempat yang membuat keputusan seperti itu tetapi kepemimpinannya tidak berubah
    Sudah berkali-kali terbukti bahwa banyak perusahaan tidak cukup peduli untuk melindungi pelanggan, dan sejarah terus berulang

    • Secara umum saya setuju, tetapi meski sangat sedikit, ada juga contoh yang baik: mereka menghargai laporan itu dan cepat memperbaikinya

  • Saya punya pertanyaan yang sangat mendasar tentang Firebase: apakah sebagian besar aplikasi dalam artikel ini dibangun hanya dengan JavaScript sisi klien yang di-host secara statis, tanpa kode server kustom?
    Maksud saya, apakah backend-nya 100% berupa konfigurasi Firebase yang di-host oleh Google?
    Kalau begitu, saya tidak menyadari bahwa arsitektur seperti ini sudah menjadi begitu umum di situs dengan jutaan pengguna

    • Ya. Entah sepenuhnya di sisi klien, atau meski lewat server tetap diteruskan begitu saja secara naif
      Kalau Anda memakai model keamanan allow by default di API, hal seperti ini pada akhirnya pasti terjadi
      Sayangnya, default yang tidak aman umum ditemukan pada library yang menargetkan developer JavaScript, dan GraphQL juga tampak seperti area yang rawan memunculkan masalah semacam ini
    • Bisa juga campuran
      Firebase juga punya Firebase Functions, yaitu fungsi yang bisa dipanggil di cloud, dan kodenya tidak dibuka ke publik
      Tetapi Firestore dan Firebase Realtime Database sama-sama mengharuskan pengguna menetapkan aturan keamanan; kalau tidak, siapa pun bisa membaca semua data
    • Ini terlihat seperti konfigurasi yang cukup ekstrem, tetapi bisa berjalan jika Anda menulis aturan otorisasi yang tepat pada skema SQL di backend
      Yang penting adalah membuat penulisan aturan otorisasi yang tepat di backend menjadi mudah

  • Melihat hal seperti ini membuat saya merasa beruntung karena sudah lama memilih password manager dan kartu virtual
    Meski begitu, internet jadi terasa semakin menakutkan
    Kebanyakan orang sama sekali tidak tahu seberapa rapuh web dan seberapa tereksposnya mereka

    • Sepertinya ke depan akan makin buruk
      AI agent akan bisa menemukan celah dengan jauh lebih efisien daripada bot, jadi rasanya masa depan yang aneh sedang menunggu
    • Seiring waktu, layanan-layanan makin mempermudah pembuatan website dan mengabstraksikan lebih banyak hal, sehingga developer tidak lagi tahu apa saja yang perlu mereka konfigurasi
    • Password manager saja tidak cukup
      Anda perlu memakai alamat email unik untuk setiap layanan yang Anda daftari
      Itu membatasi dampak saat terjadi insiden, dan juga mencegah pengumpulan informasi publik dengan mencocokkan data dari layanan lain
      Kadang kalau email berbahaya datang ke alamat unik itu, Anda bahkan bisa menyadari adanya kompromi sebelum operator situs mengetahuinya

  • Apakah ada yang tahu lebih banyak soal bagian “program Python dengan sekitar 500 thread mulai memakan memori seiring waktu”?
    Saya juga punya scraper di Python dengan ratusan thread, dan rasanya memang banyak makan memori
    Saya penasaran apakah ada solusi sementara, atau satu-satunya jalan keluar adalah menulis ulangnya dalam bahasa lain

    • Bisa dilakukan di Python, tetapi Anda perlu mendalami bagaimana reference counting di Python berinteraksi dengan thread
      Secara pribadi saya lebih suka proses daripada thread, dan memakai worker pool serta message bus alih-alih shared memory
      Solusi ini juga punya kekurangan dan sedikit overhead, tetapi Anda jadi jauh lebih jarang perlu mengkhawatirkan masalah memori
      Untuk crawler, jumlah prosesnya relatif tetap dan pekerjaan tiap proses independen, jadi model proses tampaknya lebih cocok
    • import multiprocessing as threading
    • Saya tidak tahu masalah pastinya, tetapi sejujurnya Python memang bukan bahasa yang cocok untuk pekerjaan seperti ini
      Menulis ulangnya nyaris merupakan satu-satunya solusi yang praktis
    • Untuk penggunaan seperti ini, yang tepat adalah asyncio
      Ini benar-benar use case yang sangat cocok

  • Bagus
    Saya penasaran bagaimana Anda sampai pada kesimpulan bahwa jumlah pengguna yang terdampak kemungkinan sebenarnya lebih besar
    Dari kelihatannya, untuk beberapa situs seperti situs judi atau Lead Carrot, mungkin ada banyak data akun palsu yang tercampur

    • Setelah meninjau beberapa situs secara manual, terlihat bahwa pemindai otomatis memeriksa tipe data yang dikenal seperti nomor telepon berdasarkan nama variabel, sehingga kurang mampu mengidentifikasi data pribadi non-Inggris dengan baik
      Ini adalah pendekatan yang hanya bekerja baik pada situs berbahasa Inggris
    • Kami sudah memastikan bahwa data situs judi itu bukan palsu, tetapi untuk sisi Lead kami tidak tahu
      Alasan kami mengatakan jumlahnya mungkin lebih besar adalah karena layanan lain yang tidak ada dalam daftar pemindaian juga bisa saja rentan