Untuk beberapa waktu sekarang, saya telah mencari celah pada platform HackerOne, dan telah mengalokasikan sejumlah waktu di luar pekerjaan utama untuk memeriksa program favorit dan baru saya. Berkali-kali saya menemukan kerentanan XSS berbasis cookie, yang akan menjadi karakter utama artikel ini. Jenis kerentanan ini terjadi ketika nilai parameter cookie tercermin pada halaman. Secara default, mereka dianggap sebagai XSS sendiri kecuali jika kita, pada gilirannya, membuktikan bahayanya. Sebenarnya, hari ini saya akan memberi tahu Anda bagaimana cara mengeksploitasi kerentanan XSS berbasis cookie, dan saya juga akan memberikan contoh dari pengujian satu perusahaan di mana saya menerima total $ 7300 untuk studi ini.
Untuk menjalankan javascript di sisi pengguna, Anda perlu menemukan cara untuk mengatur cookie dan, jika perlu, memikat korban ke halaman di mana, pada gilirannya, cookie tertanam. Kemungkinan cara untuk mengeksploitasi bug ini:
⠀
1. Injeksi CRLF. Kerentanan ini terjadi ketika tidak ada verifikasi yang tepat dan pemblokiran karakter pemecah baris. Kami dapat menerapkan header Set-cookie sebagai tanggapan dengan nama yang diinginkan serta nilai cookie dan mengaturnya di browser. Contoh kehidupan nyata: Injeksi CRLF yang licin di twitter.com dalam arahan ulang - https://twitter.com/login?redirect_after_login=/jjjkkk 嘊 嘍 Set-Cookie: jjjjj = a; domain = twitter.com
Laporan tentang jenis kerentanan ini dapat dibaca di HackerOne
hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection2. Kerentanan XSS pada subdomain. XSS harus dapat diakses oleh publik dan terletak di wildcard * .vulnerabledomain.com. Untuk banyak program karunia bug, subdomain berada di luar cakupan, yaitu, dalam kebanyakan kasus, bug tidak diterima sama sekali, atau diterima dengan tanda "tidak memenuhi syarat untuk karunia". Dalam kasus seperti itu, Anda tidak boleh mundur, tetapi demi terhubung dengan XSS berbasis cookie, Anda dapat menginvestasikan waktu Anda dalam mencari XSS untuk mendapatkan hadiah. Jika XSS terdeteksi, kami dapat mengatur atau menghapus cookie menggunakan fungsi document.cookie.
Peningkatan dampak: Seringkali, korban mempercayai domain utama dari vulnerabledomain.com lebih dari, misalnya, jira.vulnerabledomain.com, dan bahkan dengan URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com . Kemungkinan besar ia akan beralih ke domain utama daripada ke subdomain jika subdomain ini tidak dikaitkan dengan akun pribadi atau otorisasi. Berdasarkan hal tersebut di atas, kita dapat menggunakan fungsionalitas pengalihan di-situs untuk mengarahkan kembali ke
vulnerabledomain.com/login?redirectUrl=https : //jira.vulnerabledomain.com/path subdomain untuk efek yang lebih baik.
Jika korban memiliki sesi aktif, pengalihan akan otomatis, jika tidak, diperlukan otorisasi. Ketika pengguna mengklik tautan semacam itu, cookie juga akan dipasang dari subdomain tempat Reflected XSS hadir, dapat dikirim lebih jauh ke hulu - ke halaman dengan XSS berbasis cookie, tempat eksploit dapat bekerja, yang pada gilirannya, akan menangkap nilai CSRF dari token tersebut. dan lengkapi permintaan untuk mengubah alamat email. Dengan demikian, kombinasi dari dua kerentanan XSS dapat menyebabkan pengambilalihan akun jika tidak ada masalah terkait, seperti konfirmasi tambahan tentang perubahan kata sandi email atau kode dari kotak surat lama.
3. Deteksi file uji yang memungkinkan cookie diatur. Cukup dengan membuka alat pendeteksi konten (dirb, dirserach, dll), mulai menggali, dan jika pengembang lupa melakukan pembersihan, Anda dapat menemukan file-file tersebut.
Baru-baru ini, saya menemukan halaman html servlet uji yang memungkinkan untuk memasang cookie dengan nama dan nilai yang berubah-ubah. Perlindungan terhadap permintaan POST, tentu saja, tidak ada, jadi jika korban akan mengunjungi eksploitasi CSRF (atau Anda dapat mengubah POST menjadi GET), adalah mungkin untuk memasang cookie di browsernya.
Bug ini dikualifikasikan sebagai alternatif pengganti injeksi CRLF, diperbaiki dengan menghapus / contoh / dan membayar $ 150 untuk bug dengan tingkat keparahan rendah. Meskipun trivia h1 disampaikan media, para pengembang masih cenderung percaya bahwa ini adalah keparahan rendah.
4. Man in the middle attack (MITM). Metode ini hanya dapat diterapkan jika tidak ada bendera aman pada cookie. Jika Anda tidak tahu jenis bendera apakah itu atau hanya ingin menyegarkan ingatan Anda, saya menyarankan Anda untuk melihat presentasi keamanan Cookie dengan OWASP London 2017
www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf .
Untuk serangan yang berhasil, perlu bahwa korban berada di jaringan penyerang atau bahwa resolusi dns dapat terpengaruh. Untuk memeriksa kerentanan, perlu:
1) host file index.php dengan konten berikut:
<?php if ($_SERVER['HTTP_HOST'] == 'non-existed-subdomain.vulnerabledomain.com') { setrawcookie("VID",'\'+alert(123123123)+\'', time()+36000, "/", ".vulnerabledomain.com",0,1); } ?>
2) Tambahkan baris berikut ke file / etc / hosts / Anda: 127.0.0.1 non-existed-subdomain.vulnerabledomain.com
3) Kunjungi non-existed-subdomain.vulnerabledomain.com dan setelah itu buka halaman tempat cookie dipantulkan.
Contoh indah eksploitasi MITM di e.mail.ru adalah https://hackerone.com/reports/312548, seperti yang Anda lihat, MITM sudah cukup untuk membuktikan bahaya kecil kerentanan, tetapi penghargaan itu tidak cocok dengan tingkat Stored XSS, karena hanya diperlihatkan tingkat Mode operasi "Lokal", yaitu, bukan "in-the-wild". Jika peneliti menghabiskan sedikit waktu mencari injeksi XSS atau CRLF (yang tak terhitung jumlahnya) terletak di * .mail.ru, hadiahnya bisa sedikit meningkat.
Tetapi tidak semua program hackerone menerima XSS berbasis cookie melalui MITM. Jika pengecualian ruang lingkup mengatakan "Self XSS", maka operasi ini dapat dianggap sebagai Self XSS dan mengatur informatif atau t / a, yang tidak selalu menyenangkan. Sekarang saya akan berbicara tentang kejadian serupa yang terjadi pada saya selama perburuan berikutnya di platform.
Saat menguji situs, saya tiba-tiba melihat bahwa nilai cookie yang dihapus tercermin di salah satu subdirektori situs. Hal pertama yang saya lakukan adalah memeriksa tampilan karakter '"/ <>. Ternyata hanya karakter <> yang difilter, dan ini memberitahu kita bahwa kita tidak dapat melampaui, tetapi juga menjadi jelas bahwa karakter lain tidak disaring. Tanpa berpikir dua kali, kami menerapkan '-alert (document.domain) -' dan js dieksekusi.
Karena pengembang tidak memberikan cookie bendera aman, dalam hal ini metode MITM berfungsi. Diputuskan untuk mengirim laporan ke program dengan dampak sebagai berikut:
Staf HackerOne (triager) menjelaskan bahwa ini adalah XSS diri dan saya harus berusaha lebih keras:
Setelah itu, saya mulai menjelajahi situs dan mencoba menemukan injeksi CRLF atau XSS untuk membuktikan bahayanya.
⠀ Saya harus memperluas daftar subdomain dengan bantuan kamus besar, mengikis subdomain dengan sertifikat SSL dan menggunakan beberapa trik lainnya. Hasilnya tidak lama datang, karena sebagian besar alat saya jalankan dengan VPS. Dari waktu ke waktu, bug lain juga terdeteksi di sepanjang jalan, yang saya laporkan, membuat in-scope dari out-of-scope, jika perlu. Saya menemukan banyak Pengalihan Terbuka dan bahkan bug Kontrol Akses yang Tidak Layak sebesar $ 5.000, tetapi saya masih tidak bisa menangkap kerentanan yang diperlukan untuk bundel tersebut. Bug yang disebutkan di atas cukup menarik dan berbahaya, seluruh subdomain diambil offline segera setelah laporan, mungkin di masa depan saya akan membuka laporan di hackerone.com/w2w, jika program menjadi publik.
Seminggu kemudian, hasil skrip untuk mendeteksi konten diperiksa, di mana titik akhir / verifikasi ditemukan, yang pada awalnya saya tidak menganggap penting, tetapi masih menetapkan skrip di atasnya - subdirektori / verifikasi / login ditemukan. Setelah transisi, halaman /verification/login/?redirect_uri=https://vulnerabledomain.com ditampilkan, yang dialihkan ke nilai redirect_uri setelah login atau segera dialihkan jika ada sesi. Setelah terbang ke penyusup, bypass perlindungan redirect terbuka ditemukan - vulnerabledomain.com@anotherdomain.com. Mencoba melepas bug ke XSS - javascript: lansiran (1) gagal, javascript: lansiran (1) // juga. Tetapi payload javascript: // https: //vulnerablesite.com/%250A1? Peringatan (1): 0 shot, karena karena keberadaan
kerentanan.big , parameter melewati validasi daftar putih.
Setelah menggerakkan mouse dengan panik melalui jendela notifikasi (saya selalu melakukannya), saya segera mulai bekerja pada XSS berbasis cookie saya. Menggunakan javascript: https: //vulnerabledomain.com/%0A1? Dokumen% 2ecookie% 20% 3d% 20% 27SID% 3d137gf6g67f76fg6766123% 5c% 27-lansiran% 28dokumen% 2domain% 29-% 5c% 27% 3b% 20 expire% 3dFri% 2c% 203% 20Ag% 202019% 2020% 3a47% 3a11% 20UTC% 3b% 20path% 3d% 2f% 3b% 20domain% 3d% 2evulnerabledomain% 2ecom% 3b% 27% 3a0 Cookie berhasil disimpan di * .vulnerabledomain.com . Setelah pergi ke halaman dengan cookie, peringatan berharga berangkat! XSS ganda, tepuk tangan! :) Saya melengkapi laporan dan menunggu jawaban.
Pada hari yang sama, "Tangkapan bagus" terbang dari triadger (jika Anda bisa menyebutnya begitu), dan bayaran dibayarkan. Tuhan memberkati perusahaan yang membayar triase!
Untuk XSS berbasis DOM, yang saya gunakan untuk memasang cookie, hadiah juga datang.
Hasil Tes
$ 1000 + $ 1000 + $ 200 (OR) + $ 100 (OR) =
$ 2300Program ini telah berfungsi selama lebih dari satu tahun, tetapi dalam waktu kurang dari sebulan saya dapat mengambil tempat pertama di dalamnya dan melakukan sedikit pengujian - saya mencoba untuk fase mayoritas endpoint, mengevaluasi reaksi mereka, memahami bagaimana situs bekerja dan bahkan menguji aplikasi desktop. Program karunia bug ini telah menjadi salah satu yang paling dicintai di HackerOne. Saya harap Anda juga suatu hari nanti menemukan yang sama! :)
Selain itu, program inilah yang memberi saya dorongan baru (mail.ru - yang pertama), - dengan itu saya mendapat 2500 reputasi (halo hoodie) dan menempati posisi ke 36 di papan peringkat untuk reputasi dalam 90 hari, yang seharusnya memberikan perolehan baru . Meskipun tampaknya cangkok tiba terlepas dari keberadaan di leaderboard, saya sering membatalkan cangkokan lama dan menunggu yang baru sesuai.
Singkat singkat
- XSS berbasis cookie sepenuhnya dapat dieksploitasi. Jika Anda mencoba dan menggali sedikit lebih dalam, Anda bisa mendapatkan hadiah alih-alih n / a, menghancurkan sinyal dan reputasi -5.
- Jika program sudah tua, ini tidak berarti bahwa tidak akan ada kerentanan di dalamnya. Jika buah-buahan menggantung di pohon untuk waktu yang lama, buah-buahan yang menggantung rendah akan dipetik dan diambil segera (pengambilalihan subdomain, dll.). Buah-buahan lain terus menggantung, tetapi lebih tinggi. Untuk mendapatkannya, Anda harus berusaha.
- Terkadang lebih baik berfokus pada satu program untuk waktu yang lama, menemukan sebanyak mungkin kerentanan dan memantaunya. Lebih baik menemukan program yang Anda sukai dan merusaknya.
- Kegigihan dan keinginan untuk memahami cara kerja aplikasi web, serta fungsi-fungsi tertentu dan interaksinya satu sama lain, adalah kunci untuk berhasil mencari kerentanan dalam karunia bug.
Jika Anda ingin terus mengikuti artikel dan berita terbaru saya, saya menyarankan Anda untuk berlangganan saluran telegram / twitter, tautan yang dapat ditemukan di bawah ini.