Pada Maret 2020, pandemi dimulai, jadi saya punya banyak waktu luang. Mereka perlu dikelola dengan bijak, dan saya memutuskan untuk mendapatkan sertifikasi OSWE. Setelah lulus ujian pada 8 Agustus, saya mengambil cuti beberapa minggu, dan kemudian pada pertengahan September saya berkata pada diri saya sendiri: “Kamu tahu apa? Nama saya tidak muncul di Hall of Fame Facebook pada tahun 2020, meskipun itu terjadi di sana setiap tahun. Saatnya menyelesaikan masalah ini! ”.
Saya tidak pernah menemukan kerentanan di salah satu subdomain Facebook, jadi saya mempelajari artikel dan menemukan satu posting tentang subdomain Facebook yang menarik perhatian saya. Ini adalah posting yang bagus, saya sarankan untuk membacanya: [Bug konversi HTML ke PDF mengarah ke RCE di server Facebook] .
Setelah membaca posting ini, saya menyadari bahwa banyak kerentanan dapat ditemukan di aplikasi web sebesar itu.
Target utama saya adalah
https://legal.tapprd.thefacebook.com
, saya bermaksud untuk mengimplementasikan RCE (Remote Code Execution) atau yang serupa.
Saya menjalankan alat fuzzing untuk mengetahui semua titik akhir dari aplikasi web ini, tidur siang selama dua jam, dan menonton film. Kemudian saya kembali ke komputer saya dan menemukan hasil yang bagus.
403:
/tapprd/
/tapprd/content/
/tapprd/services/
/tapprd/Content/
/tapprd/api/
/tapprd/Services/
/tapprd/temp/
/tapprd/logs/
/tapprd/logs/portal/
/tapprd/logs/api/
/tapprd/certificates/
/tapprd/logs/auth/
/tapprd/logs/Portal/
/tapprd/API/
/tapprd/webroot/
/tapprd/logs/API/
/tapprd/certificates/sso/
/tapprd/callback/
/tapprd/logs/callback/
/tapprd/Webroot/
/tapprd/certificates/dkim/
/tapprd/SERVICES/
Saya rasa hasil ini cukup untuk mengkonfirmasi teori saya tentang dahsyatnya aplikasi ini. Kemudian saya mulai membaca file Javascript, untuk memahami bagaimana situs web, metode apa yang dia gunakan, dll.
Saya melihat cara untuk melewati pengalihan ke Login SSO
https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login
dan setelah menganalisis halaman login saya menemukan titik akhir ini:
/tapprd/auth/identity/user/forgotpassword
Setelah kabur dengan titik akhir pengguna, saya mengidentifikasi titik akhir lain
/savepassword
menunggu permintaan POST, Setelah memeriksa file Javascript, saya menemukan cara kerja halaman, bahwa token yang dihasilkan dan token xsrf diperlukan, dll. Awalnya saya pikir itu layak untuk dicoba untuk memeriksa, Anda dapat mengubahnya secara manual dengan bantuan
burp suite
, tetapi mendapat kesalahan kegagalan operasi .
Saya pikir itu mungkin alamat email yang salah atau yang serupa. Mari kita coba mengambil email administrator. Saya mulai mencatat alamat email sembarang, membuat daftar kata, dan kemudian menggunakan sendawa untuk menguji apa yang terjadi.
Ketika saya kembali beberapa jam kemudian, saya melihat kesalahan yang sama, ditambah hasil lainnya. Itu adalah pengalihan 302 ke halaman login. Wow, berhasil!
Izinkan saya menjelaskan apa yang terjadi di sini: Saya mengirim permintaan acak dengan token CSRF menggunakan cracker dan alamat email acak dengan kata sandi titik akhir baru
/savepassword
, dan salah satu hasilnya adalah pengalihan 302.
Redirect
Sekarang saya bisa pergi ke halaman login, masukkan email saya dan kata sandi baru - BOOM, login ke aplikasi berhasil dan saya memiliki akses ke panel admin!
Saya membaca laporan seorang peretas yang menemukan RCE sebelumnya diimplementasikan dengan PDF, perusahaan memberinya hadiah hanya $ 1000. Jadi saya memutuskan: oke, Anda perlu membuat kesan yang baik dan menulis exploit yang sempurna untuk mendapatkan Impact yang tinggi.
Saya segera menulis skrip Python sederhana untuk mengeksploitasi kerentanan ini: Anda memasukkan alamat email dan sandi baru, dan skrip mengubah sandi.
Dampaknya sangat besar di sini karena karyawan Facebook masuk dengan akun kerja mereka. Artinya, mereka menggunakan token akses akun Facebook mereka sendiri, dan kemungkinan besar jika penyerang lain ingin menggunakan exploit ini, tindakan tersebut akan memberinya akses ke akun beberapa karyawan Facebook. Lalu
saya melaporkan kerentanannya, dan laporan saya ditinjau .
Saya menerima penghargaan $ 7.500 pada tanggal 2 Oktober
Saya sangat menyukai exploit untuk kerentanan ini, dan saya memutuskan bahwa itu tidak cukup, skripnya terlalu lemah! Perlu terus menggali lebih dalam.
Jadi saya menemukan dua kerentanan lagi, yang akan saya bahas di bagian kedua artikel.
Bagian kedua
Di bagian pertama, saya menemukan kemampuan untuk membajak akun dengan API yang tidak aman, yang memungkinkan saya untuk mengubah kata sandi akun administrator mana pun tanpa campur tangan pengguna, dan departemen keamanan Facebook membayar saya $ 7.500 . Di bagian kedua, saya menemukan cara untuk membajak akun menggunakan manipulasi cookie. Menggabungkannya dengan SSRF internal , saya menerima hadiah $ xxxxx . Ya, jumlah lima digit ... Baiklah, mari kita mulai.
Sebelum dipublikasikan, artikel tersebut diperiksa oleh beberapa pihak, dan saya harus mendapat izin tertulis untuk itu, sehingga beberapa nama dan informasi dapat diubah atas permintaan Facebook dan mitranya.
Ketika saya menemukan kerentanan dari bagian pertama artikel, Facebook memperbaikinya sehari setelah menerima laporan. Kemudian saya mulai mempelajari sejarah
burp suite
untuk memahami bagaimana semuanya bekerja.
Seperti yang Anda lihat dari tangkapan layar (nomor 1 dengan latar belakang biru), ASPXAUTH digunakan sebagai cookie . Idealnya!
Apakah Anda melihat apa yang saya maksud? ASPXAUTH memiliki peluang 80% untuk menjadi rentan, tetapi ini membutuhkan informasi berikut:
validationKey
(): , .decryptionMethod
(): ( «AES»).decryptionIV
(): ( — , ).decryptionKey
(): , .
Anda dapat membaca lebih lanjut tentang ini di sini: Kelas MachineKey .
Saya tidak memiliki informasi tentang poin mana pun, jadi mengapa saya berasumsi bahwa ada kerentanan di sini?
Sebenarnya saya tidak tahu itu, tapi kebanyakan aplikasi ASPXAUTH dalam cookie terenkripsi dengan kunci enkripsi biasanya hanya menggunakan email atau pengguna dan masa kadaluwarsa cookie. Saya telah menggunakan metode ini berkali-kali dalam program bounty di situs web lain dan berhasil.
Saya perlu menemukan cara untuk menyiasati sistem ini, setidaknya bukan upaya penyiksaan. Saya pergi ke Google dan mencari situs web lain yang menggunakan aplikasi yang sama. Saya seharusnya beruntung dan menemukan situs web menggunakan aplikasi yang sama dan kunci enkripsi yang sama, dan cukup memilih nama pengguna admin yang benar.
Saya menemukan situs web lain menggunakan aplikasi yang sama, pendaftaran aktif, jadi saya masuk dengan nama pengguna admin Facebook, menyadap permintaan, mengambil ASPXAUTH dan menggantinya dengan ASPXAUTH Facebook yang kedaluwarsa. Tebak apa yang terjadi?
Saya sudah melewatkan panel ini, tetapi akhirnya kembali ke sana. Sekarang, mari kita bicara sedikit tentang pengawasan ASP.net yang harus dipertimbangkan oleh sebagian besar pengembang saat membangun aplikasi agar tetap aman:
- ASPXAUTH harus disimpan dalam database dan aplikasi harus memvalidasi kebenarannya.
- Sebagai pemeriksaan tambahan, ASPXAUTH terkadang harus berisi lebih dari sekedar nama pengguna.
- Setiap situs harus memiliki kunci enkripsi dan dekripsi yang unik (kunci default harus diubah).
Kesimpulan 1 : Saya dapat masuk ke akun administrator mana pun, hanya mengetahui nama penggunanya; Saya menganggap kompleksitas kerentanan ini sangat rendah , dan dampaknya tinggi . Jika saya hanya melaporkan kerentanan ini, saya hanya akan menerima $ 7.500 , seperti di bagian pertama, tetapi saya menginginkan lebih.
Di panel, saya melihat sesuatu yang aneh, yaitu opsi untuk membuat formulir dan opsi lain - pemicu API. Saya curiga sesuatu, kemungkinan besar ada kemungkinan SSRF (Server-Side Request Forgery) tidak terbatas. Oleh karena itu, saya menulis surat kepada departemen keamanan Facebook, mengatakan bahwa ada hampir seratus persen kerentanan SSRF kritis dalam aplikasi, meminta izin untuk mengujinya. Jawabannya datang kepada saya:
Saat itu, saya masih membahas laporan dari bagian pertama (pembajakan akun) dengan mereka, karena saya melaporkan kerentanan ini seminggu setelah yang pertama. Seperti yang Anda lihat, departemen keamanan Facebook terus percaya bahwa saya mengklaim bypass otentikasi lain dan SSRF, bahkan setelah saya menjelaskan kerentanan dengan bukti. Melihat ini, saya diberi izin untuk menguji SSRF.
Setelah beberapa saat, saya menulis skrip kecil dan mengunggahnya ke editor mereka. Skrip memungkinkan saya mengirim permintaan apa pun dengan data apa pun (GET, POST, PUT, PATCH, HEAD, OPTIONS) ke URL apa pun, baik internal maupun eksternal.
Dari bagian belakang skrip, saya dapat mengubah metode permintaan dan data yang dikirim, dll.
Pada tahap ini, saya dapat memperluas kerentanan ini ke RCE, mungkin ke LFI (Penyertaan File Lokal, menambahkan file lokal), jika saya melangkah lebih jauh ( saya tidak sepenuhnya yakin tentang ini, kemudian saya meminta izin Facebook untuk merekayasa balik aplikasi, tetapi mereka menolak dan mengatakan mereka tidak berpikir saya dapat memperluas serangan ).
Kemudian saya mencoba menyerang Facebook dengan skrip kenari. Tebak apa yang terjadi lagi?
Saya menerima token kenari saya. Apa berikutnya? Saya perlu menulis laporan baru dengan semua detail, termasuk skrip dan PoC (bukti konsep), seperti yang saya katakan di atas.
Kesimpulan 2: Dengan menulis skrip untuk mengirim permintaan sewenang-wenang, saya bisa mendapatkan SSRF internal dan memberikan akses ke jaringan Facebook internal. Saya menganggap kesulitan serangan ini rendah, dan Dampak kritis .
Impact SSRF:
SSRF- Facebook, , -, . SSRF .
SSRF-, , , , , .
Pelajari lebih lanjut tentang kerentanan SSRF dapat ditemukan di artikel portswigger .
Kesimpulan terakhir: Saya merangkai kedua kerentanan ke titik di mana saya memiliki akses ke intranet Facebook ( SSRF ), menggunakan pengambilalihan Akun untuk mendapatkan skrip yang saya unggah di dalam aplikasi, mengirimkan permintaan sewenang-wenang yang saya inginkan.
Mari kita bicara tentang apa yang dapat saya capai dengan rantai kerentanan yang saya temukan:
- Saya dapat mengakses akun karyawan Facebook mana pun di dasbor Departemen Hukum.
- Tidak perlu menjelaskan seberapa penting informasi yang bisa didapat penyerang setelah masuk.
- Saya dapat menggunakan SSRF untuk mengakses intranet Facebook (intern.our.facebook.com).
- Saya pikir dengan sedikit usaha, saya dapat memperluas kerentanan ini dan menggunakannya untuk memindai jaringan / server internal.
Kita semua tahu betapa pentingnya SSRF , terutama jika frekuensinya tidak dibatasi. Saya dapat dengan mudah mengubah tipe konten dan metode permintaan. Menurut panduan pembayaran Facebook , kerentanan ini harus diberi $ 40.000 dalam bonus $ 5.000 jika saya dapat mengubah jenis konten permintaan dan metode permintaan.
Setelah menunggu lama, saya menerima pesan ini dari Facebook:
Menerima penghargaan $ 40.000 dari Facebook ditambah bonus $ 2.000 (naik dari $ 7.000 yang diharapkan ).
Saya mengajukan pertanyaan kepada mereka tentang mengapa saya tidak menerima Bonus Kontrol Penuh ( $ 5.000 ), dan menerima jawaban ini:
Secara total, dengan kerentanan pertama, jumlahnya mencapai $ 54.800 .
Saya melaporkan kerentanan ini beberapa hari setelah bagian pertama laporan kerentanan.
Kronologi laporan:
- Rabu, 9 September 2020 - Laporan kerentanan dikirim.
- Senin, 26 Oktober 2020 - Facebook meminta saya untuk membuka laporan baru. ~ Tindakan korektif diambil.
- Senin, 26 Oktober 2020 - laporan ditinjau.
- Kamis 25 Februari 2021 - Masalah diselesaikan dan hadiah dibayarkan. Sekitar enam bulan, ya .
- Jumat, 5 Maret 2021 - bonus $ 5.300 dibayarkan.
Saya ingin memberikan beberapa saran berharga untuk pemburu serangga. Saat Anda melihat ASPXAUTH coba dapatkan cookie dari situs web lain menggunakan aplikasi yang sama dan uji metode yang sama seperti milik saya:
- Buat cookie ASPXAUTH baru dari situs web lain.
- Periksa untuk melihat apakah cookie akan berfungsi di situs web yang sedang diselidiki.
Saya menyukai prosesnya, tetapi menunggu selama enam bulan dan menutup laporan karena alasan yang tidak rasional sangat mengganggu. Saya bersyukur, tetapi harus bekerja keras dan ini bukan satu-satunya SSRF yang saya temukan. Faktanya, saya menemukan lebih banyak yang aneh, tetapi Facebook menutup laporan tersebut sebagai "informatif" karena perusahaan menandatangani perjanjian dengan pemasok yang dibuat beberapa minggu setelah meninjau laporan. Pada akhirnya, ini bukan masalah saya, jadi pengalaman ini tidak menyenangkan.
Pada akhirnya, saya ingin meminta maaf jika ada sesuatu yang tidak jelas. Butuh beberapa waktu untuk mempublikasikan bagian kedua - seperti yang disebutkan di atas, saya menunggu izin tertulis dan revisi laporan. Oleh karena itu, banyak aspek telah dihapus atau disensor untuk menjaga kerahasiaan pihak ketiga.