Contoh Bug Remote Execution Code - CRUDPRO

Contoh Bug Remote Execution Code

Ketika berbicara dengan peneliti keamanan pemula dan pemburu hadiah bug, mereka merasa sangat kompleks sehingga mereka tidak berpikir mereka dapat menemukan kerentanan eksekusi kode jarak jauh. Karena kesalahpahaman ini, orang-orang ini tidak benar-benar berusaha menemukan salah satu dari mereka atau berhenti merawat mereka untuk sementara waktu. Mungkin alasan di baliknya adalah bahwa sebagian besar contoh/deskripsi adalah bug yang benar-benar sangat kompleks yang mengarah ke RCE dari beberapa akar penyebab berbeda yang dirantai bersama. Saya selalu terkesan dengan artikel yang ditulis dengan baik dan metode eksploitasi baru ini, tetapi saya masih mencari sesuatu yang mudah saat berburu. Untuk alasan ini, saya memutuskan untuk membagikan beberapa contoh aktual yang saya temukan di target Synack untuk beberapa waktu. Ini sebenarnya buah gantung yang bisa ditemukan atau disalahgunakan siapa saja. Beberapa trik yang berbeda sebenarnya dapat mengeksploitasi kerentanan, tetapi pada awalnya tampaknya tidak mungkin.

Upload file tidak terbatas 1

Pada sistem host yang saya cari, saya menemukan halaman login di bawah direktori /support/ di direktori fuzzing. Dengan bantuan file javascript yang dimuat pada halaman login itu, Anda dapat membuat daftar beberapa titik akhir setelah login dan mengakses titik akhir ini secara langsung untuk mengakses beberapa halaman admin tanpa login. Pertama, itu juga mengizinkan ekstensi file asp dengan menyertakan halaman unggah file. Apakah itu terdengar sangat mudah?

Nah, setelah mengunggah, saya mencoba menghitung direktori pengunggahan file di file fuzzing dan file javascript, tetapi itu tidak mungkin. Saya kemudian mencoba mengunggah file ke direktori yang lebih tinggi ketika mencoba kerentanan traversal direktori dalam nama file, tetapi berhasil.

Menggunakan kamus "Fuzzing-Path Traversal" Burp Suite, kami melakukan serangan otomatis sederhana untuk menemukan kerentanan. Namun, perhatikan bahwa mengumpulkan file bukanlah masalah, tetapi semua muatan yang berjalan membuat file baru di server, yang dapat menyebabkan masalah dengan fungsionalitas creation/update/deletion.

Perhatikan bahwa kerentanan ini ditemukan di target yang telah aktif setidaknya selama dua minggu. Pembayarannya sekitar 3k.

Upload File tanpa batas 2

Pada sistem web yang saya uji, saya menemukan formulir web yang sama sekali tidak ada di peta situs atau UI aplikasi web dengan bantuan Google Dorks, seperti pencarian situs:domain.com ext:aspx. Formulir web juga memiliki bagian unggah file tempat saya dapat mengunggah ekstensi asp.

Tantangan kali ini juga untuk menemukan direktori unggahan. Apa pun yang saya lakukan, saya tidak dapat menghitung direktori unggahan, dan saya tidak menemukan kerentanan terhadap rantai seperti traversal direktori seperti pada contoh pertama. Setelah itu, saya kembali ke formulir web yang saya isi. Itu adalah formulir aplikasi yang saya tidak ingat. Saya mengisi formulir besar dan mengirimkannya. Beberapa menit kemudian, saya menerima email dari aplikasi web saya tentang aplikasi saya. Email tersebut berisi semua informasi yang Anda isi dalam formulir, termasuk tautan ke dokumen yang diunggah yang berada dalam cakupan aplikasi yang sama. Ketika saya mengklik tautan, cangkang web yang sama seperti pada contoh pertama dikembalikan dan platform mengembalikan pembayaran sekitar 3rb.

Targetnya hidup selama dua hari ketika saya mengirimkan kerentanan. Aturan 24 jam telah berlalu untuk kerentanan ini dan belum ada yang melaporkannya.

Eksploitasi RCE yang diketahui

Dalam tes host, saya menemukan versi aplikasi SugarCRM berjalan di alamat IP dalam cakupan. Kumpulan versi perangkat lunak dan pencarian kerentanan di Google memudahkan untuk menemukan bahwa versi tersebut rentan terhadap kerentanan eksekusi kode PHP, bahkan di dalam modul Metasploit. Mudah?

Sekarang, tidak ada sesi yang dibuat saat eksploitasi selesai. Saya mencoba menggunakan muatan msf yang berbeda dari kerangka kerja, tetapi tidak ada yang berhasil. Mungkin firewall memblokir permintaan mengikat/membalikkan shell yang masuk dan keluar. Setelah itu, saya membuka kode exploit dan menganalisisnya dari sini. Kode eksploitasi membuat file bernama acak di bawah direktori / custom / dan kemudian membuat shell terbalik dari file php yang dibuat ke alamat IP yang ditentukan. Mengakses langsung file yang dibuat oleh upaya eksploitasi di atas (ditampilkan sebagai /custom/svbGhtxS.php dalam foto) mengembalikan respons kosong. Ini berarti bahwa file tersebut benar-benar dibuat dan eksploitasinya berhasil.

Kemudian, pada kode di bawah ini, saya perhatikan bahwa header payload khusus dikirim dari file ini ke server melalui kode ini untuk penggunaan penuh dengan enkode base64.

Jadi saya mengkodekan payload sebagai @system(whoami);. untuk:
  • Perintah sistem dari php untuk menjalankan perintah OS.
  • Perintah Whoamios untuk mengembalikan hasilnya.

Ketika saya meminta file yang dibuat oleh Metasploit menggunakan header payload yang dibuat pada gambar di bawah, output dari perintah whoami dikembalikan dan pembayaran sekitar 3k dilakukan lagi.

Sekarang ketika saya mencoba untuk menghapus webshell yang saya buat untuk proses pembersihan, saya menemukan webshell lain yang dibuat sebelum saya, bukan saya sendiri (seperti yang saya tahu dari nama file dan tanggal pembuatan). Dengan kata lain, peneliti lain juga ditemukan. Kerentanan ini tidak dieksploitasi karena modul Metasploit tidak bekerja dengan sempurna dan tidak membaca kode sumber eksploit. Kerentanan ditemukan di luar aturan 24 jam sehari setelah target diaktifkan. Artinya, tidak menduplikasi peneliti lain.

# Contoh keempat — Injeksi perintah tingkat aplikasi

Ini sedikit lebih rumit daripada contoh lainnya, tetapi saya ingin menambahkannya ke posting ini karena dieksploitasi secara berbeda. Pengujian untuk aplikasi web yang diautentikasi memberikan kemampuan untuk menambahkan ekspresi khusus ke kasus yang dibuat pengguna. Misalnya. Jika kasing adalah tentang pembayaran, Anda dapat secara opsional mengembalikan firstAmount — lastAmount dalam output kasing. Ekspresi ini menggunakan fungsi yang dibuat khusus seperti fungsi addDate dan diffDate.

Teknologi yang mendasarinya adalah Java karena memiliki ekstensi .do. Mungkin pada tahap skrip input, apakah menurut Anda fitur Java dan fungsi yang dibuat khusus juga diizinkan?

Java one-liner new java.io.DataInputStream(java.lang.Runtime.getRuntime().exec("whoami") .getInputStream()).readLine() di bawah fungsi addMessage yang dibuat khusus untuk menampilkan kode dan saya menyimpan expression.

Setelah memicu dari halaman lain, saya mendapatkan output berikut:

Ini mengembalikan injeksi kode Java murni yang berhasil. Setelah beberapa penelitian, kami menemukan kerentanan serupa di fitur lain aplikasi, yang menghasilkan total pembayaran sekitar 6k. Kata terakhir

Kami berharap posting ini akan secara khusus mendorong dan mendorong peneliti baru untuk mencari kerentanan eksekusi perintah yang kompleks dan kerentanan eksekusi perintah sederhana. Ceramah, kuliah, posting, seperti yang selalu saya bicarakan. Yang Anda butuhkan hanyalah bug sederhana.