Colleghi, chi utilizza Exim nelle versioni 4.87…4.91 sui propri server di posta è invitato a aggiornarsi urgentemente alla versione 4.92, fermando prima il servizio Exim per evitare attacchi attraverso CVE-2019-10149.
Sono potenzialmente vulnerabili diversi milioni di server in tutto il mondo, con una vulnerabilità classificata come critica (punteggio base CVSS 3.0 = 9.8/10). I malintenzionati possono eseguire comandi arbitrari sul vostro server, in molti casi con privilegi di root.
Assicuratevi di utilizzare la versione corretta (4.92) o già patchata.
Oppure patchate quella esistente, vedi il thread .
Aggiornamento per centos 6: vedi — per centos 7 funziona anche se non è ancora arrivato direttamente da epel.
UPD: Ubuntu è colpita 18.04 e 18.10, l'aggiornamento per queste versioni è stato rilasciato. Le versioni 16.04 e 19.04 non sono colpite, a meno che non siano state installate varianti personalizzate. Maggiori informazioni .
Attualmente, il problema descritto lì viene sfruttato attivamente (presumibilmente da un bot), ho notato alcune infezioni sui miei server (che eseguivano la versione 4.91).
Continua a leggere solo per coloro che sono già "finiti" — o bisogna trasferire tutto su una VPS pulita con software aggiornato, o cercare una soluzione. Proviamo? Scrivete se qualcuno può combattere questo malware.
Se sei un utente di Exim e leggi questo e non hai ancora aggiornato (non ti sei assicurato di avere la versione 4.92 o una versione patchata), fermati e corri ad aggiornare.
Per chi è già stato colpito — continuiamo…
UPD: e dà un consiglio giusto:
I malware possono essere numerosi. Lanciando un rimedio sbagliato e ripulendo la coda, l'utente non si curerà e potrebbe non sapere da cosa deve essere curato.
L'infezione è evidente in questo modo: [kthrotlds] carica il processore; su una debole VDS al 100%, sui server più deboli ma visibile.
Dopo l'infezione, il malware elimina le registrazioni nel cron, scrivendo solo se stesso per l'esecuzione ogni 4 minuti, rendendo il file crontab immutabile. Crontab -e non può salvare le modifiche, restituisce un errore.
L'immutabilità può essere rimossa in questo modo, dopo di che si può eliminare la riga del comando (1.5kb):
chattr -i /var/spool/cron/root
crontab -e Poi nell'editor del crontab (vim) eliminiamo la riga e salviamo:dd
:wq
Tuttavia, qualche processo attivo sta riscrivendo di nuovo, sto indagando.
Nel frattempo ci sono molti wget (o curl) attivi che puntano agli indirizzi nello script di installazione (vedi sotto), al momento li interrompo così, ma si riavviano di nuovo:
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 evitare problemi, ma se qualcuno è infetto e sa come lavorare con gli script shell, si prega di esaminare più attentamente.
Aggiornerò man mano che ricevo nuove informazioni.
UPD 1: Cancellazione dei file (dopo chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root non ha aiutato, così come l'arresto del servizio — ho dovuto rimuovere completamente il crontab (rinominare il file bin).
UPD 2: L'installatore del trojan a volte si trovava anche in altre posizioni, è stata utile la ricerca per dimensione:
find / -size 19825c
UPD 3: Attenzione! Oltre a disabilitare selinux, il trojan aggiunge il suo SSH key in ${sshdir}/authorized_keys! E attiva i seguenti campi in /etc/ssh/sshd_config, se non erano già stati impostati su YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Riepilogo attuale: disattiviamo exim, cron (alle radici), rimuoviamo urgentemente la chiave trojan da ssh e modifichiamo la configurazione di sshd, riavviamo sshd! E questo non è nemmeno sicuro che aiuti, ma senza di ciò la situazione è critica.
Ho estratto le informazioni importanti dai commenti sui patch/aggiornamenti all'inizio della nota, in modo che chi legge possa iniziare da lì.
UPD 5: che il malware ha cambiato le password in WordPress.
UPD 6: , stiamo testando! Dopo il riavvio o la disattivazione della soluzione sembra perdere efficacia, ma intanto va bene così.
Chi realizza (o trova) una soluzione stabile, per favore contatti, sarà di grande aiuto per molti.
UPD 7: scrive:
Se non lo hanno già detto, il virus si ripristina grazie a un'email non inviata in exim, alla seconda tentativo di invio dell'email si ripristina, controllate in /var/spool/exim4
Per svuotare completamente la coda di exim, si può fare così:
exipick -i | xargs exim -Mrm
Controllo del numero di record in coda:
exim -bpc
UPD 8: Di nuovo : FirstVDS ha proposto la propria versione dello script per la soluzione, iniziamo a testarlo!
UPD 9: Sembra che lavorando, grazie per lo script!
Ricorda che il server potrebbe già essere stato compromesso e che gli attaccanti potrebbero aver inserito altre anomalie non documentate.
Pertanto, è consigliabile migrare su un server pulito (vds), o almeno mantenere sotto controllo la situazione — se ci saranno aggiornamenti, scrivi qui nei commenti, poiché è evidente che non tutti passeranno a una nuova installazione...
UPD 10: Grazie ancora : ricorda che non solo i server vengono infettati, ma anche Raspberry Pi, e vari sistemi virtuali... Quindi, dopo aver salvato i server, non dimenticare di proteggere le tue console di gioco, i robot e così via.
UPD 11: Da una nota importante per coloro che 'curano manualmente':
(dopo aver applicato uno dei metodi per combattere questo malware)
è necessario riavviare assolutamente — il malware rimane da qualche parte nei processi aperti e, di conseguenza, nella memoria, registrando nuovamente se stesso nel cron ogni 30 secondi
UPD 12: nella sua coda exim un altro(?) malware e consiglia prima di studiare specificamente il proprio problema, prima di iniziare la cura.
UPD 13: è tempo di passare a un sistema pulito, trasferendo i file con estrema cautela, poiché il malware è già disponibile pubblicamente e può essere utilizzato da altri in modi meno ovvi e più pericolosi.
UPD 14: tranquillizzandosi sul fatto che le persone intelligenti non avviano da root — un'altra cosa. :
Anche se non funziona da root, si verifica comunque un'intrusione... Ho un OrangePi con Debian Jessie UPD: Stretch, Exim è avviato da Debian-exim e c'è comunque stata un'intrusione, è stata cancellata la cron e altro.
UPD 15: quando si migra su un server pulito da uno compromesso, non dimenticate l'igiene. :
Quando trasferite i dati, fate attenzione non solo ai file eseguibili o di configurazione, ma anche a tutto ciò che potrebbe contenere comandi dannosi (ad esempio, in MySQL questo potrebbe essere CREATE TRIGGER o CREATE EVENT). Inoltre, non dimenticate i file .html, .js, .php, .py e altri file pubblici (idealmente, questi file, così come altri dati, dovrebbero essere ripristinati da un archivio locale o da un'altra fonte fidata).
UPD 16: e : nel sistema era installata una versione di exim, mentre in realtà ne veniva eseguita un'altra.
Quindi a tutti Dopo l'aggiornamento, assicurati di utilizzare proprio la nuova versione!
exim --versionIn merito alla loro situazione, abbiamo collaborato per risolverla.
Sul server è stata utilizzata DirectAdmin e c'era il suo vecchio pacchetto da_exim (a versione obsoleta, senza vulnerabilità).
Tuttavia, successivamente, tramite il gestore dei pacchetti di DirectAdmin custombuild, è stata installata una versione più recente di exim, già vulnerabile.
In questa specifica situazione, ha anche aiutato l'aggiornamento tramite custombuild.
Non dimenticare di fare backup prima di tali esperimenti e assicurati che prima/dopo l'aggiornamento tutti i processi exim della vecchia versione e non siano 'bloccati' in memoria.
Fonte: habr.com
