Kesalahan konfigurasi SendBird yang Tak Terungkap

Pada kolaborasi perburuan bug acak dengan tim saya ( thaivu , lamscun , thefool45 , fergustr4n ), kami telah bertemu dengan target pribadi acak seperti biasa. Dalam perjalanan mengeksploitasi target, saya menemukan bahwa target kami telah mengimplementasikan fitur chatting menggunakan layanan dari platform pihak ketiga. Setelah melakukan beberapa google dork, saya menemukan bahwa fitur chatting target kami adalah produk dari SendBird— “platform API interaksi terkemuka yang dipercaya oleh aplikasi digital modern seperti Paypal, Yahoo, Reddit, Delivery Hero, dan Hinge untuk dengan mudah menyematkan obrolan, suara, dan video real-time ke dalam aplikasi mereka”. Itu menarik minat saya dan saya memutuskan untuk meneliti lebih lanjut tentang cara kerjanya untuk melihat apakah akan ada tindakan tersembunyi yang dapat saya lakukan atau konfigurasi tersembunyi yang mungkin terlewatkan oleh pengembang…
1 — Pelajari produk dan dokumen pihak ketiga
Saya langsung pergi ke Situs Utama SendBird untuk mengetahui apa yang akan saya hadapi. Portal Pengembang SendBird menyediakan dokumen yang sangat jelas dan berguna bagi pengembang untuk setiap jenis produk (panduan penggunaan, contoh API, Catatan, Rekomendasi,…).
Ada beberapa catatan menarik pada saat saya memulai penelitian saya ( Beberapa mungkin sudah usang saat Anda membaca blog ini ):
- Host Aplikasi SendBird Pelanggan akan berbentuk “https://api-{application_id}.sendbird.com”
- Sendbird menyediakan berbagai opsi kontrol akses dan beberapa diaktifkan secara default untuk menghindari kesalahan tak terduga saat membuat aplikasi sampel.
- Pelanggan tidak dapat mengubah sendiri pengaturan Daftar Kontrol Akses. Mengubah pengaturan ACL hanya dapat dilakukan oleh anggota tim Rekayasa Solusi Sendbird .
- Secara default, Pengaturan Keamanan Aplikasi SendBird untuk “ pengguna tanpa token akses ” adalah “Baca & Tulis” — obrolan dan “Panggil & Jawab” — panggilan.
Setelah mendapatkan ikhtisar tentang cara kerja SendBird, saya kembali ke target saya untuk menggunakan, memainkan fungsi untuk memverifikasi dengan apa yang telah saya baca di atas. Saya mengonfirmasi bahwa ada API dengan host dengan pola yang sama seperti "api-{application_id}.sendbird.com" dan dengan jalur yang sama seperti yang saya lihat di dokumen. Kemudian, saya segera menggunakan sesi API saat ini untuk mencoba berbagai API di dokumen API. Secara acak, saya memilih API yang mencantumkan pengguna di Aplikasi SendBird "GET /v3/users/" dan yang mengejutkan, server merespons kembali dengan semua pengguna terdaftar !!! Melompat kegirangan, saya memberi tahu semua rekan satu tim saya untuk memeriksanya.

Kami mencoba dan mengetahui bahwa sesi pengguna kami dapat memanggil berbagai API dan melakukan banyak tindakan pada pengguna, saluran, pesan, … dalam Aplikasi SendBird dari target kami. Itu benar-benar kontrol akses yang rusak besar karena kesalahan konfigurasi ACL !!!
Namun, ada satu hal yang tidak dapat kami pahami yaitu dari mana "Session-Key" berasal dan bagaimana cara membuatnya karena kami tidak dapat melihat nilai "Session-Key" dalam respons apa pun?

Kembali ke Dokumen SendBird untuk membaca lebih lanjut dan melakukan lebih banyak, kami mengetahui beberapa hal lagi:
- “Secara default, server Sendbird dapat mengotentikasi pengguna hanya dengan ID pengguna yang unik”
- “Jika tidak ditemukan ID pengguna yang cocok, server membuat akun pengguna baru dengan ID pengguna”
- “Otentikasi pengguna dapat dilakukan hanya dengan ID pengguna mereka sendiri, tetapi juga dengan token akses atau token sesi”
- Target kami sebagai ClientApp dapat mengautentikasi ke Server SendBird melalui WebSocket dengan format URL Upgrade WebSocket sebagai: “ wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token }”
- Klien SendBird dari target kami diautentikasi ke server SendBird melalui WebSocket.
- "Kunci-Sesi" akan dikirim ke klien melalui Pesan WebSocket setelah panggilan klien Tingkatkan URL WebSocket seperti di atas
- Klien SendBird dari target kami dapat mengautentikasi hanya dengan ID pengguna dengan " access_token=null"
- Kami juga menemukan API tersembunyi untuk mengautentikasi melalui USER ID hanya sebagai cara WebSocket di file JS: “ POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — body: {“ app_id”:”<application_id>”} ”
3 — Cara melakukan pemeriksaan besar-besaran kerentanan pada Instans SendBird lain di target yang berbeda
- Kami harus mengonfirmasi bahwa target kami mengimplementasikan SendBird dalam aplikasi mereka dengan merayapi, melakukan penemuan konten pada target dan grep untuk kata “sendbird” dan regex ID Aplikasi SendBird “ [0–9A-F]{8}-[0– 9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12} ”
- Setelah mengonfirmasi target yang mengimplementasikan SendBird dan mendapatkan ID Aplikasi SendBird, kami memeriksa apakah Pengaturan Keamanan Aplikasi SendBird untuk “pengguna tanpa token akses” salah konfigurasi atau tidak dengan melakukan login/pembuatan pengguna anonim menggunakan cara berikut:
- wss://ws-{application_id}.sendbird.com/?user_id={user_id}&ai={application_id}&access_token={access_token}
- POST https://api-{application_id}.sendbird.com/v3/users/{user_id}/login — body: {“app_id”:”<application_id>”}
- https://www.postman.com/sendbird/workspace/sendbird-platform-api/overview
- https://sendbird.com/docs
- Membocorkan Informasi Sensitif Pengguna
- Buat saluran obrolan (tanpa membuat liga baru)
- Kelola saluran obrolan
- Perbarui profil obrolan pengguna
- Perbarui konfigurasi saluran grup
- Mengobrol dengan pengguna mana pun
- Penyerang dapat mengedit/menghapus pesan dari pengguna mana pun saat menjadi peran operator dari saluran yang dibuat sendiri.
- Penyerang dapat memperbarui detail, konfigurasi saluran saat menjadi anggota saluran apa pun.
- Seperti yang didokumentasikan, satu Pengguna SendBird hanya dapat bergabung dengan batas 2000 saluran grup, penyerang dapat membuat 2000 saluran grup dan menambahkan semua pengguna di Aplikasi SendBird ke saluran tersebut. Akibatnya, semua pengguna tidak dapat bergabung dengan saluran SendBird setelah itu, yang dapat menyebabkan Denial of Service.
- …
- SendBird memiliki lebih banyak dokumen tentang rekomendasi keamanan, terutama tentang ACL.
- SendBird sekarang memungkinkan pelanggan mereka untuk mengubah ACL sendiri.
4. Jika langkah nomor 2 tidak berhasil, kami akan secara manual menelusuri fungsi pada target, mendapatkan Sesi Pengguna SDK dengan cara biasa yang dilakukan target dan memeriksa kesalahan konfigurasi ACL seperti langkah 3.
5. Otomasi semuanya!
Referensi untuk API SendBird untuk diperiksa:

Setelah memeriksa kerentanan pada Aplikasi SendBird yang berbeda, kebanyakan dari mereka rentan terhadap kesalahan konfigurasi ACL. Namun, berdasarkan aplikasi yang berbeda dengan kebutuhan dan dampak bisnis yang berbeda, tingkat keparahan juga harus dipertimbangkan berbeda (dari Sedang — Kritis).
Dampaknya beragam:





Kolaborasi hebat dengan thaivu , lamscun , thefool45, fergustr4n $$$$

### Pembaruan dari SendBird