Kerentanan Log4j, atau “Log4Shell”, dianggap sebagai salah satu kelemahan perangkat lunak paling fatal yang pernah ada. Apache telah menambal kelemahan tersebut pada bulan Desember 2021, namun tetap menjadi perhatian tim keamanan. Faktanya, kelemahan ini masih menjadi salah satu kerentanan keamanan yang paling banyak dieksploitasi.
Log4Shell bertahan karena paket perangkat lunak Apache Log4j yang dipengaruhinya adalah salah satu pustaka pencatatan yang paling banyak digunakan di dunia. Menemukan dan memperbaiki setiap instance Log4Shell diperkirakan akan memakan waktu satu dekade, menurut Departemen Keamanan Dalam Negeri AS.
Sementara itu, tim keamanan dapat mengambil beberapa langkah untuk mempercepat mitigasi dan remediasi Log4Shell di jaringan mereka.
Bergabunglah dengan para pemimpin keamanan yang mengandalkan Buletin Think untuk berita yang dikurasi tentang AI, keamanan siber, data, dan otomatisasi. Pelajari dengan cepat dari tutorial pakar dan penjelas—dikirimkan langsung ke kotak masuk Anda. Lihat Pernyataan Privasi IBM®.
Sebelum mempelajari cara mendeteksi dan menambal Log4Shell, penting untuk memahami sifat kerentanan tersebut.
Log4j adalah logger sumber terbuka (dikelola oleh Apache Software Foundation) yang merekam informasi dan peristiwa dalam sebuah program. Log4j bukan perangkat lunak mandiri tetapi paket kode yang dapat ditambahkan oleh pengembang ke aplikasi Java mereka sendiri. Kerangka kerja Apache Log4j digunakan di beberapa layanan terbesar di web, mulai dari infrastruktur jaringan seperti Amazon Web Services (AWS) dan solusi Cisco hingga aplikasi populer seperti Twitter dan Minecraft.
Beberapa versi Log4J—khususnya, Log4j 2.17.0 dan di yang lebih lama—memiliki kerentanan serius. Yang paling berbahaya di antaranya adalah Log4Shell (CVE-2021-44228; peringkat CVSS: 10), kerentanan zero-day eksekusi kode jarak jauh (RCE) yang ditemukan pada Log4j versi 2.14.1 dan yang lebih lama.
Log4Shell adalah hasil dari bagaimana versi Log4j yang rentan menangani Java Naming and Directory Interface (JNDI), API yang digunakan aplikasi Java untuk mengakses sumber daya yang dihosting di server eksternal. Aktor ancaman dapat mengambil hampir seluruh kendali atas sistem yang rentan dengan mengirimkan perintah pencarian JNDI yang berbahaya melalui Log4j. Perintah ini mengelabui aplikasi agar menjalankan kode arbitrer yang dapat melakukan hampir semua hal: mencuri data, menginstal ransomware, membuat perangkat offline, dan banyak lagi.
Serangan siber Log4Shell yang khas bekerja seperti ini:
Ketika Apache bekerja untuk menambal Log4Shell, para peneliti keamanan mengidentifikasi beberapa kelemahan terkait di beberapa versi Log4j. Termasuk di dalamnya:
Menemukan setiap instance Log4j yang rentan dalam jaringan bisa jadi sulit. Menurut perkiraan, Log4j muncul di jutaan aplikasi, yang berarti tim keamanan memiliki banyak aset untuk diperiksa.
Selanjutnya, Log4j sering muncul sebagai ketergantungan tidak langsung. Artinya, Log4j tidak secara langsung terkandung dalam kode sumber aset, tetapi muncul sebagai ketergantungan paket perangkat lunak atau integrasi yang diandalkan aset tersebut. Google melaporkan bahwa instance Log4j yang paling rentan memiliki kedalaman lebih dari satu level dalam rantai dependensi, dan beberapa di antaranya memiliki kedalaman sembilan level.
Konon, tim keamanan dapat mendeteksi kerentanan Log4j dengan taktik dan alat yang tepat.
Setiap versi Log4j 2 dari 2.0-beta9 hingga 2.17 rentan terhadap Log4Shell atau kelemahan terkait. Dengan kata lain, tim keamanan harus menemukan dan menangani versi Log4j apa pun dengan versi di bawah 2.17.1.
Log4Shell dan kekurangannya yang terkait hanya terdapat dalam file "Log4j-core" yang memberikan fungsionalitas inti Log4j. Kelemahan tidak terdapat dalam file "Log4j-api" yang mengontrol antarmuka antara aplikasi dan alat pencatat Log4j.
Log4j dapat muncul di dalam aset yang dikendalikan perusahaan, aset pihak ketiga yang digunakan perusahaan (misalnya layanan cloud), dan aset yang digunakan oleh penyedia layanan yang memiliki akses ke jaringan perusahaan. Meskipun Log4j kemungkinan besar muncul di aplikasi berbasis Java, Log4j juga dapat hadir di aplikasi bukan Java melalui dependensi dan integrasi.
Dalam aplikasi Java, pustaka seperti Log4j sering dikemas dalam file Java Archive atau "file JAR". File JAR dapat berisi file JAR lainnya yang pada gilirannya dapat berisi file JAR mereka sendiri, dan seterusnya. Untuk menemukan semua versi Log4j yang rentan, tim keamanan harus memeriksa semua tingkat file JAR, bukan hanya file tingkat atas.
Pakar merekomendasikan penggunaan kombinasi teknik untuk menemukan kerentanan Log4j.
Pencarian manual. Tim keamanan dapat mencari kelemahan Log4j secara manual. Mereka dapat menggunakan alat pengembangan seperti Apache Maven untuk menghasilkan pohon ketergantungan yang memetakan semua dependensi dalam aplikasi, atau mereka dapat menggunakan intelijen ancaman eksternal untuk mengidentifikasi aset yang terpengaruh. Sebagai contoh, Badan Keamanan Siber dan Keamanan Infrastruktur (CISA) menyusun daftar perangkat lunak yang diketahui menderita Log4Shell. Daftar ini tersedia di GitHub.
Pada sistem operasi Linux, Microsoft Windows, dan macOS, tim keamanan dapat mencari contoh Log4j dalam direktori file menggunakan antarmuka baris perintah.
Alat pemindaian kerentanan. Setelah penemuan Log4Shell, beberapa organisasi merilis alat gratis yang dirancang untuk menemukan kerentanan Log4j. Contohnya termasuk Log4j-sniffer dari Palantir dan pemindai dari Pusat Koordinasi CERT, di banyak lainnya.
Meskipun pemindai khusus masih tersedia, banyak solusi keamanan standar seperti pemindai kerentanan, platform manajemen permukaan serangan (ASM), dan solusi deteksi dan respons titik akhir (EDR) yang sekarang dapat mendeteksi kerentanan Log4j.
Karena Log4Shell dapat bersembunyi jauh di dalam rantai ketergantungan, tim keamanan dapat melengkapi pemindaian otomatis dengan metode yang lebih langsung, seperti uji penetrasi.
Perburuan ancaman. Menurut CISA, penyerang diketahui menggunakan Log4Shell untuk membobol jaringan dan kemudian menambal aset yang disusupi untuk menutupi jejak mereka. Karena itulah disarankan agar tim keamanan menganggap pelanggaran telah terjadi dan secara aktif mencari tanda-tanda eksploitasi Log4Shell.
Alat keamanan siber seperti solusi informasi keamanan dan manajemen peristiwa (SIEM) serta platform deteksi dan respons yang diperluas (XDR) dapat membantu mendeteksi aktivitas abnormal yang terkait dengan Log4Shell, seperti entri log yang aneh atau pola lalu lintas yang mencurigakan. Tim keamanan harus meluncurkan respons insiden penuh dan prosedur investigasi untuk setiap petunjuk yang mungkin akan Log4Shell, mengingat betapa seriusnya konsekuensi dari serangan ini.
Tim keamanan memiliki beberapa opsi saat mengatasi kerentanan Log4j.
Untuk remediasi lengkap Log4Shell dan kelemahan terkait, organisasi harus memperbarui semua contoh Log4j di jaringan mereka ke versi terbaru (atau setidaknya ke versi 2.17.1). Versi terbaru Log4j menghapus fungsi-fungsi yang dapat dieksploitasi oleh penyerang, dan menghentikan dukungan untuk protokol yang biasa disalahgunakan seperti LDAP.
Tidak ada patch tunggal di seluruh sistem yang tersedia, dan memperbarui Java itu sendiri tidak menyelesaikan masalah tersebut. Tim keamanan harus memperbarui setiap instance Log4j di setiap aset yang terpengaruh.
Peneliti keamanan setuju bahwa penambalan adalah solusi ideal. Jika penambalan tidak memungkinkan, organisasi dapat menggunakan langkah-langkah mitigasi lain untuk meminimalkan kemungkinan serangan.
Melarang pencarian pesan di aplikasi yang rentan. Penyerang menggunakan fitur Log4j yang disebut “penggantian pencarian pesan” untuk mengirim perintah berbahaya ke aplikasi yang rentan. Tim keamanan dapat secara manual melarang fungsi ini dengan mengubah properti sistem “log4j2.formatMsgnoLookups” menjadi “true” atau mengatur nilai variabel lingkungan “LOG4J_FORMAT_MSG_NO_LOOKUPS” menjadi “true.”
Meskipun menghapus fungsi substitusi pencarian pesan membuat penyerang lebih sulit untuk menyerang, langkah ini tidak menjamin tidak adanya penyalahgunaan. Pelaku kejahatan masih dapat menggunakan CVE-2021-45046 untuk mengirim pencarian JNDI berbahaya ke aplikasi dengan pengaturan non-default.
Menghapus kelas JNDIlookup dari aplikasi yang rentan. Di Log4j, kelas JNDILookup mengatur bagaimana alat pencatat menangani pencarian JNDI. Jika kelas ini dihapus dari direktori kelas Log4j, pencarian JNDI tidak dapat lagi dilakukan.
Apache mencatat bahwa perintah berikut dapat digunakan untuk menghapus kelas JNDIlookup dari aplikasi yang rentan:
zip -q -d log4j-core-*.jar org/apache/pencatatan/Log4j/core/lookup/JndiLookup.class
Meskipun metode ini lebih efektif daripada melarang pencarian pesan, metode ini tidak menghentikan penyerang melakukan upaya eksploitasi lainnya, seperti memicu denial-of-service melalui pencarian rekursif.
Memblokir potensi lalu lintas serangan Log4Shell. Tim keamanan dapat menggunakan firewall aplikasi web (WAF), sistem deteksi dan pencegahan intrusi (IDPS), EDR, dan alat keamanan siber lainnya untuk mencegat lalu lintas ke dan dari server yang dikendalikan penyerang dengan memblokir protokol yang umum digunakan seperti LDAP atau RMI. Tim keamanan juga dapat memblokir alamat IP yang terkait dengan serangan atau string yang biasanya digunakan penyerang dalam permintaan berbahaya, seperti "jndi," "ldap" dan "rmi."
Namun, penyerang dapat menyiasati pertahanan ini dengan menggunakan protokol dan alamat IP baru atau menyamarkan untai yang berbahaya.
Karantina aset yang terpengaruh. Jika semuanya gagal, tim keamanan dapat mengarantina aset yang terpengaruh sambil menunggu patch. Salah satu cara untuk melakukan ini adalah dengan menempatkan aset yang rentan di segmen jaringan yang terisolasi yang tidak dapat diakses secara langsung dari internet. WAF dapat ditempatkan di sekitar segmen jaringan ini untuk perlindungan ekstra.
Salah satu hal rumit tentang memperbaiki Log4Shell adalah bahwa kerentanan ini tidak selalu ditambal. Pada November 2022, Tenable melaporkan bahwa 29% aset yang masih rentan terhadap Log4Shell adalah "pengulangan" yang berarti bahwa mereka ditambal tetapi kelemahannya muncul kembali. Pengulangan terjadi ketika pengembang secara tidak sengaja menggunakan pustaka perangkat lunak berisi versi Log4j yang belum ditambal untuk membangun atau memperbarui aplikasi.
Meskipun para pengembang dapat meneliti kerangka kerja yang mereka gunakan dengan lebih cermat, versi Log4j yang rentan sangat mudah terlewat jika versi tersebut berada di beberapa tingkat dalam file JAR.
Menerapkan manajemen kerentanan formal dan program manajemen tambalan dapat memberi tim keamanan cara yang lebih efektif untuk memantau aset guna menemukan kerentanan Log4j. Pemindaian kerentanan dan pengujian penetrasi secara teratur dapat membantu dengan cepat mendeteksi kerentanan baru, baik Log4Shell maupun lainnya. Manajemen patch memastikan kerentanan baru ditutup segera setelah vendor merilis perbaikan.