Colleghi, chi utilizza nei propri server di posta Exim versioni 4.87…4.91 deve aggiornare urgentemente alla versione 4.92, dopo aver prima arrestato Exim per evitare attacchi tramite CVE-2019-10149.
Potenzialmente vulnerabili sono diversi milioni di server in tutto il mondo, la vulnerabilità è classificata come critica (CVSS 3.0 base score = 9.8/10). Gli aggressori possono eseguire comandi arbitrari sul vostro server, in molti casi come root.
Si prega di assicurarsi di utilizzare la versione corretta (4.92) o già patchata.
Oppure patchate l'esistente, vedere il thread .
Aggiornamento per centos 6: vedere — per centos 7 funziona anche, se non è ancora arrivato direttamente dall'epel.
UPD: Ubuntu colpiti 18.04 e 18.10, è stato rilasciato un aggiornamento per loro. Le versioni 16.04 e 19.04 non sono colpite, a meno che non siano state installate versioni personalizzate. Maggiori dettagli .
Attualmente il problema descritto lì è attivamente sfruttato (da un bot, si presume), l'ho notato su alcuni dei miei server (che giravano su 4.91) infettati.
Continuare a leggere è pertinente solo per chi è già "infiltrato" — bisogna o trasferire tutto su una VPS pulita con software aggiornato, o cercare una soluzione. Proviamo? Scriveteci se qualcuno può combattere questo malware.
Se siete utenti di Exim e leggendo questo non vi siete ancora aggiornati (non vi siete assicurati di avere la versione 4.92 o una versione patchata), vi prego di fermarvi e andare ad aggiornarvi.
Per chi è già colpito — continuiamo…
UPD: e dà un consiglio corretto:
I malware possono essere moltissimi. Avviando una cura sbagliata e pulendo la coda, l'utente non si curerà e potrebbe non sapere da cosa deve curarsi.
L'infezione si manifesta così: [kthrotlds] carica il processore; su un VDS debole al 100%, sui server più deboli è comunque evidente.
Dopo l'infezione, il malware elimina le voci nel cron, registrando solo se stesso per l'avvio ogni 4 minuti, mentre il file crontab diventa immutabile. Crontab -e non può salvare le modifiche e restituisce un errore.
L'immutabile può essere rimosso ad esempio così, dopo di che cancellare la riga del comando (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Poi, lì nell'editor crontab (vim) cancelliamo la riga e salviamo:dd
:wq
Tuttavia, qualche processo attivo riscrive di nuovo, sto indagando.
Nel frattempo ci sono molti wget (o curl) attivi agli indirizzi dello script dell'installatore (vedi sotto), per il momento li blocco così, ma si riavviano di nuovo:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Fermando..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Lo script dell'installatore del trojan si trova qui (centos): \/usr\/local\/bin\/nptd… non lo pubblico per evitare problemi, ma se qualcuno è infetto e sa lavorare con gli script shell, per favore esamini attentamente.
Aggiungerò informazioni man mano che verranno aggiornate.
UPD 1: Rimozione dei file (con pre-esecuzione di chattr -i) \/etc\/cron.d\/root, \/etc\/crontab, rm -Rf \/var\/spool\/cron\/root non ha aiutato, così come fermare il servizio — è stato necessario rimuovere completamente il crontab (rinominare il file bin).
UPD 2: L'installatore del trojan si trovava a volte anche in altre posizioni, la ricerca per dimensione ha aiutato:
find \/ -size 19825c
UPD 3: Attenzione! Oltre a disabilitare selinux, il trojan aggiunge anche il suo chiave SSH in ${sshdir}\/authorized_keys! E attiva i seguenti campi in \/etc\/ssh\/sshd_config, se non erano già stati scritti come YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Riassumendo fino ad ora: disabilitiamo exim, cron (con privilegio root), rimuoviamo urgentemente la chiave trojan da ssh e modifichiamo il config sshd, riavviamo sshd! E al momento non è chiaro se questo aiuterà, ma senza questo è veramente un disastro.
Ho spostato le informazioni importanti dai commenti riguardo ai patch/aggiornamenti all'inizio della nota, affinché quelli che leggono da essa possano cominciare.
UPD 5: che il malware ha cambiato le password in WordPress.
UPD 6: , la stiamo testando! Dopo il riavvio o la disattivazione di questa soluzione sembra che non funzioni più, ma per ora va bene così.
Chi realizzerà (o troverà) una soluzione stabile, per favore scriva, aiuterete molti.
UPD 7: scrive:
Se non l'hanno già detto, il virus si riattiva grazie a un'email non inviata in exim, durante il tentativo di inviare nuovamente l'email si ripristina, controlla in \/var\/spool\/exim4
È possibile pulire l'intera coda di exim in questo modo:
exipick -i | xargs exim -Mrm
Controllo del numero di registrazioni in coda:
exim -bpc
UPD 8: Ancora : FirstVDS ha proposto la propria versione dello script per la cura, iniziamo a testarla!
UPD 9: Sembra che sulla tecnologia Dac. Il sistema monitora lo stato dell'hardware tramite sensori installati nella sala macchine. Essi analizzano le frequenze ultrasoniche e le vibrazioni del pavimento., grazie per lo script!
Ricordate che il server è già stato compromesso e gli aggressori potrebbero aver inserito altre insidie atipiche (non elencate nel dropper).
Quindi è meglio trasferirsi su un server pulito (vds), o almeno continuare a tenere d'occhio la questione: se ci sono novità, scrivete nei commenti qui, poiché chiaramente non tutti si trasferiranno su una nuova installazione…
UPD 10: Grazie ancora : ricorda che non solo i server si infettano, ma ad esempio anche Raspberry Pi, e anche diverse macchine virtuali… Quindi dopo aver salvato i server, non dimenticate di salvare le vostre console di gioco, robot, ecc.
UPD 11: Da importante avviso per i 'curatori manuali':
(dopo l'applicazione di uno qualsiasi dei metodi per combattere questo malware)
è necessario riavviarsi - il malware si trova da qualche parte nei processi aperti e, di conseguenza, in memoria, e si reinstalla da solo nel cron ogni 30 secondi
UPD 12: nella sua coda exim un altro (?) malware e consiglia di studiare prima il proprio problema specifico, prima di iniziare il trattamento.
UPD 13: di trasferirsi presto a un sistema pulito e di portare i file con estrema cautela, poiché il malware è già accessibile pubblicamente e altri possono utilizzarlo in modi meno ovvi e più pericolosi.
UPD 14: rassicurando se stessi dicendo che le persone intelligenti non avviano da root - un ulteriore :
Anche se non si opera da root, l'intrusione può comunque avvenire... Ho un OrangePi con debian jessie UPD: stretch, exim avviato da Debian-exim e si è comunque verificata un'intrusione, ha annullato il cron e altro.
UPD 15: quando ci si sposta su un server pulito da uno compromesso non dimenticate l'igiene, :
Quando trasferite i 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 dimenticate i file .html, .js, .php, .py e altri file pubblici (idealmente questi file, come altri dati, dovrebbero essere ripristinati da un'archiviazione locale o da un'altra fonte di fiducia).
UPD 16: e : nel sistema c'era una versione di exim nelle porte, ma in realtà ne veniva eseguita un'altra.
Quindi a tutti dopo l'aggiornamento vale la pena assicurarsi di usare proprio la nuova versione!
exim --versionCi siamo occupati insieme della loro situazione specifica.
Sul server veniva utilizzato DirectAdmin e era presente il suo vecchio pacchetto da_exim (vecchia versione, priva di vulnerabilità).
Con il gestore dei pacchetti custombuild di DirectAdmin è stata installata una versione di exim più recente, già vulnerabile.
In questa situazione specifica, anche l'aggiornamento tramite custombuild ha aiutato.
Non dimenticate di fare backup prima di effettuare esperimenti del genere e assicuratevi che, prima e dopo l'aggiornamento, tutti i processi di exim della vecchia versione e non siano 'bloccati' nella memoria.
Fonte: habr.com
