Worm: tecniche di prevenzione e difesa

Alcune settimane fa si è fatta larga menzione di Ramen, un worm per Linux che dava la possibilità, tra le altre cose, di generare gli effetti propri di rootkit ben più evoluti. Adesso, a poca distanza da quell’avvenimento, l’allarme *nix worm torna all’ordine del giorno con lion.
Allo stato attuale l’analisi più approfondita è stata fatta da alcuni ricercatori americani.

Dopo Ramen arriva lion
un nuovo worm per Linux

Lion, nella sua similitudine con Ramen, riveste una pericolosità molto maggiore. Infetta le installazioni Linux con il deamon BIND DNS. Allo stato attuale sono riconosciute vulnerabili le seguenti release di BIND: 8.2, 8.2-P1, 8.2.1 e 8.2.2-Px. La versione di BIND 8.2.3-REL e la BIND 9 non risultano essere vulnerabili.
Chi segue la nostra rubrica Bug Report su www.netstime.com ha avuto notizia della vulnerabilità di BIND relativa a TSIG. Lion si propaga a mezzo di un’applicazione denominata randb.Questa effettua una scansione di indirizzi IP di classe B sulla porta TCP 53 (rispondente al servizio DNS). Ecco di seguito quello che accade:

Ogni sistema sottoposto a probing, viene controllato ai fini della vulnerabilità indicata all’inizio del nostro articolo.

Se vengono trovate versioni di BIND vulnerabili, il worm “esegue” l’exploit. Dopo questa operazione installa il rootkit denominato t0rn;

Una volta penetrato nel sistema, il worm verifica il contenuto di

/etc/passwd,

/etc/shadow,

e di altre impostazioni di rete verso un indirizzo facente parte del dominio china.com.

Agisce su /etc/hosts.deny, diminuendo alcune delle protezioni ivi gestite dal noto tool di sicurezza tcp wrappers.

Piazza una backdoor in /etc/inetd.conf. Questa agisce sulle porte 60008/TCP e 33567/TCP;

Installa una versione troianizzata di ssh operativa sulla 33568/TCP.

Viene “killato” Syslogd, in maniera tale che il sistema non sia più in grado di gestire il logging in maniera affidabile.

Viene installata una versione troianizzata di login, che cerca una password hashed nella posizione /etc/ttyhash.

La location /usr/sbin/nscd (che contiene il deamon opzionale Name Service Caching) viene sovrascritta con una versione troianizzata di ssh.

Vi ricordo che, nel momento in cui lion ha trovato una victim machine vulnerabile al bug TSIG, è t0rn rootkit ad entrare in azione. Il rootkit effettua la sostituzione di numerosi binari sul sistema, al mero (e ovvio, direi) fine di occultarsi. Di seguito una lista di binari che vengono sostituiti (fonte sans):

du

find

ifconfig

in.telnetd

in.fingerd

login

ls

mjy

netstat

ps

pstree

top

Oltre a quanto sopra, il rootkit installa i binari: t0rn e tfn.
Particolare attenzione viene prestata alla fase di “pulitura dei file di log”, azione che ricopre una certa importanza in ogni attacco che si rispetti.
A tal fine viene installato Mjy, un binario per cancellare le log entries, piazzato nella location /bin e /usr/man/man1/man1/lib/.lib/.
Al momento in cui scriviamo sono allo studio da parte di ricercatori possibili soluzioni per eliminare l’infezione dal sistema operativo. A sottolineare il problema degli attacchi a Linux è stato segnalato Adore. Si tratta di un nuovo worm sviluppato per attaccare il sistema oerativo open source, per maggiori informazioni su Adore si veda Bug Report nelle pagine seguenti.

Fake triggering: un nuovo pericolo per gli IDS

Una delle tecniche più utilizzate dagli attacker per minare l’operatività degli Intrusion Detection System è quella detta in gergo di triggering: si tratta, tecnicamente parlando, di attivare le capacità di detection con un numero di eventi decisamente superiore all’effettiva capacità di reazione, in modo tale da diminuirne l’affidabilità complessiva.Sono purtroppo molti gli strumenti che stanno diventando disponibili al mondo degli attacker per effettuare attacchiagli IDS attraverso il malicious triggering.
Tutti hanno in comune la generazione di un elevato numero di pacchetti, proprio quelli che gli Intrusion Detection System “vogliono vedere”. Si tratta quindi di singoli pacchetti TCP, UDP o ICMP, che creano un matching di determinate regole contenute all’interno della rule base. In alcuni casi, se si effettua un’attenta analisi introspettiva della qualità dei pacchetti generati, ci si accorgerà che non sembrano attacchi reali, ma contengono stringhe per cui l’IDS di turno è stato effettivamente programmato.
Questa impostazione consente da un lato il risparmio in termini di stringhe “fake” create e dall’altro il massimo rapporto di efficacia tra il numero di pacchetti mandato e la messa in difficoltà dell’IDS target.
In alcuni forum, inoltre, è stato commentato che l’impostazione di tipo random timing e i dati presenti nei payload siano dei tentativi di rendere difficile la detection dei fake packet.

Rivedere il modo d’operare
a basso livello

Gli stessi analisti coinvolti nel processo di verifica di dette transazioni hanno considerato che, visto il modello di “istruzione” degli Intrusion Detection System, questi potrebbero incontrare delle difficoltà nel discernere tra un singolo pacchetto TCP specificamente “costruito” per il fake trigger e un altro che fa realmente parte di una transazione.
L’approccio consigliato è quello per esclusione, basato su uno screening dei pacchetti che, oggettivamente, non hanno alcuna chance di far parte di un attacco reale. Si tratterebbe, in pratica, di rivedere a basso livello il modo di operare di alcuni Intrusion Detection System, basandosi, per esempio, su un insieme di regole incrociate, il cui fine è un cross matching.
Il risultato potrebbe essere una sensibile diminuzione dei falsi allarmi e dei Denial of Service indiretti.
Altro problema correlato a questi tipi di attacco è che gli strumenti di flooding che lo generano hanno un funzionamento semplice, anche in ordine alla generazione di pacchetti, i quali possono avere indirizzi di partenza “spoofati” e sposteranno la loro principale operatività sulla gestione di transazioni stateless, quindi basicamente UDP,.protocollo che non prevede la sequenzializzazione, il controllo degli errori e meccanismi di controllo del flusso, anche se usa il protocollo IP per l’indirizzamento. Questo risolverebbe in anticipo qualsiasi implementazione di tipo cross matching basata su TCP.

Alcune
considerazioni “cross”

Di tipo personale e non. Partiamo dalle seconde. Alcuni hanno ipotizzato che questa nuova tendenza di attacco sarebbe stata innescata in qualche modo da alcuni produttori di Intrusion Detection Systems di tipo HIDS (Host Based), i quali starebbero puntando molto su questi problemi per accelerare il processo di transizione dai NIDS (Network Intrusion Detection Systems) al modello ibrido o, in casi estremi, verso quello host based, appunto. Il motivo sarebbe dovuto alla oggettiva difficoltà di rincorrere e di monitorare througput superiori ai 300 Mbps, a prescindere dai tentativi più o meno grossolani di effettuare trunking più o meno efficaci effettuati in questo periodo. Un’altra considerazione è di tipo personale. Con l’avvento di questa categoria di tool, se non si corre ai ripari si assume il rischio di perdere di efficacia nella real time detection e in altre operazioni correlate.
Una cosa è certa: la nascita di questi “nuovi” flood non creerà problemi alla comunità opensource, che è già al lavoro, da un lato per proteggere il modello NIDS, e dall’altro per nuove implementazioni di IDS basati sull’Hybrid model.