Πριν από λίγες εβδομάδες, η είδηση για τα προβλήματα ασφαλείας του Log4j έκανε πολλούς χρήστες στο δίκτυο ανάποδα και είναι ότι είναι ένα από τα ελαττώματα που έχουν γίνει αντικείμενο εκμετάλλευσης και που πολλοί ειδικοί έχουν χαρακτηρίσει ως "το πιο επικίνδυνο εδώ και πολύ καιρό", από τα τρωτά σημεία που αποκαλύφθηκαν στο δίκτυο για μερικά από αυτά. εδώ στο blog και με την ευκαιρία αυτή βρήκαμε τα νέα ενός άλλου.
Και είναι αυτό πριν από λίγες μέρες κυκλοφόρησε είδηση ότι εντοπίστηκε μια άλλη ευπάθεια στη βιβλιοθήκη Log4j 2 (το οποίο αναφέρεται ήδη στο CVE-2021-45105) και το οποίο, σε αντίθεση με τα δύο προηγούμενα τεύχη, χαρακτηρίστηκε ως επικίνδυνο, αλλά όχι κρίσιμο.
το νέο πρόβλημα επιτρέπει την άρνηση της υπηρεσίας και εκδηλώνεται με τη μορφή βρόχων και παραβάσεων κατά την επεξεργασία ορισμένων γραμμών.
Τρωτό επηρεάζει συστήματα που χρησιμοποιούν αναζήτηση περιβάλλοντος, όπως ${ctx: var}, για να προσδιορίσετε τη μορφή εξόδου του αρχείου καταγραφής.
ο Οι εκδόσεις Log4j από 2.0-alpha1 έως 2.16.0 στερούνταν προστασίας από επαναλαμβανόμενη αναδρομή, τι επέτρεψε σε έναν εισβολέα να χειραγωγήσει την τιμή που χρησιμοποιήθηκε στην αντικατάσταση για να δημιουργήσετε έναν ατελείωτο βρόχο που θα εξαντλούσε τον χώρο στοίβας και θα προκαλούσε τη διακοπή της διαδικασίας. Συγκεκριμένα, το πρόβλημα παρουσιάστηκε κατά την αντικατάσταση τιμών όπως "${${::-${::-$${::-j}}}}".
Επιπλέον, Μπορεί να σημειωθεί ότι οι ερευνητές της Blumira έχουν προτείνει μια επίθεση σε ευάλωτες εφαρμογές Java που δεν δέχονται αιτήματα από εξωτερικά δίκτυα, για παράδειγμα, συστήματα προγραμματιστών ή χρήστες εφαρμογών Java μπορούν να υποστούν επίθεση με αυτόν τον τρόπο.
Η ουσία της μεθόδου είναι ότι εάν υπάρχουν ευάλωτες διεργασίες Java στο σύστημα του χρήστη που δέχεται συνδέσεις δικτύου μόνο από τον localhost ή επεξεργάζεται αιτήματα RMI (Remote Method Invocation, port 1099), η επίθεση μπορεί να εκτελεστεί με εκτελεσμένο κώδικα JavaScript όταν ο χρήστης ανοίγει μια κακόβουλη σελίδα στο πρόγραμμα περιήγησης. Για τη δημιουργία σύνδεσης με τη θύρα δικτύου μιας εφαρμογής Java σε μια τέτοια επίθεση, χρησιμοποιείται το WebSocket API, στο οποίο, σε αντίθεση με τα αιτήματα HTTP, δεν ισχύουν περιορισμοί ίδιας προέλευσης (το WebSocket μπορεί επίσης να χρησιμοποιηθεί για τη σάρωση θυρών δικτύου στον τοπικό κεντρικό υπολογιστή για τον προσδιορισμό των διαθέσιμων προγραμμάτων οδήγησης δικτύου).
Ενδιαφέρον παρουσιάζουν επίσης τα αποτελέσματα της αξιολόγησης της ευπάθειας των βιβλιοθηκών που σχετίζονται με τις εξαρτήσεις με το Log4j που δημοσιεύει η Google. Σύμφωνα με την Google, το ζήτημα επηρεάζει το 8% όλων των πακέτων στο κεντρικό αποθετήριο Maven.
Συγκεκριμένα, 35863 πακέτα Java που σχετίζονται με το Log4j με άμεσες και έμμεσες εξαρτήσεις εκτέθηκαν σε τρωτά σημεία. Με τη σειρά του, το Log4j χρησιμοποιείται ως άμεση εξάρτηση του πρώτου επιπέδου μόνο στο 17% των περιπτώσεων και στο 83% των πακέτων που καλύπτονται από την ευπάθεια, η δέσμευση γίνεται μέσω ενδιάμεσων πακέτων που εξαρτώνται από το Log4j, δηλ. εξαρτήσεις του δεύτερου και υψηλότερου επιπέδου (21% - το δεύτερο επίπεδο, 12% - το τρίτο, 14% - το τέταρτο, 26% - το πέμπτο, 6% - το έκτο).
Ο ρυθμός διόρθωσης της ευπάθειας εξακολουθεί να αφήνει πολλά περιθώρια, μια εβδομάδα μετά τον εντοπισμό της ευπάθειας, από τα 35863 πακέτα που εντοπίστηκαν, το πρόβλημα έχει επιδιορθωθεί μέχρι στιγμής μόνο σε 4620, δηλαδή στο 13%.
Οι αλλαγές στα πακέτα είναι απαραίτητες για την ενημέρωση των απαιτήσεων εξάρτησης και την αντικατάσταση των συνδέσεων παλαιών εκδόσεων με σταθερές εκδόσεις του Log4j 2 (τα πακέτα Java εξασκούν τη δέσμευση σε μια συγκεκριμένη έκδοση, όχι σε ανοιχτό εύρος που επιτρέπει την εγκατάσταση της πιο πρόσφατης έκδοσης).
Η εξάλειψη της ευπάθειας στις εφαρμογές Java παρεμποδίζεται από το γεγονός ότι τα προγράμματα συχνά περιλαμβάνουν ένα αντίγραφο των βιβλιοθηκών στην παράδοση και δεν αρκεί η ενημέρωση της έκδοσης Log4j 2 στα πακέτα συστήματος.
Εν τω μεταξύ, η Υπηρεσία Κυβερνοασφάλειας και Προστασίας Υποδομών των ΗΠΑ εξέδωσε μια οδηγία έκτακτης ανάγκης που απαιτεί από τις ομοσπονδιακές υπηρεσίες να προσδιορίσουν συστήματα πληροφοριών που επηρεάζονται από την ευπάθεια Log4j και να εγκαταστήσουν ενημερώσεις που μπλοκάρουν το ζήτημα έως τις 23 Δεκεμβρίου.
Από την άλλη, δόθηκε κατευθυντήρια γραμμή μέχρι τις 28 Δεκεμβρίου, στην οποία οι φορείς είχαν την υποχρέωση να αναφέρουν τις εργασίες που πραγματοποιήθηκαν. Για την απλούστευση της αναγνώρισης προβληματικών συστημάτων, έχει καταρτιστεί κατάλογος προϊόντων στα οποία έχει επιβεβαιωθεί η εκδήλωση ευπάθειας (υπάρχουν περισσότερες από 23 χιλιάδες εφαρμογές στη λίστα).
Τέλος, Αξίζει να αναφέρουμε ότι η ευπάθεια επιδιορθώθηκε στο Log4j 2.17, το οποίο δημοσιεύτηκε πριν λίγες μέρες. Συνιστάται στους χρήστες που έχουν απενεργοποιημένες ενημερώσεις να ενημερώνονται ανάλογα, ενώ ο κίνδυνος της ευπάθειας μετριάζεται από το γεγονός ότι το πρόβλημα εκδηλώνεται μόνο σε συστήματα με Java 8.
πηγή: https://logging.apache.org/