Come trovare e rimuovere un rootkit in /etc/ld.so.preload

Capire come si nasconde un rootkit di preload

• Processi: ps e top leggono la directory /proc; una readdir() intercettata salta gli ID dei processi dell'attaccante.
• File: lo stesso aggancio nasconde i file per nome, spesso compresi /etc/ld.so.preload stesso e la libreria, così ls e cat dicono che non esistono.
• Connessioni: netstat e ss perdono le righe dei socket dell'attaccante.
• Tutto il resto funziona normalmente, ed è proprio questo lo scopo: il server sembra pulito a ogni strumento di cui di solito ti fideresti.

Ciò a cui non può nascondersi: i programmi che non usano la libreria C del sistema (binari linkati staticamente come busybox-static), il kernel, e un sistema avviato da un altro supporto. Un rootkit caricato come modulo del kernel è un altro caso, più difficile: si nasconde anche a /proc, e i controlli qui sotto possono non vederlo.

Controllare con strumenti che il rootkit non può ingannare

Procurarsi un busybox linkato staticamente

busybox-static è un unico binario con ls, cat, grep, sh e altro, linkato senza la libreria C, quindi una libreria precaricata non si carica mai al suo interno. ldd deve rispondere not a dynamic executable.

sudo apt install busybox-static
ldd /bin/busybox

La famiglia RHEL non ha un busybox statico nei repository di base. Copialo da una macchina Debian o Ubuntu pulita (dopo averci installato busybox-static), e richiamalo come /root/busybox invece di busybox nei comandi qui sotto:

scp /bin/busybox root@SERVER_IP:/root/busybox
ssh root@SERVER_IP 'chmod 700 /root/busybox && ldd /root/busybox'

Leggere il file direttamente

Confronta quello che vede busybox con quello che vedono gli strumenti del sistema. Se busybox mostra il file e i normali ls e cat dicono che non esiste, un rootkit è attivo in questo momento.

sudo busybox ls -la /etc/ld.so.preload
sudo busybox cat /etc/ld.so.preload
ls -la /etc/ld.so.preload
cat /etc/ld.so.preload

Per ogni libreria nominata nel file, verifica se appartiene a un pacchetto. Esistono rari usi legittimi, come il logger di comandi Snoopy e alcuni agent di monitoraggio, e arrivano da un pacchetto che hai installato tu:

dpkg -S /usr/lib/libhide.so

rpm -qf /usr/lib/libhide.so

Una libreria che non appartiene a nessun pacchetto è sospetta. Annota dimensione e hash, guarda i nomi che contiene (funzioni intercettate come readdir, la parola /proc) e quali processi l'hanno caricata:

sudo busybox ls -la /usr/lib/libhide.so
sudo busybox sha256sum /usr/lib/libhide.so
sudo busybox strings /usr/lib/libhide.so | busybox grep -iE 'readdir|/proc|preload|hide' | busybox head

sudo busybox sh -c "busybox grep -l '/usr/lib/libhide.so' /proc/[0-9]*/maps"

Confrontare /proc con ps

busybox legge /proc senza l'aggancio; ps lo usa. Ogni ID di processo che busybox trova e ps no è nascosto, e la riga ne mostra il binario. I processi terminati durante il ciclo possono comparire una volta: eseguilo due volte e guarda gli ID che compaiono entrambe le volte.

sudo busybox sh -c 'for d in /proc/[0-9]*; do p=${d#/proc/}; /bin/ps -p "$p" > /dev/null 2>&1 || echo "$p $(busybox readlink "$d/exe")"; done'

Lo stesso per le connessioni di rete: il netstat di busybox legge /proc/net direttamente. Una connessione presente nel primo elenco e assente nel secondo è nascosta.

sudo busybox netstat -tan
sudo ss -tanp

LD_PRELOAD negli ambienti e nei servizi

Lo stesso trucco funziona per singolo processo, con la variabile LD_PRELOAD in un file di unità, un profilo della shell o /etc/environment. Cercala nei processi in esecuzione e nei file abituali:

sudo busybox sh -c "busybox grep -l LD_PRELOAD /proc/[0-9]*/environ"
sudo busybox grep -rs LD_PRELOAD /etc/environment /etc/profile /etc/profile.d /etc/bash.bashrc /etc/bashrc \
  /etc/systemd /lib/systemd/system /usr/lib/systemd/system /root/.bashrc /root/.profile

Binari di sistema modificati

Alcuni kit sostituiscono anche ps, ls o sshd. Il database dei pacchetti elenca i file pacchettizzati il cui contenuto è cambiato (file di configurazione esclusi):

sudo dpkg --verify | grep -v ' c /'

sudo rpm -Va 2>/dev/null | grep -E '^..5' | grep -v ' c /'

Il modo sicuro: da un sistema di rescue

Anche dpkg e rpm sono linkati dinamicamente. Per un risultato su cui contare, avvia il sistema di rescue del provider, monta il disco del server e leggi lì il file, dove non gira niente del server. Trova prima la partizione root con lsblk: /dev/sda1 è un esempio.

lsblk -f
mount /dev/sda1 /mnt
ls -la /mnt/etc/ld.so.preload && cat /mnt/etc/ld.so.preload

Rimuovere il rootkit di preload

Se il provider può fare uno snapshot del disco, fallo prima. Poi tieni una copia del file e della libreria come prova:

sudo busybox mkdir -p /root/evidence
sudo busybox cp -a /etc/ld.so.preload /usr/lib/libhide.so /root/evidence/
sudo busybox sha256sum /root/evidence/*

I rootkit rendono spesso immutabili i loro file, così anche root riceve Operation not permitted. Il busybox-static di Debian non ha chattr; qui funzionano lsattr e chattr del sistema, perché i kit di preload nascondono i file per nome e di solito non toccano gli attributi:

sudo lsattr /etc/ld.so.preload /usr/lib/libhide.so
sudo chattr -i -a /etc/ld.so.preload /usr/lib/libhide.so

Rimuovi il file di preload con busybox. Dal prossimo programma avviato in poi non viene più precaricato niente, e il normale ls conferma che il file non c'è più:

sudo busybox rm /etc/ld.so.preload
ls -la /etc/ld.so.preload

I processi già in esecuzione hanno ancora la libreria caricata, ma i nuovi ps e ss che avvii no, quindi ciò che era nascosto adesso si vede. Cercalo, e congela ciò che non c'entra prima di ucciderlo:

ps -ef --forest | less
sudo ss -tanp
sudo kill -STOP PID

Rimuovi ciò che lo riporta: cron, unità systemd, chiavi SSH e account, come in Come trovare e rimuovere un crypto miner dal server, che passa in rassegna ogni posto. Poi cancella la libreria e riavvia, così nessun processo in esecuzione la tiene:

sudo busybox rm /usr/lib/libhide.so
sudo ldconfig
sudo reboot

Decidere quando reinstallare il server

Scrivere /etc/ld.so.preload richiede root. Quando un attaccante ha avuto root, la pulizia rimuove ciò che hai trovato, non per forza tutto ciò che c'era. Reinstalla da un'immagine pulita quando vale una di queste condizioni:

• Sono cambiati dei binari di sistema (il controllo dei pacchetti qui sopra).
• Il kernel è marcato tainted da un modulo sconosciuto, o lsmod elenca un modulo che non sai spiegare.
• Non hai trovato come è entrato l'attaccante.
• Il server contiene dati dei clienti, dati di pagamento o credenziali per altri sistemi.

cat /proc/sys/kernel/tainted
lsmod | sort | head -50
sudo dmesg | grep -iE 'taint|module verification|unsigned'

0 in tainted è un kernel pulito; altri valori hanno le loro ragioni, come i driver proprietari, quindi verificale prima di trarre conclusioni. Per reinstallare: prepara un nuovo server dall'immagine del provider, aggiornalo, ripristina i dati (non programmi o configurazioni che non puoi verificare) da un backup fatto prima dell'infezione, cambia ogni segreto, poi sposta il traffico. La checklist per un nuovo VPS copre la prima ora.

Domande

/etc/ld.so.preload è sempre malevolo?

No, ma è raro. Un server normale non ce l'ha. Alcuni strumenti legittimi lo usano, come il logger di comandi Snoopy, e arrivano da un pacchetto che hai installato tu: dpkg -S o rpm -qf sulla libreria te lo dice.

Basta cancellare il file?

Ferma l'occultamento per ogni nuovo programma, ed è per questo che è il primo passo. Non rimuove ciò che l'attaccante ha fatto con root: persistenza, altre backdoor, segreti rubati. Per quello servono il resto della pulizia, o una reinstallazione.

rkhunter e chkrootkit lo trovano?

Controllano le librerie precaricate e i kit noti, e vale la pena eseguirli. Sono script che chiamano gli strumenti del sistema, quindi su un sistema infetto possono ricevere la stessa vista nascosta. Eseguili da un sistema di rescue per un risultato su cui contare.