Cos'è un canale occulto
Il concetto risale ai primi anni Settanta. Le ricerche sul confinement problem mostrarono che un processo può far trapelare informazioni anche quando gli è vietato comunicare. Butler Lampson formulò il problema nel 1973 e, nello stesso anno, C. Lamb descrisse come analizzare le risorse condivise di un sistema per individuare proprio questo tipo di fuga.
Criteri successivi per i sistemi affidabili, in particolare lo standard statunitense TCSEC, hanno reso l'analisi dei canali occulti un requisito formale per i prodotti ad alta garanzia.
Ciò che accomuna tutti i canali occulti è l'uso improprio di una risorsa per uno scopo che i suoi progettisti non avevano previsto. La risorsa è legittima (header dei pacchetti, orologi di sistema, code di stampa, risoluzione dei nomi) e continua a svolgere la sua funzione normale mentre trasporta un payload nascosto. Poiché il comportamento del vettore è quello atteso, il trasferimento non attira attenzione, a meno che qualcuno non lo cerchi in modo specifico.
Canali di storage e canali di temporizzazione
L'ingegneria della sicurezza divide tradizionalmente i canali occulti in due classi, in base alla risorsa condivisa che sfruttano.
In un canale occulto di storage un processo scrive in una posizione che un altro legge, come il campo identificativo di un pacchetto IP, la lunghezza di una query DNS, gli attributi di un file o lo spazio inutilizzato in un header di protocollo. Ogni stato scritto codifica uno o più bit.
In un canale occulto di temporizzazione un processo modula quando o per quanto tempo usa una risorsa condivisa, come gli intervalli tra i pacchetti, i pattern di carico del processore o l'ordine degli eventi. Il destinatario misura la temporizzazione e decodifica il messaggio. Non viene scritto nulla da nessuna parte.
In pratica il confine è sfumato: la lunghezza di un pacchetto può essere considerata storage, e i pattern di burst temporizzazione. La classificazione determina comunque come un canale viene individuato nella revisione di progetto e rilevato in esercizio. I canali di storage offrono una capacità maggiore; quelli di temporizzazione sono più lenti, ma ancora più difficili da distinguere dal comportamento normale.
Tunneling via DNS e ICMP
Gli esempi reali più rilevanti riutilizzano un'infrastruttura che i firewall quasi non bloccano mai, perché la risoluzione dei nomi e la diagnostica di base sono indispensabili:
| Tecnica | Vettore riutilizzato | Come nasconde i dati |
|---|---|---|
| Tunneling DNS | Query di risoluzione dei nomi | Byte codificati nei sottodomini di query verso un server dell'attaccante |
| Tunneling ICMP | Pacchetti di diagnostica echo | Dati arbitrari nel payload di ogni pacchetto echo |
| Manipolazione degli header | Campi degli header IP e TCP | Bit nascosti nei numeri di sequenza, nei flag o in byte inutilizzati |
| Modulazione della temporizzazione | Intervalli e burst di pacchetti | Ritardi o burst deliberati, rilevabili solo statisticamente |
Perché i canali occulti contano per il rischio insider
Per un insider malevolo, i canali occulti risolvono il problema centrale del furto di dati: i canali standard sono sorvegliati. E-mail, upload web, messaggistica e supporti rimovibili possono essere tutti ispezionati, quindi un insider che vuole far uscire un database clienti senza essere notato ha bisogno di un percorso che nessuna regola di ispezione osserva. Il tunneling via DNS o ICMP offre esattamente questo.
I canali occulti servono anche gli attaccanti esterni: il traffico di comando e controllo, gli aggiornamenti dei malware e l'esfiltrazione di dati a tappe si mascherano abitualmente da protocolli consentiti. Per i difensori la conseguenza è scomoda: un log pulito dei canali standard non dimostra che nessun dato sia uscito, ma solo che nessuno sia uscito attraverso i canali sotto osservazione.
Monitorare i canali standard mostra cosa ne è uscito, non se sia uscito altro.
Come appare in Anexet
Gli agent di Anexet intercettano il traffico a livello di protocollo, quindi le sessioni HTTP, FTP, SMTP, IMAP e POP3 sono visibili sull'endpoint. Nella console ogni protocollo ha il proprio interruttore e il proprio filtro di porte, e le statistiche mostrano le sessioni TCP e i pacchetti intercettati nel tempo. Abbinato al monitoraggio del traffico web e al sistema DLP di Anexet, collega il contesto di navigazione al contenuto di ogni trasferimento.
1 / 2
Rilevamento e mitigazione
Rilevare i canali occulti è più difficile che sorvegliare quelli standard, perché l'attività del vettore è legittima. L'eliminazione completa è raramente raggiungibile. L'obiettivo realistico è ridurre la capacità del canale occulto sotto quella che serve a un attaccante e aumentare le probabilità di notare un tentativo.
I programmi pratici combinano i livelli riportati nella tabella seguente:
| Livello | Cosa fa | Quando si applica |
|---|---|---|
| Analisi a livello di progettazione | Individua i potenziali canali occulti nelle risorse condivise prima del rilascio | Prima del rilascio |
| Restrizione del traffico in uscita | Consente solo i protocolli necessari e i server dei nomi approvati, e limita l'ICMP in uscita | Configurazione di rete |
| Baseline del traffico e rilevamento delle anomalie | Segnala etichette di query lunghe, entropia insolita e volumi anomali | In esercizio |
| Limitazione della velocità | Limita il volume del traffico, rendendo impraticabile un'esfiltrazione massiccia | In esercizio |
| Visibilità sugli endpoint | Processi, connessioni e attività degli utenti danno contesto alle anomalie sottili | In esercizio |
Da dove iniziare
Parti dai canali che l'azienda lascia aperti per impostazione predefinita, come DNS e ICMP in uscita, poi aggiungi contesto comportamentale perché un uso insolito di questi canali porti a un utente preciso. L'analisi dei canali occulti appartiene alla revisione di progetto, e il monitoraggio mantiene le probabilità dalla parte dei difensori in esercizio.
Per approfondire: Fuga tecnica di informazioni: cos'è e come proteggersi?.
I canali occulti non possono essere esclusi del tutto, ma possono essere resi lenti, costosi e visibili.
Anexet TeamCome Anexet affronta questo
Anexet non afferma di rilevare ogni canale occulto. L'analisi formale dei canali occulti è una disciplina di progettazione, e nessun prodotto di monitoraggio può escludere del tutto i canali di temporizzazione nascosti. Anexet offre visibilità sugli endpoint nei canali in cui di solito sono incorporati i trasferimenti nascosti, così che l'attività insolita diventi osservabile.
Gli agent sugli endpoint intercettano il traffico dei protocolli di rete (HTTP/HTTPS, FTP, SMTP, IMAP, POP3), registrano l'attività web e le destinazioni URL, e applicano l'analisi dei contenuti a tutto ciò che transita sui canali standard. I dati sensibili vengono catturati mentre si trovano ancora su un percorso visibile, prima di scomparire in un tunnel. L'architettura on-premise mantiene traffico, contenuti e log all'interno dell'infrastruttura dell'organizzazione.
Intercettazione del traffico di rete
Gli agent intercettano il traffico a livello di protocollo, inclusi HTTP/HTTPS, FTP, SMTP, IMAP e POP3. Un server opzionale del traffico di rete aggiunge l'intercettazione centralizzata del traffico speculare, con filtri IP e MAC.
Visibilità dell'attività web
URL di destinazione, upload e sessioni webmail vengono registrati sull'endpoint, cioè nel contesto in cui devono operare gli strumenti di tunneling DNS e basati sul web.
Analisi dei contenuti
Tesauri di sicurezza (170 dizionari predefiniti), banche di hash e impronte digitali identificano quando file sensibili vengono spostati o trasformati e segnalano la preparazione di un'esfiltrazione mentre è ancora su un canale standard.
Contesto comportamentale
Il monitoraggio dell'attività degli utenti e il risk scoring collegano le anomalie di rete all'utente che le ha generate. Un traffico esterno insolito in un orario insolito pesa di più quando può essere attribuito.
Monitoraggio del traffico web
Scopri di più