Ada banyak pembicaraan di internet tentang kerentanan di Log4J yang memungkinkan penyerang memicu eksekusi kode arbitrer dari jarak jauh jika Anda memiliki kemampuan untuk mengirim data ke aplikasi yang menggunakan pustaka log4j untuk mencatat peristiwa.
Serangan ini dapat dilakukan tanpa diautentikasiMisalnya, dengan memanfaatkan halaman autentikasi yang mencatat kesalahan autentikasi.
Cacat ini telah membuat perusahaan yang berspesialisasi dalam keamanan siber untuk bekerja pada acara tersebut dan menunjukkan bahwa jumlah serangan yang memanfaatkan kelemahan ini meningkat.
Anggota dari Apache Software Foundation telah mengembangkan tambalan untuk memperbaiki kerentanan dan itu adalah versi 2.15.0, selain fakta bahwa solusi yang mungkin juga telah diketahui untuk mengurangi risiko.
Apa itu Apache Log4j? Seberapa serius kesalahannya?
Bagi mereka yang masih belum tahu seberapa serius masalahnya, saya dapat memberi tahu Anda itu Pada tanggal 9 Desember, kerentanan ditemukan di luntuk merekam perpustakaan log4j Apache.
Perpustakaan ini banyak digunakan dalam proyek pengembangan aplikasi Java / J2EE serta penyedia solusi perangkat lunak berbasis Java / J2EE standar.
log4j termasuk mekanisme pencarian yang dapat digunakan untuk query melalui sintaks khusus dalam format string. Misalnya, dapat digunakan untuk meminta berbagai parameter seperti versi lingkungan Java melalui $ {java: version} dll.
Kemudian tentukan kunci jndi dalam string, mekanisme pencarian gunakan JNDI API. Secara default, semua permintaan dibuat dengan awalan java: comp / env / *; namun, penulis menerapkan opsi untuk menggunakan awalan khusus menggunakan titik dua di kunci.
Di sinilah letak kerentanannya: sijndi: ldap: // digunakan sebagai kunci, permintaan masuk ke server LDAP yang ditentukan. Protokol komunikasi lain seperti LDAPS, DNS, dan RMI juga dapat digunakan.
Oleh karena itu, server jarak jauh yang dikendalikan oleh penyerang dapat mengembalikan objek ke server yang rentan, yang dapat menyebabkan eksekusi kode arbitrer pada sistem atau kebocoran data rahasia.
Yang harus dilakukan penyerang hanyalah mengirim string khusus Melalui mekanisme yang menulis string ini ke file log dan oleh karena itu dikelola oleh perpustakaan Log4j.
Ini dapat dilakukan dengan permintaan HTTP sederhana, misalnya yang dikirim melalui formulir web, bidang data, dll., atau dengan jenis interaksi lainnya menggunakan pendaftaran sisi server.
Tenable mencirikan kerentanan sebagai "kerentanan paling penting dan kritis dalam dekade terakhir."
Bukti konsep telah diterbitkan. Kerentanan ini sekarang aktif dieksploitasi.
Tingkat keparahan kerentanan adalah Maksimal 10 pada skala CVSS.
Berikut adalah daftar sistem yang terpengaruh:
- Apache Log4j versi 2.0 hingga 2.14.1
- Apache Log4j versi 1.x (versi usang) tunduk pada konfigurasi khusus.
- Produk yang menggunakan versi rentan Apache Log4j - Sertifikat nasional Eropa mempertahankan daftar lengkap produk dan status kerentanannya
CERT-FR merekomendasikan untuk melakukan analisis menyeluruh terhadap log jaringan. Alasan berikut dapat digunakan untuk mengidentifikasi upaya untuk mengeksploitasi kerentanan ini saat digunakan di URL atau header HTTP tertentu sebagai agen pengguna
Akhirnya perlu disebutkan bahwa sangat disarankan untuk menggunakan log2.15.0j versi 4 sesegera mungkin.
Namun, jika terjadi kesulitan saat bermigrasi ke versi ini, solusi berikut dapat diterapkan untuk sementara:
Untuk aplikasi yang menggunakan versi 2.7.0 dan yang lebih baru dari pustaka log4j, dimungkinkan untuk melindungi dari serangan apa pun dengan memodifikasi format peristiwa yang akan dicatat dengan sintaks% m {nolookups} untuk data yang akan diberikan pengguna .
Modifikasi ini memerlukan modifikasi file konfigurasi log4j untuk menghasilkan versi aplikasi yang baru. Oleh karena itu, ini memerlukan pengulangan langkah-langkah validasi teknis dan fungsional sebelum menerapkan versi baru ini.
Untuk aplikasi yang menggunakan pustaka log2.10.0j versi 4 dan yang lebih baru, Anda juga dapat melindungi dari serangan apa pun dengan mengubah parameter konfigurasi log4j2.formatMsgNoLo