[Write Up — Bahasa Indonesia] Server-Side Request Forgery (SSRF) — PortSwigger Labs
Server-Side Request Forgery Attack
Dalam Server-Side Request Forgery Attack (SSRF Attack), penyerang dapat menyalahgunakan fungsionalitas di server untuk membaca atau memperbarui sumber daya internal. Penyerang dapat menyediakan atau memodifikasi URL yang akan dibaca atau dikirim oleh kode yang berjalan di server, dan dengan memilih URL dengan hati-hati, penyerang mungkin membaca konfigurasi server seperti metadata AWS, menyambung ke layanan internal seperti HTTP diakifkan database atau melakukan permintaan posting terhadap layanan internal yang tidak dimaksud untuk diekspos.
Pada kesempatan kali ini saya akan menulis mengenai serangan SSRF ini dengan menggunakan PortSwigger sebagai lab implementasinya. Berikut beberapa lab mengenai SSRF Attack yang tersedia di PortSwigger.
Lab: Basic SSRF against the local server
Langkah pertama adalah lakukan pengumpulan informasi, mengenai fungsi yang tersedia di web target. Buka direktori /admin, namun hal itu tidak dapat diizinkan karena hanya pengguna administrator yang dapat mengakses halaman tersebut, maka dari itu kita tidak bisa mengakses halaman /admin.
Selanjutnya hasil dari pengumpulan informasi sebelumnya, menemukan terdapat fungsi atau fitur aplikasi untuk melakukan pengecekan stok.
Dan ketika di cek lebih lanjut lagi fitur tersebut mengambil data dari sistem internal menggunakan parameter stockApi.
Parameter tesebut dapat kemungkinan untuk dilakukan exploitasi serangan SSRF. maka dari itu kita dapat mencobanya dengan cara mengubah nilai URL yang terdapat pada parameter stockAPI. Kirim request tersebut ke burp repeater, kemudian ubah nilai parameter menjadi http://localhost/admin
Maka akan memunculkan respon HTTP 200 yang memiliki arti bahwa benar parameter stockApi ini memiliki kerentanan SSRF.
Dilihat dari source-code kita dapat menghapus akun pengguna. Maka dari itu atur URL agar kita dapat menghapus user yang ada.
Dan akun pengguna terhapus.
Lab: Basic SSRF against another back-end system
Kembali gunakan fitur atau fungsi untuk pengecekan stok dan lakukan intercept menggunakan burpsuite.
Dan hasilnya akan seperti berikut.
Terlihat pada parameter stockApi sistem mengambil data dari sistem internal. maka dari itu kita dapat mencoba mengeksploitasinya. dengan mengirimkan request tersebut ke burp intruder. Kemudian ubah nilai dari parameter stockApi menjadi http://192.168.0.1:8080/admin yang dimana tambahkan ‘§’ di oktet terakhir pada alamat IP agar nilai angka dari oktet terakhir dapat dilakukan bruteforce.
Selanjutnya atur payload type menjadi number dan atur angka menjadi dimulai dari 1 hingga 255 dan dilakukan hanya 1 kali pengulangan.
Lalu kemudian jalankan bruteforce, hingga menemukan nilai yang memiliki respon 200 atau berhasil.
Kemudian kirim request tersebut ke burp repeater dan atur URL agar dapat menghapus akun pengguna.
Jika sukses akan mendapatkan respon seperti gambar dibawah ini.
Lab: SSRF with blacklist-based input filter
Coba kembali gunakan fitur pengecakan stok produk dan lakukan intercept pada requestnya menggunakan burp intercept.
Hasil dari intercep menggunakan burp intercept.
Kirimkan request tersebut ke burp repeater. Kemudian ubah nilai dari parameter stockApi.
Ketika menggunakan http://localhost sebagai nilai dari parameter stockApi akan mendapatkan respon error dengan kode error 400.
Begitu juga ketika menggunakan http://127.0.0.1 akan mendapatkan respon yang sama.
Kita dapat simpulkan bahwa sistem melakukan blacklist input terhadap http://localhost dan juga http://127.0.0.1. Beberapa aplikasi memang akan melakukan blokir terhadap nama host tersebut. Namun, untuk menghindari filter tersebut, kita dapat menggunakan beberapa teknik ini diantaranya sebagai berikut.
- Menggunakan representasi IP alternatif seperti 2130706433, 017700000001, atau 127.1
- Mendaftarkan nama domain yang menghasilkan 127.0.0.1
- Membypass string yang diblokir menggunakan URL Encoding atau variasi kasus.
Kita dapat mencoba membypass filter tersebut menggunakan representasi IP alternatif dari http://127.0.0.1 menggunakan http://127.1
Dan terlihat responnya menampilakan kode 200 dan berhasil menampilkan tampilan web.
Selanjutnya dapat membuka halaman admin.
Namun ketika menggunakan halaman admin dilakukan block lagi oleh aplikasi. Maka dapat disimpulkan aplikasi memblacklist juga inputan yang mengandung kata admin.
Maka dari itu kita melakukan bypass juga dengan cara melakukan URL encoding untuk karakter ‘a’ yang ada di dalam kata admin.
Maka hal tersebut berhasil, filtering dapat di bypass.
Kemudian hapus pengguna untuk dapat menyelesaikan lab ini.
Dan pengguna pun berhasil dihapus.
Lab: SSRF with whitelist-based input filter
Coba gunakan fitur pengguna untuk melakukan pengecekan stok produk dan lakukan intercept.
Kirim request tersebut ke burp repeater. dan ubah nilai parameter stockApi menjadi http://192.168.0.12:8080/admin
Ketika mengirimkan request tersebut akan muncul respon yang memberitahu bahwa request akan divalidasi dengan whitelist. Karena pada beberapa kasus terdapat aplikasi yang hanya mengizinkan inputan yang cocok dimulai dengan, atau berisi whitelist dari nilai yang diizinkan. Untuk dapat menghindari filterisasi seperti kasus tersebut dapat menggunakan beberapa caranya diantaranya sebagai berikut :
- Kita dapat menyematkan kredensial di URL sebelum nama host, menggunakan karakter ‘@’. Misalnya : http://expected-host@evil-host
- Kita juga dapat menggunakan ‘#’ untuk menunjukan fragmen URL. Misalnya : https://evil-host#expected-host
- Kita juga dapat memanfaatkan hierarki penamaan DNS untuk menempatkan input yang diperlukan ke dalam nama DNS yang sepenuhnya memenuhi syarat yang kita kontrol. Misalnya : https://expected-host.evil-host
- Kita dapat menyandikan karakter URL untuk mengacaukan kode parsing URL. Ini sangat berguna jika kode yang mengimplementasikan filter menangani karakter yang disandikan URL secara berbeda dari kode yang menjalankan permintaan HTTP back-end
- Selain itu, kita dapat menambahkan titik ‘.’ ke URL dalam parameter. Jika regex yang digunakan untuk whitelist salah dikonfigurasi, ini dapat melewati batasan
- Kita juga dapat mengkombinasikan dari teknik-teknik tersebut secara bersamaan.
Kita dapat menggunakan http://localhost:80%25%32%33@stock.weliketoshop.net/ untuk menghindari filterisasi whitelist pada aplikasi.
Maka akan menghasilkan respon 200 atau berhasil.
Kemudian hapus akun pengguna bernama carlos untuk menyelesaikan lab ini dengan menggunakan inputan http://localhost:80%25%32%33@stock.weliketoshop.net/admin/delete?username=carlos pada parameter stockApi.
Maka akun pengguna berhasil dihapus.
CVSS:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
Pencegahan Server-Side Forgery Request Attack
Dalam rencana pencegahan SSRF developer aplikasi dapat menerapkan kontrol pertahanan yang diantaranya sebagai berikut :
Lapisan Jaringan
- Segmentasikan fungsionalitas akses sumber daya jarak jauh di jaringan terpisah untuk mengurangi dampak dari serangan SSRF
- Terapkan kebijakan pada firewall ‘deny by default’ atau aturan kontrol akses jaringan untuk memblokir semua kecuali lalu lintas intranet yang penting.
Lapisan Aplikasi
- Melakukan sanitasi dan validasi semua data yang diinput oleh klien
- Terapkan skema URL, port, dan tujuan dengan positve allow list
- Jangan mengirim raw response ke klien
- Nonaktifkan pengalihan HTTP
- Waspadai konsistensi URL untuk menghindari serangan seperti DNS rebinding dan “time of check, time of use” (TOCTOU) race coditions.
Terimakasih!
Stay Ethical and Happy Hacking!🍻
Referensi :