Beberapa minggu yang lalu berita tentang masalah keamanan Log4j membuat banyak pengguna di jaringan terbalik dan itu adalah salah satu kelemahan yang paling banyak dieksploitasi dan yang oleh banyak ahli dicap sebagai «paling berbahaya di dunia. lama », Dari kerentanan yang diketahui di jaringan, kami berbicara tentang beberapa di antaranya di sini di blog dan kali ini kami telah menemukan berita lain.
Dan itu beberapa hari yang lalu berita dirilis bahwa kerentanan lain diidentifikasi di perpustakaan Log4j 2 (yang sudah terdaftar di bawah CVE-2021-45105) dan yang, tidak seperti dua masalah sebelumnya, diklasifikasikan sebagai berbahaya, tetapi tidak kritis.
Masalah baru memungkinkan penolakan layanan dan memanifestasikan dirinya dalam bentuk loop dan penghentian abnormal saat memproses baris tertentu.
Kerentanan memengaruhi sistem yang menggunakan penelusuran konteks, seperti $ {ctx: var}, untuk menentukan format keluaran log.
itu Log4j versi 2.0-alpha1 hingga 2.16.0 tidak memiliki perlindungan terhadap rekursi yang tidak terkontrol, apa memungkinkan penyerang untuk memanipulasi nilai yang digunakan dalam substitusi menyebabkan loop tak berujung yang akan kehabisan ruang pada stack dan menyebabkan proses hang. Secara khusus, masalah terjadi saat mengganti nilai seperti "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Selain itu, Dapat dicatat bahwa peneliti Blumira telah mengusulkan serangan terhadap aplikasi Java yang rentan yang tidak menerima permintaan dari jaringan eksternal, misalnya, sistem pengembang atau pengguna aplikasi Java dapat diserang dengan cara ini.
Inti dari metode ini adalah jika ada proses Java yang rentan pada sistem pengguna yang menerima koneksi jaringan hanya dari host lokal (localhost), atau memproses permintaan RMI (Remote Method Invocation, port 1099), serangan dapat dilakukan dengan kode JavaScript yang dieksekusi ketika pengguna membuka halaman berbahaya di browser. Untuk membuat koneksi ke port jaringan aplikasi Java dalam serangan seperti itu, API WebSocket digunakan, yang, tidak seperti permintaan HTTP, tidak ada batasan asal yang sama diterapkan (WebSocket juga dapat digunakan untuk memindai port jaringan di port lokal host untuk menentukan driver jaringan yang tersedia).
Hasil evaluasi kerentanan perpustakaan yang terkait dengan dependensi dengan Log4j yang diterbitkan oleh Google juga menarik. Menurut Google, masalahnya mempengaruhi 8% dari semua paket di repositori Maven Central.
Secara khusus, 35863 paket Java terkait Log4j dengan dependensi langsung dan tidak langsung terkena kerentanan. Pada gilirannya, Log4j digunakan sebagai ketergantungan langsung tingkat pertama hanya dalam 17% kasus, dan dalam 83% paket yang tercakup oleh kerentanan, pengikatan dilakukan melalui paket perantara yang bergantung pada Log4j, yaitu. dependensi tingkat kedua dan tertinggi (21% - tingkat kedua, 12% - ketiga, 14% - keempat, 26% - kelima, 6% - keenam).
Tingkat perbaikan kerentanan masih menyisakan banyak yang harus diinginkan, seminggu setelah kerentanan diidentifikasi, dari 35863 paket yang diidentifikasi, masalah telah diperbaiki sejauh ini hanya di 4620, yaitu menjadi 13%.
Perubahan pada paket diperlukan untuk memperbarui persyaratan ketergantungan dan mengganti pengikatan versi lama dengan versi tetap Log4j 2 (Paket Java mempraktikkan pengikatan ke versi tertentu, dan bukan rentang terbuka yang memungkinkan penginstalan versi terbaru).
Penghapusan kerentanan dalam aplikasi Java terhambat oleh kenyataan bahwa program sering kali menyertakan salinan perpustakaan dalam pengiriman, dan tidak cukup untuk memperbarui versi Log4j 2 dalam paket sistem.
Sementara itu, Badan Perlindungan Infrastruktur dan Keamanan Siber A.S. mengeluarkan arahan darurat yang mengharuskan lembaga federal untuk mengidentifikasi sistem informasi yang terpengaruh oleh kerentanan Log4j dan menginstal pembaruan yang memblokir masalah sebelum 23 Desember.
Di sisi lain, pedoman diberikan hingga 28 Desember, di mana organisasi memiliki kewajiban untuk melaporkan pekerjaan yang dilakukan. Untuk menyederhanakan identifikasi sistem yang bermasalah, daftar produk di mana manifestasi kerentanan telah dikonfirmasi (ada lebih dari 23 ribu aplikasi dalam daftar).
Akhirnya, Perlu disebutkan bahwa kerentanan telah diperbaiki di Log4j 2.17 yang diterbitkan beberapa hari yang lalu dan pengguna yang pembaruannya dinonaktifkan disarankan untuk melakukan pembaruan yang sesuai, selain fakta bahwa bahaya kerentanan dikurangi dengan fakta bahwa masalahnya hanya muncul pada sistem dengan Java 8.
sumber: https://logging.apache.org/