Kerentanan SSRF dan Cara Menemukannya
Tidaklah rahasia bahwa arsitektur cloud memiliki beberapa karakteristik yang membuat serangan SSRF sulit untuk diatasi. Meskipun SSRF bukanlah vektor ancaman yang baru, sering kali disalahpahami dan dikacaukan dengan CSRF.
Dalam artikel ini, hacker etis Luke Stephens menjelaskan apa itu kerentanan, tempat-tempat di mana mereka paling umum ditemukan, dan bagaimana Anda dapat melewati perlindungan SSRF.
Penjelasan SSRF
Server-Side Request Forgery (SSRF) terjadi ketika sebuah aplikasi menerima URL (atau sebagian URL) dari pengguna, kemudian mengakses URL tersebut dari server. Penting untuk dicatat bahwa SSRF hanya merupakan kerentanan jika ada dampak keamanan. Mengakses URL dari server adalah tugas umum yang diperlukan dalam banyak kasus dan dapat sepenuhnya aman. Ini menjadi masalah ketika permintaan ini mengkompromikan keamanan. Misalnya:
- Anda dapat membuat permintaan ke endpoint internal yang membocorkan informasi sensitif, dan responsnya dapat dilihat oleh penyerang
- Anda dapat membuat permintaan ke jaringan internal yang memungkinkan Anda melakukan tindakan yang tidak sah atau mengeksploitasi sistem internal
- Anda dapat memetakan jaringan internal dengan menyebarkan permintaan melaluinya, menggunakan aplikasi web yang rentan sebagai proxy
Blind vs. Partial-blind vs. Non-blind
Penting untuk membuat perbedaan ini.
- Dalam SSRF buta, tidak ada bagian dari respons yang dapat dilihat. Ini membuatnya sulit (tetapi tidak selalu mustahil) untuk dieksploitasi.
- Dalam SSRF non-buta, respons terhadap permintaan dari server dapat dilihat oleh penyerang secara penuh.
- Dalam SSRF partial-blind, beberapa bagian dari respons dapat dilihat (mungkin kode status atau bagian tertentu dari respons).
Di Mana Menemukan Kerentanan SSRF
Nama Parameter Rentan Umum
Saat melakukan pengujian keamanan aplikasi, kami biasanya menganalisis ribuan permintaan dan parameter. Mengetahui nama parameter yang paling mungkin rentan terhadap SSRF membantu kami memperhatikan mereka secara lebih seksama.
Untungnya, data ini telah dikumpulkan dalam ekstensi Burp Suite HUNT. Alat ini awalnya dibuat oleh Jason Haddix saat dia bekerja di Bugcrowd, jadi saya yakin nama-nama parameter ini dikumpulkan dari pengajuan bug bounty Bugcrowd. Berikut adalah nama parameter tersebut:
- dest
- redirect
- uri
- path
- continue
- url
- window
- next
- data
- reference
- site
- html
- val
- validate
- domain
- callback
- return
- page
- feed
- host
- port
- to
- out
- view
- dir
- show
- navigation
Tidak mengherankan, nama-nama parameter ini semuanya merujuk pada jenis objek yang dapat diambil dari sumber daya jarak jauh.
Integrasi Webhook
Aplikasi yang ingin terintegrasi dengan aplikasi lain sering melakukannya dengan mengimplementasikan webhook yang keluar. Cara terbaik untuk menjelaskan ini adalah dengan contoh.
Misalnya, kita menguji aplikasi web yang menangani faktur. Pengembang ingin menyediakan solusi generik untuk berintegrasi dengan layanan lain, jadi mereka mengimplementasikan webhook. Aplikasi dapat diatur sehingga ketika sebuah faktur dibuat, itu akan mengirimkan permintaan HTTP (webhook) ke server yang dipilih oleh pengguna, yang berisi rincian faktur yang baru saja dibuat.
Ini memungkinkan pengguna aplikasi untuk menangkap webhook di server mereka sendiri dan menggunakan detail faktur sesuai keinginan mereka. Misalnya, mereka mungkin ingin memposting detail faktur ke Slack, mendorongnya ke CRM mereka, atau mengirim email ke tim akun mereka.
Sebagian besar aplikasi yang memiliki fungsi webhook juga memiliki beberapa jenis fungsi untuk menguji webhook. Biasanya Anda memberikan aplikasi dengan rincian permintaan yang ingin Anda buat, seperti URL, dan kemudian uji webhook akan menunjukkan responsnya. Saya bahkan pernah melihat beberapa aplikasi yang memungkinkan Anda menentukan kata kerja HTTP dan header kustom. Ini seperti stasiun pengujian SSRF kecil Anda sendiri.
Impor Berkas
Banyak aplikasi memerlukan kebutuhan untuk mengimpor berkas. Misalnya, aplikasi media sosial memerlukan kebutuhan untuk mengunggah foto profil. Dalam beberapa kasus, aplikasi memungkinkan berkas diimpor dari URL daripada diunggah langsung.
Kasus-kasus seperti ini seringkali menghasilkan SSRF. Untuk menguji, cukup tentukan URL internal yang sensitif, seperti http://192.168.1.1, kemudian unduh foto profil yang dihasilkan dan lihat dengan editor teks. Jika beruntung, itu akan berisi respons dari endpoint metadata cloud.
Generator PDF
Beberapa waktu yang lalu, Nahamsec dan Cody Brocious melakukan presentasi DEFCON yang luar biasa tentang melakukan serangan SSRF melalui generator PDF, berjudul “Owning the cloud through SSRF and PDF generators”.
Dalam presentasi ini, mereka menyajikan ide untuk melakukan SSRF melalui generator PDF. Anda lihat, kebanyakan generator PDF saat ini hanya merender HTML di browser tanpa kepala dan kemudian mencetak halaman web yang dihasilkan sebagai PDF untuk membuatnya. Jika ada konten yang didefinisikan pengguna yang didorong ke PDF tersebut, itu mungkin rentan terhadap XSS, yang berarti bahwa pengguna dapat menyematkan iframe dalam PDF tersebut. Iframe tersebut dapat memuat sumber daya internal apa pun, dan kemudian respons dari sumber daya internal tersebut akan muncul di PDF yang dihasilkan.
Rincian lengkapnya di luar cakupan blog ini, tetapi saya mendorong Anda untuk memeriksa slide-nya.
Seberapa Aman Berkas PDF? Lihat tulisan ini dan kekurangannya di Detectify Blog.
Bypass Umum
Jika upaya SSRF Anda tidak berhasil pada percobaan pertama, tidak semuanya hilang. Berikut adalah beberapa bypass umum yang cepat untuk dicoba.
Gunakan Nama Host Alih-alih IP
Kadang-kadang, pengembang hanya melarang penggunaan 192.168.1.1secara langsung. Dalam hal ini, kita cukup menggunakan nama host yang diurai menjadi alamat IP yang sama. Nip.io memungkinkan DNS wildcard sederhana untuk alamat IP apa pun; berikut adalah beberapa contohnya. Semua ini diurai menjadi 192.168.1.1.
- 192.168.1.1.nip.io
- 192-168-1-1.nip.io
- 0xc0a80101.nip.io (notasi IP heksadesimal)
- Something.google.com.192.168.1.1.nip.io
Pengalihan HTTP
Kadang-kadang, melewati perlindungan SSRF semudah menggunakan pengalihan HTTP.
Katakanlah kita dapat membuat permintaan ke customdomain.com, tetapi tidak ke 192.168.1.1.
Kita dapat meng-host skrip sederhana di customdomain.com untuk 302 redirect ke 192.168.1.1. Jika endpoint yang rentan mengikuti pengalihan tetapi tidak memeriksanya, kita memiliki SSRF!
Berikut adalah skrip PHP sederhana untuk melakukan pengalihan.
<?php header("Location: http://192.168.1.1/") ?>DNS Rebinding
Banyak aplikasi mencoba menghalangi upaya SSRF dengan pola kode seperti ini:
func fetch_if_allowed(url string){
if ip_is_blocked(resolve($url)){
return false
} else {
fetch($url)
}
}
Kode ini rentan terhadap bentuk kerentanan TOCTOU (time-of-check, time-of-use) yang disebut DNS rebinding. Penyerang dapat mengatur server DNS yang merespons dengan dua alamat IP berbeda pada permintaan bergantian, satu diizinkan melalui fungsi ip_is_blocked(), dan yang lain tidak.
Dalam hal ini, kita dapat mengatur layanan DNS rebinding seperti rbndr milik Taviso untuk diurai menjadi 1.1.1.1 setiap kali kedua, dan 192.168.1.1 setiap kali lainnya. Ketika domain diurai pertama kali, aplikasi melihat bahwa itu diurai menjadi 1.1.1.1, dan memungkinkan kode mengalir ke pernyataan else, di mana domain diurai lagi – kali ini menjadi 192.168.1.1.
Notasi IP Non-Standar
Kadang-kadang, alamat IP tertentu diblokir, seperti 192.168.1.1. Dalam hal ini, kita mungkin dapat melewatinya dengan hanya menggunakan notasi IP yang berbeda. Misalnya, semua ini akan diinterpretasikan sebagai 192.168.1.1. Tidak percaya? Coba ping mereka!:
- 030052000401 (oktal)
- 0xc0a80101 (heksadesimal)
- 3232235777 (integer)
- ::ffff:c0a8:101 (IPv6)
Parafrase:
Arsitektur cloud memiliki beberapa fitur yang membuat serangan SSRF sulit untuk ditangani, meskipun ancaman ini bukanlah hal baru. Luke Stephens, seorang hacker etis, menjelaskan tentang SSRF, di mana sering ditemukan, dan cara mengatasinya.
Apa Itu SSRF?
SSRF terjadi ketika aplikasi menerima URL dari pengguna dan mengaksesnya dari server. Ini menjadi masalah ketika permintaan tersebut merusak keamanan, seperti mengakses informasi sensitif atau melakukan tindakan tidak sah di jaringan internal.
Tipe SSRF:
- Blind SSRF: Tidak ada bagian dari respons yang terlihat.
- Non-blind SSRF: Respons dapat dilihat sepenuhnya.
- Partial-blind SSRF: Sebagian respons terlihat.
Menemukan Kerentanan SSRF:
Nama Parameter Rentan: Parameter seperti dest, redirect, uri, path, dan url seringkali rentan terhadap SSRF.
Integrasi Webhook: Aplikasi yang mengintegrasikan dengan aplikasi lain menggunakan webhook seringkali rentan. Misalnya, aplikasi faktur yang mengirimkan data ke server yang dipilih pengguna bisa dieksploitasi.
Impor Berkas: Aplikasi yang memungkinkan impor berkas dari URL, seperti foto profil, dapat dieksploitasi dengan memberikan URL internal sensitif.
Generator PDF: Generator PDF yang merender HTML dapat dieksploitasi dengan menyematkan iframe yang mengakses sumber daya internal.
Bypass Umum:
Jika upaya SSRF gagal, coba beberapa metode bypass berikut:
- Gunakan Nama Host: Alih-alih IP, gunakan nama host yang diurai ke IP yang sama.
- Pengalihan HTTP: Gunakan skrip pengalihan untuk melewati pembatasan.
- DNS Rebinding: Manipulasi resolusi DNS untuk mengelabui aplikasi.
- Notasi IP Non-Standar: Gunakan notasi IP berbeda seperti oktal, heksadesimal, atau IPv6 untuk menghindari pembatasan.
Metode-metode ini dapat membantu dalam mengatasi perlindungan SSRF yang ada.
Kesimpulan:
Arsitektur cloud memiliki kelemahan yang membuat Server-Side Request Forgery (SSRF) sulit ditangkal. Kerentanan SSRF terjadi ketika aplikasi menerima URL dari pengguna dan mengaksesnya melalui server, yang bisa membahayakan keamanan jika digunakan untuk tujuan tidak sah. SSRF dapat dikategorikan menjadi blind, non-blind, dan partial-blind berdasarkan tingkat respons yang dapat dilihat oleh penyerang.
Kerentanan ini sering ditemukan dalam parameter seperti url, path, dan redirect, serta dalam integrasi webhook, impor berkas, dan generator PDF. Meskipun serangan SSRF dapat diatasi dengan perlindungan tertentu, penyerang masih dapat melewati proteksi ini melalui berbagai metode seperti penggunaan nama host, pengalihan HTTP, DNS rebinding, dan notasi IP non-standar. Oleh karena itu, pemahaman mendalam dan pendekatan proaktif sangat penting untuk melindungi sistem dari ancaman SSRF.
