Ενημερώστε επειγόντως το Exim σε 4.92 - υπάρχει ενεργή μόλυνση

Συνάδελφοι που χρησιμοποιούν τις εκδόσεις Exim 4.87...4.91 στους διακομιστές αλληλογραφίας τους - ενημερώστε επειγόντως στην έκδοση 4.92, έχοντας προηγουμένως διακόψει την ίδια την Exim για να αποφύγουν την εισβολή μέσω του CVE-2019-10149.

Αρκετά εκατομμύρια διακομιστές σε όλο τον κόσμο είναι δυνητικά ευάλωτοι, η ευπάθεια αξιολογείται ως κρίσιμη (βασική βαθμολογία CVSS 3.0 = 9.8/10). Οι εισβολείς μπορούν να εκτελούν αυθαίρετες εντολές στον διακομιστή σας, σε πολλές περιπτώσεις από το root.

Βεβαιωθείτε ότι χρησιμοποιείτε μια σταθερή έκδοση (4.92) ή μια που έχει ήδη επιδιορθωθεί.
Ή διορθώστε το υπάρχον, δείτε το νήμα άψογο σχόλιο.

Ενημέρωση για CentOS 6: εκ. σχόλιο του Theodor — για το centos 7 λειτουργεί επίσης, αν δεν έχει φτάσει ακόμα απευθείας από την epel.

UPD: Το Ubuntu επηρεάζεται 18.04 και 18.10, έχει κυκλοφορήσει μια ενημέρωση για αυτούς. Οι εκδόσεις 16.04 και 19.04 δεν επηρεάζονται, εκτός εάν έχουν εγκατασταθεί προσαρμοσμένες επιλογές σε αυτές. Περισσότερες λεπτομέρειες στον επίσημο ιστότοπό τους.

Πληροφορίες για το πρόβλημα στο Opennet
Πληροφορίες στην ιστοσελίδα Exim

Τώρα γίνεται ενεργή εκμετάλλευση του προβλήματος που περιγράφεται εκεί (προφανώς από ένα bot), παρατήρησα μια μόλυνση σε ορισμένους διακομιστές (που εκτελούνται σε 4.91).

Η περαιτέρω ανάγνωση είναι σχετική μόνο για όσους το έχουν ήδη «αποκτήσει» - πρέπει είτε να μεταφέρετε τα πάντα σε ένα καθαρό VPS με νέο λογισμικό ή να αναζητήσετε μια λύση. Να προσπαθήσουμε; Γράψτε αν κάποιος μπορεί να ξεπεράσει αυτό το κακόβουλο λογισμικό.

Εάν είστε χρήστης του Exim και διαβάζετε αυτό το άρθρο, δεν έχετε ακόμα ενημερώσει (δεν έχετε βεβαιωθεί ότι είναι διαθέσιμη η έκδοση 4.92 ή μια ενημερωμένη έκδοση), σταματήστε και εκτελέστε την ενημέρωση.

Για όσους έχουν ήδη φτάσει εκεί, ας συνεχίσουμε...

UPD: Το supersmile2009 βρήκε άλλον τύπο κακόβουλου λογισμικού και δίνει τις σωστές συμβουλές:

Μπορεί να υπάρχει μεγάλη ποικιλία κακόβουλου λογισμικού. Με την εκτόξευση του φαρμάκου για το λάθος πράγμα και την εκκαθάριση της ουράς, ο χρήστης δεν θα θεραπευτεί και μπορεί να μην ξέρει τι χρειάζεται να λάβει θεραπεία.

Η μόλυνση είναι αισθητή ως εξής: [kthrotlds] φορτώνει τον επεξεργαστή. σε ένα αδύναμο VDS είναι 100%, στους διακομιστές είναι πιο αδύναμο αλλά αισθητό.

Μετά τη μόλυνση, το κακόβουλο λογισμικό διαγράφει τις εγγραφές cron, καταχωρώντας μόνο τον εαυτό του εκεί για να εκτελείται κάθε 4 λεπτά, ενώ κάνει το αρχείο crontab αμετάβλητο. Crontab -ε δεν μπορεί να αποθηκεύσει τις αλλαγές, δίνει ένα σφάλμα.

Το Immutable μπορεί να αφαιρεθεί, για παράδειγμα, ως εξής, και στη συνέχεια να διαγράψετε τη γραμμή εντολών (1.5 kb):

chattr -i /var/spool/cron/root
crontab -e

Στη συνέχεια, στο πρόγραμμα επεξεργασίας crontab (vim), διαγράψτε τη γραμμή και αποθηκεύστε:dd
:wq

Ωστόσο, ορισμένες από τις ενεργές διεργασίες αντικαθίστανται ξανά, το καταλαβαίνω.

Ταυτόχρονα, υπάρχουν ένα σωρό ενεργά wgets (ή μπούκλες) που κρέμονται στις διευθύνσεις από το σενάριο εγκατάστασης (δείτε παρακάτω), τα καταρρίπτω έτσι προς το παρόν, αλλά ξεκινούν ξανά:

ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`

Βρήκα το σενάριο εγκατάστασης Trojan εδώ (centos): /usr/local/bin/nptd... Δεν το δημοσιεύω για να το αποφύγω, αλλά αν κάποιος έχει μολυνθεί και κατανοεί σενάρια φλοιού, παρακαλώ μελετήστε το πιο προσεκτικά.

Θα προσθέσω καθώς ενημερώνονται οι πληροφορίες.

UPD 1: Η διαγραφή αρχείων (με προκαταρκτικό chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root δεν βοήθησε, ούτε η διακοπή της υπηρεσίας - έπρεπε να crontab εντελώς προς το παρόν, σκίστε το (μετονομάστε το αρχείο bin).

UPD 2: Το πρόγραμμα εγκατάστασης Trojan μερικές φορές βρισκόταν επίσης σε άλλα μέρη, η αναζήτηση κατά μέγεθος βοήθησε:
εύρεση / -μέγεθος 19825c

UPD3: Προσοχή! Εκτός από την απενεργοποίηση του selinux, το Trojan προσθέτει και το δικό του Κλειδί SSH σε ${sshdir}/authorized_keys! Και ενεργοποιεί τα ακόλουθα πεδία στο /etc/ssh/sshd_config, εάν δεν έχουν ήδη οριστεί σε YES:
PermitRootLogin ναι
Έλεγχος ταυτότητας RSAA ναι
PubkeyAuthentication ναι
echo UsePAM ναι
PasswordAuthentication ναι

UPD 4: Για να συνοψίσουμε αυτή τη στιγμή: απενεργοποιήστε το Exim, cron (με ρίζες), αφαιρέστε επειγόντως το κλειδί Trojan από το ssh και επεξεργαστείτε τη διαμόρφωση sshd, επανεκκινήστε το sshd! Και δεν είναι ακόμη σαφές ότι αυτό θα βοηθήσει, αλλά χωρίς αυτό υπάρχει πρόβλημα.

Μετέφερα σημαντικές πληροφορίες από τα σχόλια σχετικά με τα patches/ενημερώσεις στην αρχή της σημείωσης, ώστε οι αναγνώστες να ξεκινήσουν με αυτό.

UPD5: Γράφει ο AnotherDenny ότι το κακόβουλο λογισμικό άλλαξε τους κωδικούς πρόσβασης στο WordPress.

UPD6: Ο Paulmann ετοίμασε μια προσωρινή θεραπεία, ας δοκιμάσουμε! Μετά από επανεκκίνηση ή τερματισμό λειτουργίας, το φάρμακο φαίνεται να εξαφανίζεται, αλλά προς το παρόν τουλάχιστον αυτό είναι.

Όποιος κάνει (ή βρει) μια σταθερή λύση ας γράψει, θα βοηθήσεις πολλούς.

UPD7: Χρήστης clsv γράφει:

Εάν δεν έχετε ήδη πει ότι ο ιός έχει αναστηθεί χάρη σε μια μη απεσταλμένη επιστολή στο Exim, όταν προσπαθείτε να στείλετε ξανά το γράμμα, αποκαθίσταται, κοιτάξτε στο /var/spool/exim4

Μπορείτε να διαγράψετε ολόκληρη την ουρά Exim ως εξής:
exipick -i | xargs exim -Mrm
Έλεγχος του αριθμού των καταχωρήσεων στην ουρά:
exim -bpc

UPD 8: Και πάλι ευχαριστώ για τις πληροφορίες AnotherDenny: Η FirstVDS πρόσφερε την έκδοση του σεναρίου θεραπείας, ας το δοκιμάσουμε!

UPD 9: Μοιάζει έργα, ευχαριστώ Κύριλλος για το σενάριο!

Το κύριο πράγμα είναι να μην ξεχνάμε ότι ο διακομιστής είχε ήδη παραβιαστεί και οι εισβολείς θα μπορούσαν να είχαν καταφέρει να φυτέψουν μερικά πιο άτυπα άσχημα πράγματα (δεν αναφέρονται στο σταγονόμετρο).

Επομένως, είναι καλύτερο να μετακινηθείτε σε έναν πλήρως εγκατεστημένο διακομιστή (vds), ή τουλάχιστον να συνεχίσετε να παρακολουθείτε το θέμα - εάν υπάρχει κάτι νέο, γράψτε στα σχόλια εδώ, επειδή προφανώς δεν θα προχωρήσουν όλοι σε μια νέα εγκατάσταση...

UPD 10: Ευχαριστώ και πάλι clsv: υπενθυμίζει ότι δεν έχουν μολυνθεί μόνο οι διακομιστές, αλλά και Raspberry Pi, και κάθε είδους εικονικές μηχανές... Μετά την αποθήκευση των διακομιστών, μην ξεχάσετε να αποθηκεύσετε τις κονσόλες βίντεο, τα ρομπότ κ.λπ.

UPD 11: Από συγγραφέας του σεναρίου θεραπείας Σημαντική σημείωση για χειροκίνητους θεραπευτές:
(μετά τη χρήση μιας ή άλλης μεθόδου καταπολέμησης αυτού του κακόβουλου λογισμικού)

Πρέπει οπωσδήποτε να κάνετε επανεκκίνηση - το κακόβουλο λογισμικό βρίσκεται κάπου σε ανοιχτές διεργασίες και, κατά συνέπεια, στη μνήμη, και γράφει από μόνο του ένα νέο για cron κάθε 30 δευτερόλεπτα

UPD12: Το supersmile2009 βρέθηκε Το Exim έχει ένα άλλο(;) κακόβουλο λογισμικό στην ουρά του και σας συμβουλεύει να μελετήσετε πρώτα το συγκεκριμένο πρόβλημά σας πριν ξεκινήσετε τη θεραπεία.

UPD13: συμβουλεύει ο lorc μάλλον, μεταβείτε σε ένα καθαρό σύστημα και μεταφέρετε αρχεία εξαιρετικά προσεκτικά, γιατί Το κακόβουλο λογισμικό είναι ήδη δημοσίως διαθέσιμο και μπορεί να χρησιμοποιηθεί με άλλους, λιγότερο προφανείς και πιο επικίνδυνους τρόπους.

UPD 14: καθησυχάζοντας τον εαυτό μας ότι οι έξυπνοι άνθρωποι δεν τρέχουν από τη ρίζα - κάτι ακόμα επείγον μήνυμα από το clsv:

Ακόμα κι αν δεν λειτουργεί από το root, συμβαίνει hacking... Έχω το debian jessie UPD: stretch στο OrangePi μου, το Exim εκτελείται από το Debian-exim και εξακολουθεί να έχει γίνει hacking, χάνονται κορώνες κ.λπ.

UPD 15: όταν μετακινείστε σε έναν καθαρό διακομιστή από έναν παραβιασμένο, μην ξεχνάτε την υγιεινή, χρήσιμη υπενθύμιση από το w0den:

Κατά τη μεταφορά δεδομένων, δώστε προσοχή όχι μόνο σε εκτελέσιμα αρχεία ή αρχεία διαμόρφωσης, αλλά και σε οτιδήποτε μπορεί να περιέχει κακόβουλες εντολές (για παράδειγμα, στη MySQL αυτό θα μπορούσε να είναι CREATE TRIGGER ή CREATE EVENT). Επίσης, μην ξεχνάτε τα .html, .js, .php, .py και άλλα δημόσια αρχεία (ιδανικά αυτά τα αρχεία, όπως και άλλα δεδομένα, θα πρέπει να επαναφέρονται από τοπικό ή άλλο αξιόπιστο χώρο αποθήκευσης).

UPD16: daykkin и savage_me αντιμετώπισε ένα άλλο πρόβλημα: το σύστημα είχε μια έκδοση του Exim εγκατεστημένη στις θύρες, αλλά στην πραγματικότητα έτρεχε μια άλλη.

Όλοι λοιπόν μετά την ενημέρωση θα πρέπει να βεβαιωθείτε ότι χρησιμοποιείτε τη νέα έκδοση!

exim --version

Τακτοποιήσαμε τη συγκεκριμένη κατάστασή τους μαζί.

Ο διακομιστής χρησιμοποίησε το DirectAdmin και το παλιό του πακέτο da_exim (παλιά έκδοση, χωρίς ευπάθεια).

Ταυτόχρονα, με τη βοήθεια του custombuild πακέτου διαχείρισης του DirectAdmin, μάλιστα, εγκαταστάθηκε τότε μια νεότερη έκδοση του Exim, η οποία ήταν ήδη ευάλωτη.

Στη συγκεκριμένη περίπτωση, η ενημέρωση μέσω custombuild βοήθησε επίσης.

Μην ξεχάσετε να δημιουργήσετε αντίγραφα ασφαλείας πριν από τέτοια πειράματα και επίσης βεβαιωθείτε ότι πριν/μετά την ενημέρωση όλες οι διεργασίες Exim είναι της παλιάς έκδοσης σταμάτησαν και όχι «κολλημένο» στη μνήμη.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο