Colleghi che utilizzano le versioni Exim 4.87...4.91 sui propri server di posta: aggiornano urgentemente alla versione 4.92, dopo aver prima arrestato Exim stesso per evitare l'hacking tramite CVE-2019-10149.
Diversi milioni di server in tutto il mondo sono potenzialmente vulnerabili, la vulnerabilità è classificata come critica (punteggio base CVSS 3.0 = 9.8/10). Gli aggressori possono eseguire comandi arbitrari sul tuo server, in molti casi da root.
Assicurati di utilizzare una versione fissa (4.92) o una a cui sono già state applicate le patch.
Oppure patch quello esistente, vedi thread .
Aggiornamento per CentOS 6: cm. — funziona anche per centos 7, se non è ancora arrivato direttamente da epel.
UPD: Ubuntu è interessato 18.04 e 18.10, è stato rilasciato un aggiornamento per loro. Le versioni 16.04 e 19.04 non sono interessate a meno che non siano installate opzioni personalizzate. Più dettagli .
Ora che il problema descritto viene sfruttato attivamente (presumibilmente da un bot), ho notato un'infezione su alcuni server (in esecuzione su 4.91).
Ulteriori letture sono rilevanti solo per coloro che l'hanno già "capito": è necessario trasportare tutto su un VPS pulito con un software nuovo o cercare una soluzione. Proviamo? Scrivi se qualcuno può superare questo malware.
Se tu, essendo un utente Exim e leggendo questo, non hai ancora aggiornato (non ti sei assicurato che sia disponibile la versione 4.92 o una versione con patch), fermati e corri ad aggiornare.
Per chi ci è già arrivato, continuiamo...
UPD: e dà il consiglio giusto:
Può esserci una grande varietà di malware. Lanciando la medicina per la cosa sbagliata e cancellando la coda, l'utente non sarà curato e potrebbe non sapere per cosa ha bisogno di essere curato.
L'infezione si nota in questo modo: [kthrotlds] carica il processore; su un VDS debole è al 100%, sui server è più debole ma evidente.
Dopo l'infezione, il malware cancella le voci cron, registrandosi lì solo per essere eseguito ogni 4 minuti, rendendo immutabile il file crontab. Crontab -e impossibile salvare le modifiche, restituisce un errore.
Immutabile può essere rimosso, ad esempio, in questo modo, quindi eliminare la riga di comando (1.5 kb):
chattr -i /var/spool/cron/root
crontab -e
Successivamente, nell'editor crontab (vim), elimina la riga e salva:dd
:wq
Tuttavia, alcuni dei processi attivi stanno sovrascrivendo di nuovo, sto cercando di capirlo.
Allo stesso tempo, ci sono un sacco di wget (o riccioli) attivi appesi agli indirizzi dello script di installazione (vedi sotto), li sto eliminando in questo modo per ora, ma ricominciano:
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}'`
Ho trovato lo script di installazione del Trojan qui (centos): /usr/local/bin/nptd... Non lo pubblico per evitarlo, ma se qualcuno è infetto e capisce gli script di shell, per favore studialo con più attenzione.
Aggiungerò man mano che le informazioni vengono aggiornate.
UPD 1: L'eliminazione di file (con chattr -i preliminare) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root non ha aiutato, né l'arresto del servizio - ho dovuto farlo crontab completamente per ora strappalo (rinomina il file bin).
UPD 2: Il programma di installazione del Trojan a volte si trovava anche in altri posti, la ricerca per dimensione ha aiutato:
trova / -dimensione 19825c
UPD 3: Attenzione! Oltre a disabilitare selinux, il trojan ne aggiunge anche uno proprio Chiave SSH in ${sshdir}/authorized_keys! E attiva i seguenti campi in /etc/ssh/sshd_config, se non sono già stati impostati su YES:
PermitRootLogin sì
Autenticazione RSA sì
PubkeyAuthentication sì
echo UsePAM sì
Autenticazione password sì
UPD 4: Per riassumere per ora: disabilita Exim, cron (con root), rimuovi urgentemente la chiave Trojan da ssh e modifica la configurazione di sshd, riavvia sshd! E non è ancora chiaro se questo aiuterà, ma senza di esso c’è un problema.
Ho spostato le informazioni importanti dai commenti sulle patch/aggiornamenti all'inizio della nota, in modo che i lettori inizino con queste.
UPD 5: che il malware ha cambiato le password in WordPress.
UPD 6: , proviamo! Dopo un riavvio o uno spegnimento, la medicina sembra scomparire, ma per ora almeno è tutto.
Chiunque faccia (o trovi) una soluzione stabile, scriva, aiuterete molti.
UPD 7: Egli scrive:
Se non hai già detto che il virus è resuscitato grazie a una lettera non inviata in Exim, quando provi a inviare nuovamente la lettera, viene ripristinata, cerca in /var/spool/exim4
Puoi cancellare l'intera coda Exim in questo modo:
exipick -i | xargs exim -Sig
Controllo del numero di voci in coda:
exim -bpc
AGGIORNAMENTO 8: Ancora una volta : FirstVDS ha offerto la sua versione dello script di trattamento, proviamolo!
UPD 9: Sembra fabbricaGrazie per la sceneggiatura!
La cosa principale è non dimenticare che il server era già compromesso e gli aggressori sarebbero riusciti a piazzare qualche altro oggetto atipico (non elencato nel contagocce).
Pertanto, è meglio passare a un server completamente installato (vds), o almeno continuare a monitorare l'argomento - se c'è qualcosa di nuovo, scrivi qui nei commenti, perché ovviamente non tutti passeranno a una nuova installazione...
UPD 10: Grazie ancora : ricorda che non sono infetti solo i server, ma anche Raspberry Pie tutti i tipi di macchine virtuali... Quindi, dopo aver salvato i server, non dimenticare di salvare le console video, i robot, ecc.
AGGIORNAMENTO 11: Da Nota importante per i guaritori manuali:
(dopo aver utilizzato l'uno o l'altro metodo per combattere questo malware)
Devi assolutamente riavviare: il malware si trova da qualche parte nei processi aperti e, di conseguenza, in memoria, e ne scrive uno nuovo su cron ogni 30 secondi
UPD 12: Exim ha un altro (?) malware in coda e ti consiglia di studiare prima il tuo problema specifico prima di iniziare il trattamento.
UPD 13: piuttosto, passa a un sistema pulito e trasferisci i file con estrema attenzione, perché Il malware è già disponibile al pubblico e può essere utilizzato in altri modi, meno ovvi e più pericolosi.
UPD 14: rassicurarci sul fatto che le persone intelligenti non scappano dalla radice: un'altra cosa :
Anche se non funziona da root, si verifica un hacking... Ho debian jessie UPD: stretch sul mio OrangePi, Exim è in esecuzione da Debian-exim e si verificano ancora attacchi di hacking, corone perse, ecc.
UPD 15: quando si passa da un server compromesso a un server pulito, non dimenticare l'igiene, :
Durante il trasferimento dei dati, prestare attenzione non solo ai file eseguibili o di configurazione, ma anche a tutto ciò che può contenere comandi dannosi (ad esempio, in MySQL potrebbe essere CREATE TRIGGER o CREATE EVENT). Inoltre, non dimenticare .html, .js, .php, .py e altri file pubblici (idealmente questi file, come altri dati, dovrebbero essere ripristinati da un archivio locale o da un altro archivio attendibile).
UPD 16: и : il sistema aveva una versione di Exim installata nei port, ma in realtà ne eseguiva un'altra.
Quindi tutti dopo l'aggiornamento dovresti assicurartene che stai utilizzando la nuova versione!
exim --versionAbbiamo risolto insieme la loro situazione specifica.
Il server utilizzava DirectAdmin e il suo vecchio pacchetto da_exim (vecchia versione, senza vulnerabilità).
Allo stesso tempo, con l'aiuto del gestore di pacchetti custombuild di DirectAdmin, infatti, è stata poi installata una versione più recente di Exim, che era già vulnerabile.
In questa particolare situazione, anche l'aggiornamento tramite custombuild ha aiutato.
Non dimenticare di fare dei backup prima di tali esperimenti e di assicurarti anche che prima/dopo l'aggiornamento tutti i processi Exim siano della vecchia versione e non "bloccato" nella memoria.
Fonte: habr.com