Jika menemukan satu kelemahan yang mudah dieksploitasi dan sangat berbahaya di perpustakaan logging Java yang ada di mana-mana Apache Log4j belum mengubah komunitas keamanan Internet, para peneliti sekarang telah menemukan kerentanan baru di patch Apache yang dikeluarkan untuk menguranginya.
Peneliti keamanan Kamis lalu mulai memperingatkan bahwa kerentanan yang dilacak sebagai CVE-2021-44228 di Apache Log4j sedang diserang secara aktif dan memiliki potensi, menurut banyak laporan, untuk merusak internet. Dijuluki Log4Shell oleh LunaSec, kelemahannya berada di perpustakaan logging Java yang digunakan secara luas dan merupakan bug eksekusi kode jarak jauh (RCE) yang mudah dieksploitasi di banyak layanan dan produk. baik server atau klien yang menjalankan Minecraft versi Java dengan memanipulasi pesan log, termasuk dari teks yang diketik ke dalam pesan obrolan. Kemudian penyerang mulai bercabang, menelurkan 60 atau lebih mutasi yang lebih besar dari eksploit asli dalam satu hari.
Untuk pujiannya, Apache buru-buru merilis patch untuk memperbaiki Log4Shell dengan Log4j versi 2.15.0 Jumat lalu. Tetapi sekarang para peneliti telah menemukan bahwa perbaikan ini “tidak lengkap dalam konfigurasi non-default tertentu” dan membuka jalan bagi serangan penolakan layanan (DoS) dalam skenario tertentu, menurut penasihat keamanan oleh Apache.org.
Kecacatan yang baru ditemukan, dilacak sebagai CVE-2021-45046, dapat memungkinkan penyerang dengan kontrol atas data input Thread Context Map (MDC) untuk membuat data input berbahaya menggunakan pola Pencarian Java Naming and Directory Interface (JNDI) dalam kasus tertentu, yang mengakibatkan serangan DoS, menurut the advisory.
Set-up untuk exploit adalah ketika konfigurasi logging menggunakan Pattern Layout non-default dengan Context Lookup – misalnya, $${ctx:loginId} – atau pola Thread Context Map (%X, %mdc , atau %MDC), menurut penasehat.
“Log4j 2.15.0 membatasi pencarian JNDI LDAP ke localhost secara default,” menurut Apache.org. “Perhatikan bahwa mitigasi sebelumnya yang melibatkan konfigurasi seperti menyetel properti sistem log4j2.noFormatMsgLookup ke true TIDAK mengurangi kerentanan khusus ini.”
Memperbaiki Fix
Rilis baru Log4j, versi 2.16.0, memperbaiki masalah dengan menghapus dukungan untuk pola pencarian pesan dan menonaktifkan fungsionalitas JNDI secara default, menurut saran tersebut. Untuk mengurangi bug di rilis Log4j sebelumnya, pengembang dapat menghapus kelas JndiLookup dari classpath, Apache.org menyarankan.
One profesional keamanan mencatat bahwa mungkin Apache tergesa-gesa untuk merilis patch untuk Log4Shell setelah kepanikan awal atas penemuannya mungkin telah secara tidak sengaja menyebabkan CVE.
terbaru”Sering terburu-buru tambalan untuk memperbaiki kerentanan berarti bahwa perbaikan mungkin tidak lengkap, karena kasusnya ada di sini,” kata John Bambenek, pemburu ancaman utama di Netenrich, dalam email ke Threatpost pada hari Selasa. Dia mengatakan solusi untuk masalah ini adalah “untuk menonaktifkan fungsionalitas JNDI sepenuhnya.” classpath – “sebaiknya semua yang di atas,” kata Bambenek.
Menangani Situasi
Peneliti dan profesional keamanan masih memikirkan implikasi luas dan luas dari Log4Shell serta potensi yang tersisa untuk lebih banyak bug terkait untuk ditemukan, profesional keamanan lainnya mencatat.
“Ketika kerentanan ditemukan dan membuat kebisingan sebanyak Log4Shell, itu selalu menandakan bahwa ada kerentanan tambahan dalam perangkat lunak yang sama atau perbaikan untuk perangkat lunak itu dan memicu penelitian dan penemuan tambahan,” Casey Ellis, pendiri dan CTO di Bugcrowd, menulis dalam email ke Threatpost.
Memang, sudah ada beberapa kebingungan tentang bagaimana m setiap kerentanan yang saat ini ada yang terkait dengan Log4Shell dan bagaimana mereka semua berkorelasi satu sama lain, menambah longsoran informasi yang dipublikasikan tentang bug tersebut, tulis peneliti dari RiskBased Security dalam posting blog yang diterbitkan Selasa.
Pada titik ini, saat ini ada tiga CVE yang diterbitkan terkait dengan Log4Shell – CVE-2021-44228, zero-day asli; CVE-2021-45046, “perbaikan tidak lengkap”; dan CVE-2021-4104, cacat yang ditemukan di komponen lain dari Log4j, JMSAppender, yang tampaknya tidak menjadi perhatian besar, menurut tim Keamanan Berbasis Risiko.
Dalam kasus CVE-2021-44228, para peneliti berpendapat bahwa itu bukan masalah baru sama sekali, “tetapi benar-benar kerentanan yang sama,” menurut post.
“MITRE dan CVE Numbering Authorities (CNA) akan menetapkan ID CVE kedua jika perbaikan tidak sepenuhnya menambal masalah,” peneliti menulis. “Ini membantu beberapa organisasi dalam melacak masalah sambil menimbulkan kebingungan kepada orang lain.”
Dan meskipun ada lebih dari satu CVE, “tempat telah memperlakukan mereka sebagai satu masalah, tapi ini jelas bukan masalahnya,” menurut RiskBased Security.
Lebih Buruk Sebelum Menjadi Lebih Baik
Satu hal yang pasti tentang drama pemasangan di sekitar Log4Shell adalah, karena permukaan serangan untuk kerentanan sangat luas, ada potensi besar untuk eksploitasi ekstensif dan lebih lanjut, menurut RiskBased Security.
“Penting untuk menelepon bahwa Log4j adalah kerangka kerja logging yang populer di Jawa,” tulis para peneliti dalam postingan tersebut. “Ini berarti digunakan dalam banyak hal.”
Memang, daftar panjang produk vendor rentan terhadap Log4Shell, termasuk namun tidak terbatas pada: Broadcom, Cisco, Elasticsearch, F-secure, Fedora, HP, IBM, Microsoft , National Security Agency (NSA), RedHat, SonicWall, dan VMWare.
Dalam beberapa jam setelah pengungkapan kelemahan tersebut kepada publik, penyerang memindai server yang rentan dan melepaskan serangan untuk menjatuhkan penambang koin, malware Cobalt Strike, ransomware Khonsari baru, remote Orcus akses trojan (RAT). membalikkan bash shell untuk serangan di masa mendatang, Mirai dan botnet lainnya, dan backdoors.
Apa pun yang terjadi ke depan, karena variasi untuk eksploitasi asli terus muncul dan penyerang terus berkerumun, situasinya kemungkinan akan memburuk sebelum menjadi lebih baik. Ini berarti bahwa debu di atas Log4Shell mungkin tidak akan bertahan lama.
“Kerentanan Log4j baru ini kemungkinan akan menghantui kita selama bertahun-tahun yang akan datang,” menurut RiskBased Security.