IDOR untuk Pengambilalihan Akun

May 06 2023

Ringkasan Halo semuanya! Setelah menyelesaikan sertifikasi OSCP saya dan ingin terjun kembali ke karunia bug lagi, saya memutuskan saya mungkin harus menulis beberapa blog berdasarkan temuan saya sebelumnya dengan harapan seseorang dapat menemukannya berguna atau belajar darinya. Penulisan ini memerlukan penemuan dua kerentanan IDOR dan memanfaatkannya untuk membocorkan PII yang mengakibatkan pengambilalihan akun.

Ringkasan

Halo orang! Setelah menyelesaikan sertifikasi OSCP saya dan ingin terjun kembali ke karunia bug lagi, saya memutuskan saya mungkin harus menulis beberapa blog berdasarkan temuan saya sebelumnya dengan harapan seseorang dapat menemukannya berguna atau belajar darinya.

Penulisan ini memerlukan penemuan dua kerentanan IDOR dan memanfaatkannya untuk membocorkan PII yang mengakibatkan pengambilalihan akun . Pengambilalihan akun dimungkinkan karena cara perusahaan menangani proses pemulihan akun dan sebenarnya merupakan salah satu temuan pertama saya ketika saya pertama kali memulai bug bounty. Sensasi menemukan ini membuat saya terus belajar lembur.

Apa IDOR yang saya bicarakan ini?

Insecure Direct Object Referencepaling sering disingkat "IDOR" adalah jenis kerentanan yang dapat dikategorikan dalam access control. IDORsterjadi dalam aplikasi saat aplikasi menggunakan input yang disediakan pengguna untuk mengakses objek secara langsung tanpa melakukan pemeriksaan apa pun untuk melihat apakah pengguna memiliki izin otorisasi yang benar. Paling sering dikaitkan dengan eskalasi hak istimewa horisontal IDORsdapat menimbulkan efek merusak pada aplikasi dan basis penggunanya.

Contoh utama dari parameter tipikal yang biasanya rentan terhadap IDOR meliputi: id= | userID= | messageId=. Memahami alur aplikasi dapat memudahkan untuk mengidentifikasi jenis masalah ini.

Gambar di atas mengilustrasikan dua skenario. Scenario Adi sebelah kiri menyampaikan aplikasi yang lebih aman di mana users 2 and 3mencoba mengakses catatan sensitif yang bukan miliknya, namun itu menghasilkan sebagaimana access denied errormestinya.

Scenario Bdi sebelah kanan, bagaimanapun, menggambarkan aplikasi yang rentan di mana aktor ancaman dapat mengeluarkan permintaan ke server web dan mengambil catatan sensitif untuk setiap pengguna tertentu tanpa ditolak aksesnya.

Jika Anda ingin membaca lebih lanjut tentang IDORs Vickie Li memiliki posting blog yang luar biasa yang menyoroti dasar-dasar jenis kerentanan ini. Anda dapat memeriksanya di sini .

Contoh di atas adalah contoh yang sederhana, namun bergantung pada aplikasinya, Anda mungkin dapat memanfaatkan informasi sebelum melaporkannya untuk meningkatkan dampaknya, yang selalu ingin saya lakukan.

Sekarang kita memiliki gagasan tentang apa IDORsitu, di mana mereka dapat ditemukan serta dampaknya, mari selami salah satu temuan awal saya! :)

Pengintaian

Meskipun masalah telah diperbaiki, saya tidak dapat memperoleh izin untuk pengungkapan publik secara penuh sehingga target akan dirujuk sebagai: example.com. Seperti halnya target apa pun, bergantung pada scope, pencacahan subdomain adalah kunci untuk memperluas permukaan serangan. Namun, pencacahan subdomain bukan satu-satunya cara untuk memperluas permukaan serangan karena kami juga dapat menganalisis JavaScriptfile untuk informasi sensitif. Dalam kasus ini saya memutuskan untuk memulai dengan menggunakan quick Google Dorkuntuk melihat apakah saya dapat menemukan subdomain yang menarik sebelum menggunakan alat otomatis untuk hasil yang lebih banyak.

Google Dork:site:*.example.com

Example.commemiliki sekitar 36 subdomain sehingga jumlah subdomain yang cukup bagus untuk digunakan!
Melihat melalui mereka satu per satu saya mencatat dua subdomain yang memiliki banyak fungsi. Saya menghabiskan waktu sekitar satu atau dua hari untuk menelusuri subdomain ini dan menguji berbagai fitur sambil mengingat beberapa fitur yang lebih menarik yang khusus untuk aplikasi tersebut. Misalnya, aplikasi memiliki fitur di mana Anda dapat membuat tiket untuk menerima dukungan dari staf dalam berbagai kategori seperti “Masalah Pembayaran”.

Bug Awal

Saya memutuskan untuk memulai dengan menganalisis cara kerja proses pendaftaran dan masuk - fitur inti yang diterapkan di hampir semua situs web saat ini. Alur pendaftaran aplikasi web dapat diringkas sebagai:

Pengguna mendaftar melalui email
Pengguna diminta untuk mengatur a PIN No.dan a security questionsebelum proses pembuatan akun dapat diselesaikan. Ini hanya dapat diatur sekali dan tidak dapat diubah
Pengguna diminta untuk mengonfirmasi email sebelum mereka dapat masuk

Menggunakan account A, saya bersemangat Burpsuitedan mulai menguji fitur ticketing dan membuat dua akun pengujian diikuti dengan pembuatan beberapa tiket di bawah kategori dukungan yang berbeda untuk tujuan pengujian. Melihat ke HTTP Historydalam Burpsuiteada beberapa panggilan menarik yang dilakukan.

Berikut ini POST requestdimulai saat membalas anggota staf di tiket terkait dengan klaim hadiah:

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

Jadi untuk menyimpulkan temuan sejauh ini:

Setelah mendaftar setiap pengguna harus membuat PIN No.dansecurity question
Situs web ini memungkinkan pengguna membuat tiket dukungan untuk bantuan
Untuk menerima dukungan, pengguna perlu merespons dengan mereka PIN No.dan security question answeruntuk hal-hal sensitif seperti pemulihan akun, klaim hadiah, dan masalah pembayaran
IDORkerentanan yang ditemukan dalam sistem tiket memungkinkan lawan untuk berkomentar dalam tiket dukungan apa pun tanpa menjadi pemilik tiket atau anggota staf

Jadi jika saya dapat memposting komentar pada tiket apa pun tanpa menjadi pemilik atau memiliki hak istimewa anggota staf… tentunya ini berarti saya juga dapat membaca tiket apa pun, bukan?

Saya menangkap permintaan GET berikut dalam upaya untuk melihat tiket milik account Avia account B, namun, itu menyebabkan 403kesalahan ilegal! Jadi, saya dapat menulis ke tiket dukungan apa pun yang diberikan tetapi tidak dapat membaca isinya. Pada titik ini saya benar-benar ingin menemukan cara yang memungkinkan untuk melanjutkan ini lebih jauh.

DAPATKAN Endpoint untuk membaca tiket di Aplikasi Web

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

Saat mencoba mengeksploitasi fitur tiket, saya menemukan permintaan berikut;

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

Membocorkan Konten Tiket melalui API di Aplikasi iOS

Selama pengintaian awal, saya telah melihat beberapa APIpermintaan dikirim saat mengambil informasi profil, lebih jauh lagi, target juga memiliki mobile appcakupan. Sangat mungkin bahwa meskipun membaca tiket pengguna lain di aplikasi web itu sendiri tidak dimungkinkan, hal itu dapat dicapai melalui aplikasi seluler karena dapat menggunakan yang berbeda API version/endpointdari aplikasi web.

Mengaktifkan Burpsuitedan menavigasi ke sesi tiket dalam Aplikasi iOS, saya tiba di titik akhir berikut:

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

Jadi sekarang saya telah menemukan dua bug - dimungkinkan untuk menulis ke tiket apa pun DAN melihat konten tiket apa pun milik pengguna lain.

Eskalasi Tiket Baca IDOR > Pengambilalihan Akun

Pada titik ini saya memiliki cukup banyak elemen yang diperlukan untuk mencapai pengambilalihan akun. Karena tiket apa pun dapat dibaca, pengambilalihan akun pengguna dapat dilakukan melalui langkah-langkah berikut:

Kunjungi /api/v1/support-tickets/234567/poststitik akhir dan kirimkan ke intruderuntuk Burpsuitemenghitung tiket sebanyak mungkin
Grepuntuk kata kunci seperti Pin Numberatau Security Questiondari tanggapan
Buat akun baru di situs web dan buka tiket di bawahaccount recovery
Anggota staf yang dialokasikan akan menanyakan nama pengguna akun yang ingin Anda pulihkan bersama dengan dan security question answer, PIN No.yang semuanya dapat dibocorkan melalui IDOR kedua yang ditemukan; dengan demikian, mengakibatkan pengambilalihan akun.

Meskipun pengambilalihan akun sudah tercapai, IDOR penulisan tiket juga dapat dimanfaatkan. Nama pengguna staf diawali dengan nama perusahaan misalnya example-John. Seorang musuh bisa;