La ricercatrice Joanna Rutkowska ne sa veramente una più del diavolo. Naturalmente il suo blog è fra i miei preferiti. Lo aggiorna raramente, ma ogni suo scritto vale ogni singolo bit impiegato. Questo articolo, scritto quasi due anni fa, prendeva spunto dalla presentazione di un suo progetto, realizzato e funzionante, di cui avevo parlato già in una differente occasione.
Joanna nel frattempo ha prodotto molte altre cose, tutte estremamente interessanti, nel campo della sicurezza e dei malware. Uno dei suoi punti di vista che condivido completamente è che l’uso della virtualizzazione come strumento di sicurezza è una falsa soluzione. Ma questa è un’altra storia. Buona lettura.
Un malware veramente cattivo #1: comunicare senza comunicare
Ogni malware ha necessità di comunicare, vuoi per avvertire casa di essere arrivato, vuoi per fare il suo sporco lavoro. Per questo motivo, in mancanza di alternative, si può sempre agire dall’esterno del computer sospetto di essere compromesso: lavorando di sniffer è di solito possibile vedere il traffico anomalo generato dal malware per comunicare con l’esterno.
Ma… immaginate un metodo di comunicazione che non sia rilevabile con un normale sniffer: niente trucchi elettronici o elettrici, la comunicazione c’è, ma non si vede.
Presentiamo i nostri attori:
- A: il computer compromesso con dentro un malware di quelli cattivi.
- B: il computer di chi ha spedito il malware ed ora sta aspettando i suoi messaggi.
- C: il computer del detective che deve scoprire cosa comunica il malware.
- X: un computer qualsiasi su Internet.
A comunica in protocollo TCP con X. B si trova in qualche punto fra A e X, e riesce a vedere il traffico di rete fra i due. C si trova anche lui fra A e X, ma anche fra A e B, quindi se A manda un qualsiasi pacchetto IP a B, C lo intercetta immediatamente e può rilevare il traffico anomalo.
Alla fine fra A e B non circola un solo pacchetto, solo fra A e X, ma B ha ricevuto tutti i dati inviati da A.
Come può essere accaduto?
Usando un Passive Covert Channel della nostra incredibile Joanna Rutkowska.
Nell’intestazione di ogni pacchetto TCP ci sono dati per il funzionamento del protocollo, sotto forma di bit. Ognuno di essi ha un significato ben preciso, e non può avere valori arbitrari. Inoltre non si possono usare trucchi come accodare dei byte in più ad ogni pacchetto, perché sarebbero immediatamente rilevati.
Un solo blocco di bit può avere in teoria un qualsiasi valore ed essere valido: il campo dell’ISN (Initial Sequence Number).
La comunicazione avviene in questo modo:
- A apre la comunicazione con X. Il malware annidato al suo interno intercetta i pacchetti TCP di tipo SYN in uscita e sostituisce l’ISN originale con quello generato da lui.
- X riceve i pacchetti e risponde normalmente.
- B, che legge in modo passivo il traffico fra A e X, estrae i dati inviati da A in tutti gli ISN dei pacchetti TCP SYN, li riassembla, e legge la comunicazione.
- C non vede nulla di strano, solo A che comunica con X, e basta.
I limiti sono che B non può inviare dati al malware e che il malware può inviare dati al ritmo di soli tre byte per ogni pacchetto TCP SYN inviato dal computer compromesso. L’integrità della comunicazione è assicurata dal meccanismo di funzionamento del protocollo TCP stesso: se dovesse andare perso un qualsiasi pacchetto, il computer compromesso lo ritrasmetterebbe automaticamente perché richiesto dal protocollo stesso. Dato che B si trova fra A e X, se X riceve un pacchetto, lo riceve anche B. Quindi anche l’integrità è assicurata.
Per evitare di essere scoperta troppo facilmente, la comunicazione usa anche una cifratura derivata dal DES, che garantisce anche una relativa casualità nei valori di ISN forgiati. In questo modo si evita di insospettire per l’inevitabile regolarità dovuta alla presenza di dati sensati in un posto dove non dovrebbero essercene.
In conclusione: abbiamo la possibilità di creare un canale sicuro e coperto con il computer compromesso, senza scambiare direttamente neanche un singolo pacchetto.
La stessa tecnica si può applicare sfruttando altri elementi di un qualsiasi altro protocollo, ad esempio, citando Joanna, i cookie http, oppure i pacchetti TCP di tipo SYN/ACK, utili se ad essere compromesso è un server.
Oggi
C’è poco altro da aggiungere. Joanna nella presentazione ha mostrato anche come accorgersi che quello che dovrebbe essere casuale non lo è, chiudendo il cerchio, come dovrebbe fare ogni hacker degno di questo appellativo.
Per il resto, gli attuali malware a grande diffusione sono tutt’altro che sofisticati, preferendo colpire la massa con poco sforzo piuttosto che spendere energie per colpire pochi ma buoni. Tanto, come ho più volte affermato, a chi crea virus interessa sfruttare le risorse del computer colpito, creando botnet, e niente altro. Malware più sofisticati sono l’eccezione, e si preferisce utilizzare la legge dell’ottanta/venti: il venti per cento dello sforzo necessario a creare un malware realmente pericoloso è sufficiente a creare un malware che colpisca l’ottanta per cento dei computer del pianeta. Perché pagare di più?


Pingback: Repliche estive: “Un malware veramente cattivo #2: trovami, se ci riesci…” (20 dicembre 2006) — Il non-blog di Mario Pascucci