Beberapa minggu yang lalu berita tentang masalah keselamatan Log4j telah menjadikan ramai pengguna di rangkaian terbalik dan ia adalah salah satu kelemahan yang paling banyak dieksploitasi dan yang dilabelkan oleh ramai pakar sebagai «paling berbahaya dalam lama », Daripada kelemahan yang telah diketahui dalam rangkaian, kami bercakap tentang beberapa daripadanya di sini di blog dan kali ini kami telah menemui berita lain.
Dan ia adalah beberapa hari yang lalu berita telah dikeluarkan bahawa satu lagi kelemahan telah dikenal pasti dalam perpustakaan Log4j 2 (yang sudah disenaraikan di bawah CVE-2021-45105) dan yang, tidak seperti dua isu sebelumnya, diklasifikasikan sebagai berbahaya, tetapi tidak kritikal.
Masalah baru membenarkan penafian perkhidmatan dan menunjukkan dirinya dalam bentuk gelung dan penamatan yang tidak normal apabila memproses baris tertentu.
Kerentanan mempengaruhi sistem yang menggunakan carian konteks, seperti $ {ctx: var}, untuk menentukan format keluaran log.
yang Log4j versi 2.0-alpha1 hingga 2.16.0 tidak mempunyai perlindungan terhadap pengulangan yang tidak terkawal, apa membenarkan penyerang memanipulasi nilai yang digunakan sebagai penggantian untuk menyebabkan gelung tidak berkesudahan yang akan kehabisan ruang pada tindanan dan menyebabkan proses tergantung. Khususnya, masalah berlaku apabila menggantikan nilai seperti "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Selain itu, Perlu diingatkan bahawa penyelidik Blumira telah mencadangkan serangan ke atas aplikasi Java yang terdedah yang tidak menerima permintaan daripada rangkaian luaran, contohnya, sistem pembangun atau pengguna aplikasi Java boleh diserang dengan cara ini.
Intipati kaedah ialah jika terdapat proses Java yang terdedah pada sistem pengguna yang menerima sambungan rangkaian hanya daripada hos tempatan (localhost), atau memproses permintaan RMI (Invokasi Kaedah Jauh, port 1099), serangan boleh dilakukan oleh kod JavaScript yang dilaksanakan apabila pengguna membuka halaman berniat jahat dalam penyemak imbas. Untuk mewujudkan sambungan ke port rangkaian aplikasi Java dalam serangan sedemikian, API WebSocket digunakan, yang, tidak seperti permintaan HTTP, tiada sekatan asal yang sama digunakan (WebSocket juga boleh digunakan untuk mengimbas port rangkaian pada tempatan hos untuk menentukan pemacu rangkaian yang tersedia).
Keputusan menilai kerentanan perpustakaan yang dikaitkan dengan kebergantungan dengan Log4j yang diterbitkan oleh Google juga menarik. Menurut Google, masalah itu menjejaskan 8% daripada semua pakej dalam repositori Maven Central.
Khususnya, 35863 pakej Java berkaitan Log4j dengan kebergantungan langsung dan tidak langsung terdedah kepada kelemahan. Sebaliknya, Log4j digunakan sebagai pergantungan langsung tahap pertama hanya dalam 17% kes, dan dalam 83% pakej yang dilindungi oleh kerentanan, pengikatan dilakukan melalui pakej perantaraan yang bergantung pada Log4j, iaitu memberitahu. tanggungan tahap kedua dan tertinggi (21% - tahap kedua, 12% - ketiga, 14% - keempat, 26% - kelima, 6% - keenam).
Kepantasan pembaikan kelemahan masih meninggalkan banyak perkara yang diingini, seminggu selepas kelemahan dikenal pasti, daripada 35863 pakej yang dikenal pasti, masalah itu telah diperbaiki setakat ini hanya pada 4620, iaitu, pada 13%.
Perubahan pakej diperlukan untuk mengemas kini keperluan pergantungan dan menggantikan pengikatan versi lama dengan versi tetap Log4j 2 (Pakej Java mempraktikkan pengikatan kepada versi tertentu dan bukan julat terbuka yang membenarkan pemasangan versi terkini).
Penghapusan kelemahan dalam aplikasi Java dihalang oleh fakta bahawa program sering menyertakan salinan perpustakaan dalam penghantaran, dan ia tidak mencukupi untuk mengemas kini versi Log4j 2 dalam pakej sistem.
Sementara itu, Agensi Perlindungan Infrastruktur dan Keselamatan Siber A.S. mengeluarkan arahan kecemasan yang memerlukan agensi persekutuan mengenal pasti sistem maklumat yang terjejas oleh kelemahan Log4j dan memasang kemas kini yang menyekat masalah itu sebelum 23 Disember.
Sebaliknya, garis panduan telah diberikan sehingga 28 Disember, di mana organisasi mempunyai kewajipan untuk melaporkan kerja yang dijalankan. Untuk memudahkan pengenalpastian sistem bermasalah, senarai produk di mana manifestasi kelemahan telah disahkan telah disediakan (terdapat lebih daripada 23 ribu aplikasi dalam senarai).
Akhirnya, Perlu dinyatakan bahawa kelemahan telah diperbaiki dalam Log4j 2.17 yang diterbitkan beberapa hari yang lalu dan pengguna yang mempunyai kemas kini yang dilumpuhkan disyorkan untuk menjalankan kemas kini yang sepadan, sebagai tambahan kepada fakta bahawa bahaya kerentanan dikurangkan oleh fakta bahawa masalah itu hanya menunjukkan dirinya pada sistem dengan Java 8.
Fuente: https://logging.apache.org/