Seppur non sempre chiamati con questo nome, siamo sicuri che avrete già sentito parlare più volte di uno degli attacchi più popolari e, almeno concettualmente, banali che consiste nell’avere un intruso che si trovi nel mezzo tra due parti che credono di comunicare una con l’altra ma che, in realtà, hanno un ‘terzo incomodo’ ad ascoltare.

Man in the middle, abbreviato spesso come MITM e che significa, per l’appunto, ‘persona che si mette in mezzo’, è esattamente quanto appena detto ma presenta molte sfaccettature e si fa presto a notare che un concetto molto generale come questo può applicarsi a diversi livelli dell’infrastruttura.

La prima forma di MITM che sicuramente vi verrà in mente è quella dell’IP spoofing, in cui lo ‘scambio’ avviene a livello di indirizzi IP ma fanno parte di questo genere di attacco anche il DNS spoofing, l’HTTPS spoofing, l’SSL hijacking, il mail hijacking, il caller ID spoofing, il wifi eavesdropping e il cookie session stealing (o Browser in the middle).

Vi è quindi dietro un mondo immenso che non è possibile coprire in un solo articolo ma è facile intuire che nessuno dei nomi precedenti presagisca nulla di buono e che lo spoofing sia, in senso molto generale, un concetto applicabile un po’ ovunque. Come di consueto, questo genere di attacchi può rappresentare un problema enorme per la nostra azienda se non ne siamo più che preparati.

Nel merito, vorremmo focalizzare su una tecnica che ne accomuna parecchi ed è spesso usata come ‘apertura’ per mettere in atto l’attacco vero e proprio e stiamo parlando dell’ARP cache poisoning o ARP spoofing.

Come si può intuire, essa si basa su un abuso del protocollo ARP, acronimo di Address Resolution Protocol, che è quasi onnipresente nelle nostre reti e permette di associare ogni MAC address a un indirizzo IPv4. In buona sostanza, se vi metteste in ascolto sulla vostra rete con un software di analisi come Wireshark, vedreste, con una certa frequenza, dei pacchetti broadcast emessi dai vostri nodi con i quali viaggiano richieste che possono presentarsi, ad esempio, come un:

Chi detiene l’indirizzo ip 10.0.7.55? Manda la risposta a 10.0.7.1

Tale richiesta può essere fatta da qualunque nodo della rete e di norma, l’unico host a rispondere è quello interessato, ovvero quello oggetto della “domanda” e che, nel nostro esempio, detiene l’indirizzo ip 10.0.7.55, il quale invierà il suo indirizzo MAC all’host che ne ha fatto richiesta. Tale informazione verrà poi mantenuta dentro una cache, chiamata per l’appunto ARP cache o ARP table.

Dimostrare tecnicamente l’attacco non sarà oggetto di questo articolo in quanto Internet abbonda di materiale in merito ma il principio base risulterà, ci auguriamo, già chiaro consultando la tabella ARP da terminale, da qualsiasi macchina connessa alla nostra rete con il comando arp -a su Linux o, su Windows, ifconfig da Powershell:

[centos@test.lab.local ~]$ arp -a
? (192.168.57.2) at 66:b0:17:34:35:5d [ether] on enp0s8
? (192.168.57.1) at 3a:0d:21:20:07:61 [ether] on enp0s8
? (10.0.2.3) at 1a:22:01:12:35:03 [ether] on enp0s3
gateway (10.0.2.2) at 1a:22:01:12:35:02 [ether] on enp0s3

Possiamo osservare alla linea 2 come, nella nostra infrastruttura di esempio, l’ip 192.168.57.2 sia detenuto dall’host la cui scheda di rete enp0s8 ha l’indirizzo MAC 66:b0:17:34:35:5d.

Se andiamo a verificare su uno dei nodi di cui sopra, con un semplice ip a:

[centos@test.lab.local ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 66:b0:17:34:35:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.57.2/24 brd 10.0.2.255 scope global noprefixroute dynamic enp0s3
       valid_lft 54466sec preferred_lft 54466sec
    inet6 fe80::954c:1645:e8ae:ae19/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Noteremo che, nel nostro esempio alla linea 9, l’indirizzo MAC della nostra scheda di rete in oggetto è esattamente quello presente nella tabella ARP di cui sopra.

Se il vostro MAC address è diverso da quello associato al vostro IP in una qualsiasi delle ARP tables, potreste essere davanti a un grosso problema.

Come si può intuire dalla breve descrizione poco sopra fornita, questo protocollo, da solo, non offre alcun tipo di sicurezza e, a meno di accorgimenti, ‘si fida’ delle risposte ricevute, con tutte le conseguenze del caso.

Che succede se, ipoteticamente, un nodo decidesse di rispondere alla richiesta pur non avendone titolo? Non vi è legge matematica o un vincolo di protocollo che stabilisca che la risposta ARP debba venire da un solo host e nemmeno da quello giusto e, nel momento in cui non è l’host legittimo a rispondere, stiamo osservando proprio dell’ARP spoofing.

Ricordiamo, infatti, che le richieste ARP sono dei pacchetti broadcast e vengono, quindi, intercettati da tutti i nodi presenti nel broadcast domain. In un ottica di difesa dell’infrastruttura risulta, quindi, già evidente come una appropriata segmentazione della rete non è solo una questione di performance ma anche di sicurezza: non vorremmo mai che un singolo host compromesso possa potenzialmente intercettare, e eventualmente alterare, tutte le richieste ARP di tutte le macchine che abbiamo in rete.

Cosa avviene, quindi, una volta che l’host malevolo è riuscito a inserirsi nelle tabelle ARP di due host obiettivo (ad esempio, il gateway e una postazione di lavoro qualsiasi)? In sintesi, esso sarà adesso il vero destinatario delle comunicazioni tra A e B, i quali non si accorgeranno di nulla in quanto ogni pacchetto che arriva al man in the middle verrà poi girato anche all’host corretto, ma non prima di essere stato osservato e, eventualmente, modificato.

Se state pensando che, oggi giorno, gran parte delle comunicazioni Internet viaggia in https, siete sulla retta via: quel famoso lucchetto non esiste solo per farvi perdere tempo ma, oltre che per non far viaggiare i pacchetti in chiaro (i quali avrebbero potuto mostrare anche dati sensibili come username e password), anche per assicurarvi che i pacchetti non siano stati alterati da uno qualsiasi degli hop, o nodi, attraverso cui siete passati per raggiungere quel sito web o quella risorsa condivisa. Come si può intuire, ciò è vero anche per le comunicazioni all’interno della stessa rete e, pertanto, la crittografia dei protocolli non può e non deve limitarsi solamente a ciò che esce su Internet.

E le richieste DNS? Quelle, molto probabilmente, stanno viaggiando in chiaro, insieme a una quantità di pacchetti, anch’essi non criptati, non necessariamente prevedibile. Va da sè, quindi, che non è il caso di correre rischi. Come possiamo mitigare un attacco del genere?

VPN: come intuibile, se le comunicazioni avvengono in un’altra rete che è visibile solo dall’interno di un tunnel criptato, non sarà possibile, dall’esterno, interagire in modo utile con tali pacchetti.

Tool di detection e\o blocking: gli attacchi di questo tipo generano sulla rete dei pacchetti che risultano anomali e, almeno per un breve lasso di tempo, vi saranno informazioni conflittuali e duplicate su chi detiene quale IP. Un sistema di prevenzione e rilevamento delle intrusioni può rilevare questo genere di anomalie, bloccare il tentativo e, eventualmente, allertare della violazione.

Packet filtering: alcuni firewall permettono di bloccare pacchetti ARP incongruenti con, ad esempio, una funzione ARP anti-spoofing.

Tabelle ARP statiche: sebbene ciò possa risultare inflessibile e scomodo, avere delle tabelle ARP prefissate e che, quindi, vengono imposte da noi e non autogenerate, rende vani questo tipo di attacchi. Non vi saranno richieste ARP perchè ogni associazione IP <-> Mac è già nota e preimpostata.

Ciò è fattibile in ambienti statici che cambiano poco nel tempo ma non tutte le infrastrutture rispecchiano questa casistica e, innegabilmente, avere altre liste da mantenere oltre al normale carico di lavoro non è sempre il massimo.

E’ anche possibile, come suggerivamo poche righe fa, notare un attacco del genere in modo manuale semplicemente osservando le tabelle ARP che, di norma, non conterranno mai due indirizzi IP associati allo stesso MAC, ma occhio ai falsi positivi: è possibile avere righe ‘sospette’ nelle cache ARP anche se è implementato un proxy ARP, ma questa è un’evenienza di cui, supponiamo, sareste sicuramente al corrente se siete amministratori della rete.

E voi? Avete già dato un’occhiata alle vostre tabelle?