Debolezze del protocollo ARP
Il protocollo ARP è nella sostanza un servizio di traduzione fondato sulla diffusione broadcast delle richieste e sulla memorizzazione delle informazioni contenute nelle risposte.
La sua fondamentale debolezza consiste nel fatto che non è prevista alcuna specifica procedura di autenticazione dei partecipanti e di verifica delle informazioni ricevute via rete.
Il processo ARP inoltre è basato su un modello di funzionamento stateless, che rende particolarmente difficile stabilire una relazione tra le richieste inviate e le risposte ricevute.
Qualunque entità, connessa direttamente alla rete locale può emettere richieste ARP (gratuite e non) e modificare, in maniera involontaria o espressamente fraudolenta, le informazioni memorizzate nella cache delle altre stazioni.
L’alterazione della cache ARP può compromettere i requisiti base di riservatezza, integrità e disponibilità dei dati trasmessi sulla rete locale.
Lo sfruttamento di questa tecnica, da parte di un hacker che controlla un sistema connesso alla rete locale, rende possibile la redirezione dei frame trasmessi.
Inviando una ARP request fasulla, un hacker può infatti modificare le informazioni registrate nella cache delle altre stazioni e sostituirsi a una stazione o a un gateway legittimi.
Avvelenando le tabelle ARP di server e gateway frequentemente utilizzati (tecnica denominata ARP Poisoning), con indirizzi MAC inconsistenti, un hacker può ottenere facilmente un effetto DoS.
Mentre sostituendo l’indirizzo MAC dei server e dei gateway con quello della scheda di rete della propria stazione si viene a creare una condizione di man-in-the-middle.
Un attaccante può ottenere il completo controllo dei flussi di pacchetti scambiati se riesce ad avvelenare le cache ARP di entrambi i partecipanti.
L’avvelenamento può essere ottenuto inviando al target un ARP reply che si finge risposta di una precedente richiesta prodotta dalla stessa stazione.
Il protocollo ARP, per la sua natura stateless, non stabilisce come la stazione deve trattare questa eccezione.
Generalmente la stazione che riceve il falso ARP reply lo accetta, finendo con il compromettere la propria cache.
Una volta alterata con successo la cache ARP, per mantenere l’illusione (e evitare così che, nel momento in cui il client ha finalmente bisogno del server, invii una ARP request broadcast), occorre che la stazione dell’attaccante invii un ARP reply ogni 30 secondi.
L’invio ripetuto di ARP reply fasulle evita lo scadere del timeout e la rimozione dell’informazione falsa dalla cache locale.
Gli attacchi derivanti da ARP Poisoning dipendono dall’intrinseca mancanza di sicurezza del protocollo ARP.
Prevenire completamente simili attacchi è pressochè impossibile, almeno se si desidera mantenere la semplicità d’uso dell’ARP a cui gli utenti sono oggi abituati.
Il raggio di azione dell’attaccante può essere però limitato utilizzando un approccio ibrido, che preveda la diffusione e memorizzazione di liste di associazioni indirizzi IP/MAC permanenti per i gateway e i server principali.
La riduzione dell’esposizione al rischio in tal caso si paga con un aumento in termini di gestione della sicurezza, dovendo affiancare un processo manuale di diffusione e controllo di liste, a un protocollo interamente automatico, come è il protocollo ARP utilizzato in maniera standard.
Occorre sottolineare che il problema riguarda tutte le stazioni connesse a uno stesso dominio di broadcast, indipendentemente dalla criticità dei dati memorizzati e dei servizi attivi sulla singola macchina.
Eventuali contromisure introdotte per risolvere il problema devono pertanto riguardare tutte le stazioni connesse alla rete locale.
L’utilizzo di switch per la propria rete non aiuta a mitigare il problema, in quanto la tecnica di ARP Poisoning non dipende dalla partecipazione attiva dei dispositivi di rete.
La riuscita dell’attacco non dipende neppure dalla scelta effettuta a proposito dei dispositivi di rete locale (hub o switch).
Nelle reti locali basate interamente su switch, si ha la propagazione controllata di tutti i pacchetti unicast (comprese le ARP reply utilizzate per l’ARP Poisoning).
Questa proprietà naturale degli switch permette agli hacker di non far giungere al soggetto legittimo, di cui si intende assumere l’identità, notifica alcuna del tentativo di attacco in corso.
Paradossalmente eventuali attività di monitoring effettuate sulle stazioni finali sono rese più semplici in presenza di hub.
Anche in tal caso però una scheda di rete che opera in condizioni standard non si rende conto del tentativo di attacco, in quanto scarta automaticamente tutte le ARP reply unicast non destinate al proprio indirizzo MAC.
L’attività di controllo sulle ARP reply trasmesse in rete locale, può essere effettuata dalle stazioni finali, ma è molto più efficace se svolta dagli stessi switch.
L’attività di monitor effettuata dagli switch deve essere in grado di rilevare i segnali di ogni attività sospetta condotta a livello ARP.
È da ritenersi sospetto il verificarsi dei seguenti eventi:
- trasmissione di un numero di messaggi ARP superiore alla media;
- ricezione di ARP reply non sollecitate (non precedute da una ARP request);
- ARP request gratuite con destinazione unicast;
- associazioni di indirizzo IP e MAC frequentemente variabili nel tempo;
- utilizzo da parte delle stazioni di indirizzi IP diversi da quelli assegnati loro dinamicamente nel costruire le ARP reply.
In presenza di simili segnali, i monitor dovrebbero essere configurati per avvisare l’amministratore della rete locale, consentendogli un’indagine tempestiva sulle ragioni che hanno fatto scattare l’allarme.
Un utente esperto può dare un contributo dotando la propria stazione di tool in grado di segnalare la ricezione di ARP reply non previste e le variazioni nel tempo delle associazioni memorizzate nella propria cache ARP.
