Duplicate dalam konteks bug bounty, merujuk pada laporan yang
menggambarkan masalah yang sama dengan laporan sebelumnya. Platform bug bounty
biasanya memungkinkan program untuk menetapkan status laporan sebagai “duplikat”
untuk memberi tahu bug hunter bahwa masalah tersebut telah dilaporkan
sebelumnya. Biasanya hadiah/bounty hanya akan di berikan oleh orang yang memberi
laporan kerentanan pertama.
Dari pada temuan ini sia sia karena tidak
mendapatkan apa pun dari kerentanan ini, maka dari itu saya akan menuliskan
proses pengalaman saya mendapatkan kerentanan ini, yang di-harapkan dapat
membantu para bug hunter untuk terus mebaca writeups agar terus berkembang. 
Misalnya, Anda adalah pengguna dengan ID 1111 di sebuah website bernama redacted.com. Ketika Anda ingin melihat data Anda di dalam website, URL yang ditampilkan mungkin seperti ini: redacted.com/userid/data. Jadi, data Anda akan ditampilkan dengan URL redacted.com/1111/data. Namun, jika Anda mengubah parameter user ID menjadi 55555, dan mengakses URL redacted.com/55555/data, Anda dapat melihat data pribadi pemilik user ID 55555 tanpa harus melewati proses otorisasi terlebih dahulu. Ini adalah celah keamanan yang disebut IDOR. Kerentanan ini terjadi karena aplikasi tidak memverifikasi atau membatasi akses ke objek (dalam hal ini, data pengguna) berdasarkan ID objek yang langsung terlihat di URL. Untuk memahami IDOR lebih lanjut bisa kunjungi link ini
Apa itu IDOR (Insecure Direct Object References)
Web atau aplikasi yang tidak memvalidasi atau mengotorisasi akses terhadap objek secara langsung, memungkinkan penyerang untuk mengakses data yang seharusnya tidak dapat diakses.
Affacted Target
Target kali ini adalah private program di salah satu platoform bug bounty, dan meskipun saya tidak bisa menyebutkan nama target-nya, yang ter-penting kita mengerti alur dari writeups/temuan ini. Kita sebut target website nya sebagai 'redacted.com'. untuk tema dari target ini yaitu “travel – trips – liburan – perjalanan”.
Sebelum menemukan bug atau kerentanan
Langkah pertama dalam mencari bug pada API yaitu memahami flow pada website nya dengan melakukan berbagai request dan disini secara tidak sadar sudah melakukan 100k+ request hanya untuk memahami flow atau cara website redacted.com bekerja.
IDOR Pertama Pada Endpoint Checkout
Setelah memahami flow pada website nya saya melihat parameter user id pada fitur checkout yang di dalam object passenger dan disini membuat saya tertarik pada parameter user id. Saya rasa jika user id nya berupa nomor penyerang akan dengan mudah mengidentifikasi IDOR pada parameter user id tersebut akan tetapi disini user id nya sudah di ubah menjadi UUID (Universal Unique Identifier) singkatnya yaitu cara khusus untuk memberikan identifikasi unik kepada sesuatu, seperti file atau user id, sehingga tidak ada yang serupa dan susah untuk ditebak. Jadi yang awal nya user id penyerang = 345 menggunakan UUID menjadi text random yang tidak memiliki pola seperti ini b4c647ca-974f-45c9-8d02-832febb9d287.
Lanjut ke metode, lakukan checkout atau order salah satu trips/travel seperti biasa untuk mendapatkan endpoint yang rentan yang didalam endpoint tersebut terdapat pada parameter user-uuid dan dibawah ini didapatkan request endpoint pada checkout trips/travel. Untuk request pada endpoint checkout nya seperti ini:
Disana terdapat parameter uuid yang berarti user id kita sebut aja parameter ini menjadi user-uuid, kemudian pada object passenger berdasarkan flow dari website nya, object passenger disini adalah orang/user yang ikut serta dalam melakukan travel/trips ini, bisa disebut juga sebagai guest.
Saya langsung membuat 2 akun yaitu akun attacker dan victim untuk mencoba apakah saya bisa memaksa-kan user lain untuk menjadi guest dari travel yang saya checkout tanpa persetujuan dari user tersebut, dengan mengubah parameter user-uuid pada object passenger yang terdapat pada endpoint checkout.
Setelah saya membuat 2 akun saya mencatat user-uuid akun korban kemudian pada akun penyerang langsung melakukan checkout untuk mendapatkan endpoint diatas. Ketika mendapatkan endpoint diatas penyerang langsung mengubah user-uuid pada ke-dua object passenger dari user-uuid penyerang menjadi user-uuid korban.
Dan IDOR berhasil dilakukan, akun korban dengan paksa (tanpa interaksi dan persetujuan) menjadi guest dari akun penyerang seperti foto dibawah:
tetapi dikarenakan user id nya berupa UUID maka kerentanan ini masih belum valid untuk dilaporkan karena UUID nya sangat sulit di tebak dan user-uuid korban harus di temukan oleh penyerang untuk bisa melakukan eksploitasi pada bug ini
IDOR Kedua Pada Endpoint Travel-Event
Ketika mencari beberapa endpoint untuk menemukan user-uuid dari user korban saya tidak menemukan satu endpoint pun yang menampilkan user-uuid korban, beberapa endpoint yang telah saya cek yaitu endpoint komentar/review hotel dari user lain, live chat kepada user lain, rating hotel dari user lain, dll.
Kemudian saya menemukan fitur Travel-Event pada fitur ini mengajak user lain untuk mengikuti travel pada suatu acara yang dibuat oleh pembuat travel-event.
Pada fitur ini terdapat fitur untuk membuat group travel atau menambahkan user lain sebagai participant dari travel-event yang dibuat tampilan nya seperti dibawah ini:
Dan untuk endpoint seperti ini: https://redacted.com/api/travel-events/{id-events}/add dan pada body request nya:
Terdapat parameter email yang rentan di dalam object participants, disini saya coba ubah dari email attacker: rhymeus@attacker2261.com menjadi email victim dengan email rhymeus@victim.com
Dan lagi lagi berhasil melakukan IDOR yang ke dua pada fitur Travel-Event hanya menggunakan email untuk mendapatkan user-uuid dari korban yang terdapat pada parameter participantId:
Menggabungkan IDOR untuk mendapatkan dampak yang lebih tinggi
- Buat Travel-Event di akun penyerang
- Tambahkan participant kemudian pada parameter email, ubah menjadi email valid dari akun lain.
- Lakukan GET pada endpoint ini untuk mendapatkan user-uuid dari akun korban https://redacted.com/api/travel-events/{id-events}/invitation dan penyerang sudah memiliki user-uuid milik korban untuk eksploitasi berikutnya.
- Pada eksploitasi berikutnya, lakukan proses checkout seperti biasa dan pada akhir proses checkout terdapat parameter passenger yang berisi user-uuid, dan kita ubah ke dua parameter user-uuid penyerang ke user-uuid korban.
- Dapat dilihat akun korban secara paksa menjadi guest dari akun penyerang tanpa interaksi dari akun korban.
- Kemudian, pada langkah terakhir, lakukan GET pada endpoint ini untuk melihat informasi pengguna dan perusahaan yang telah menjadi tamu dari akun penyerang: https://redacted.com/api/trips/{id-travel} dan akan muncul response seperti ini:
Dampak Kerentanan
Memungkinkan penyerang untuk mengakses detail informasi pribadi dan perusahaan melalui email korban
Timeline
- Report: 14 Oktober 2023
- Triage: 14 Oktober 2023
- Status: Duplicate
- Reward: None
Demikian writeup yang saya buat untuk kesempatan ini. Saya berharap writeup ini dapat memberikan manfaat dan motivasi bagi teman-teman bug hunter yang juga bekerja keras dalam mencari dan melaporkan bug pada sebuah sistem. Jika ada kekurangan atau kesalahan, saya sangat mengharapkan masukan dan kritik dari teman-teman bug hunter lainnya agar tulisan ini dapat lebih baik kedepannya.