Spring4Shell CVE-2022-22965, Celah RCE di Spring Framework

Spring4Shell (CVE-2022-22965) adalah celah eksekusi kode jarak jauh (RCE) di Spring Framework, kerangka kerja Java yang sangat banyak dipakai untuk aplikasi web dan API. Lewat fitur data binding, penyerang bisa memanipulasi properti internal aplikasi sampai akhirnya menulis file berbahaya ke server dan menjalankannya.

Kenapa ini penting dibahas lagi beberapa tahun kemudian? Karena aplikasi Java di perusahaan sering berumur panjang. Sistem internal yang dibangun dengan Spring 5.x lalu jarang disentuh masih banyak berjalan, dan celah yang sudah masuk katalog celah yang dieksploitasi seperti ini tetap jadi target pemindaian otomatis.

Apa yang terjadi pada Maret 2022?

Menurut kronologi resmi tim Spring, celah ini dilaporkan peneliti dari AntGroup FG pada Selasa malam, dua hari sebelum rilis perbaikan. Tim Spring menyelidiki dan menyiapkan perbaikan, tapi rincian celah lebih dulu bocor ke internet sebelum rilis resmi siap.

Pada 31 Maret 2022, Spring Framework 5.3.18 dan 5.2.20 dirilis, disusul Spring Boot 2.6.6 dan 2.5.12 yang memakai Framework 5.3.18. CVE-2022-22965 diterbitkan di hari yang sama. Pada 1 April 2022, tim Spring mengumumkan bahwa Apache Tomcat merilis versi 10.0.20, 9.0.62, dan 8.5.78 yang menutup jalur serangan dari sisi Tomcat. CISA memasukkannya ke katalog Known Exploited Vulnerabilities pada 4 April 2022.

Nama "Spring4Shell" muncul dari komunitas karena kemiripannya dengan Log4Shell beberapa bulan sebelumnya. Meski namanya mirip, cara kerja dan cakupannya berbeda.

Bocornya rincian sebelum perbaikan siap membuat banyak tim keamanan bekerja dalam ketidakpastian selama beberapa hari. Sempat beredar kebingungan apakah celah ini sama dengan celah lain di ekosistem Spring yang diumumkan berdekatan. Pelajarannya, saat ada kabar celah besar, rujuk dulu pengumuman resmi vendor sebelum mengambil keputusan berdasarkan unggahan media sosial.

Siapa yang terdampak?

Eksploit yang dipublikasikan butuh semua syarat berikut terpenuhi sekaligus:

• Memakai JDK 9 atau lebih baru.
• Berjalan di Apache Tomcat sebagai servlet container.
• Dikemas dan dideploy sebagai WAR.
• Memakai dependensi spring-webmvc atau spring-webflux.
• Versi Spring Framework 5.3.0 sampai 5.3.17, atau 5.2.19 ke bawah.

Aplikasi Spring Boot yang dijalankan sebagai JAR mandiri (cara bawaan Spring Boot) tidak rentan terhadap eksploit spesifik ini. Namun tim Spring menegaskan sifat celahnya lebih umum, jadi bisa ada jalur eksploitasi lain. Karena itu, update tetap dianjurkan walaupun aplikasimu tidak memenuhi semua syarat di atas.

Bagaimana cara celah ini bekerja?

Spring MVC punya fitur data binding: parameter dari permintaan HTTP otomatis diisikan ke objek Java. Kalau formulir mengirim nama=Budi, Spring memanggil setNama("Budi") pada objek tujuan.

Masalahnya, binding ini bisa merambat ke properti bertingkat, termasuk class, lalu ke classLoader. Di JDK 9 ke atas, ada jalur baru lewat class.module.classLoader yang lolos dari perlindungan lama. Di Tomcat, jalur ini bisa mencapai pengaturan komponen pencatat log akses, sehingga penyerang bisa mengubah lokasi dan isi file log menjadi file JSP berisi web shell di folder aplikasi. Setelah itu, cukup panggil file tersebut lewat browser untuk menjalankan perintah di server.

Ringkasan perbaikan

Bagaimana dengan solusi darurat disallowedFields?

Bagi aplikasi yang belum bisa diupdate, tim Spring menyarankan menolak pola parameter seperti class.* dan *.class.* secara global lewat @ControllerAdvice yang mengatur WebDataBinder. Ada catatan penting: controller yang punya @InitBinder sendiri bisa menimpa pengaturan global ini. Jadi solusi ini perlu dicek ke seluruh controller, dan sebaiknya hanya dipakai sampai update bisa dijalankan.

Langkah praktis untuk tim IT

1. Inventaris aplikasi Java. Catat semua aplikasi yang memakai Spring, cara deploy (JAR atau WAR), versi JDK, dan versi Tomcat. Sering kali aplikasi lama buatan vendor justru yang terlupa.
2. Cek versi dependensi, termasuk dependensi turunan. Aplikasi bisa memakai Spring lewat pustaka lain tanpa tercantum langsung di pom.xml.
3. Update dan uji. Naikkan Spring Framework atau Spring Boot ke versi yang sudah diperbaiki. Bila ada lompatan versi besar, uji di lingkungan staging dulu.
4. Periksa tanda penyusupan. Cari file .jsp yang tidak dikenal di folder aplikasi Tomcat dan perubahan aneh pada konfigurasi log akses, terutama di server yang terbuka ke internet sejak 2022.
5. Pasang pemantauan. WAF bisa membantu memblokir pola permintaan berisi class.module.classLoader, tapi tetap anggap ini lapisan tambahan.

Celah seperti ini juga pengingat untuk membuat jadwal patch management yang mencakup pustaka aplikasi, bukan hanya sistem operasi. Untuk menentukan prioritas, kamu bisa memakai skor CVSS dan status di katalog KEV CISA. Bandingkan juga dengan pelajaran dari Log4Shell, celah Java lain yang dampaknya jauh lebih luas.