Magazine Salute e Benessere

MITM ‘in deep’ – PARTE 1, ARP e IPv4

Creato il 19 febbraio 2014 da Matteo Tosato @MatteoTosato87

Address Resolution Protocol – panoramica

La versione 4 del protocollo IP (Internet Protocol), si appoggia al protocollo ARP (Address Resolution Protocol) per la traduzione degli indirizzi logici (IP) in fisici (MAC) o viceversa nelle reti di tipo Ethernet (le più diffuse).
L’RFC numero 826 e successive, presentano le specifiche di funzionamento di ARP.
Tale sistema di traduzione, fondamentale per la maggior parte delle reti LAN moderne, possiede una vulnerabilità intrinseca responsabile, negli anni, di innumerevoli violazioni della privacy degli utenti.

Di seguito si cercherà di presentare, teoria, pratica ed esempi del famoso attacco ‘MITM’ (Man-In-The-Middle) attuabile in qualsiasi rete LAN IPv4 che utilizzi ARP per la risoluzione degli indirizzi di rete. Tale tecnica è spesso utilizzata anche in modo legittimo da apparati di rete o programmi che intervenendo sulle tabelle di risoluzione, modificando con criterio il tipo di instradamento del traffico di rete.

Riferendoci al modello OSI (Open System Interconnection), IP e ARP lavorano a livello di collegamento, il secondo partendo dal basso. Dal punto di vista dell’host tale sistema si compone di una tabella-cache residente in memoria. Tale tabella mentiene un elenco di corrispondenze fra indirizzi logici e rispettivi indirizzi fisici degli host della LAN.
Chiariamo subito che tale traduzione è necessaria data la possibilità degli host di cambiare indirizzo logico in maniera dinamica oppure di averne anche più di uno. In soldoni, ARP permette l’aggiornamento dinamico delle corrispondenze IP<->MAC di tutti gli host di una rete LAN.

Ogni volta che un host deve inviare un pacchetto, il seguente algoritmo (implementato all’interno dello stack di rete TCP/IP) si occupa di controllare se le informazioni per l’invio su rete ethernet sono sufficienti:

Pseudo algoritmo ARP

Pseudo algoritmo ARP

Il formato del protocollo utilizzato sia per le richieste che per le risposte ARP, è il seguente:

arp

Address Resolution Protocol header format

Il primo campo di 16 bit, Hardware type, è il tipo dell’hardware utilizzato, nel caso delle reti ethernet esso è impostato a ’1′ (Elenco completo dei tipi).
Protocol type, sempre di 16 bit corrisponde al tipo di protocollo di rete utilizzato. Esso si riferisce perciò al tipo di incapsulamento successivo (Nelle reti IP è impostato a 0×800, l’unico disponibile attualmente).
Hardware address length e Protocol address length sono campi a 8 bit e contengono rispettivamente la lunghezza in byte degli indirizzi hardware e protocol.
Opcode, lungo 16 bit, contiene il codice di funzionamento ARP, ovvero se il pacchetto rappresenta una richiesta, una risposta o altro (Elenco Opcode di ARP).
Source hardware address, source protocol address, sono i campi per MAC e indirizzo IP. Questi campi indirizzo sono lunghi 32 bit l’uno.
Lo stesso vale anche per i successivi, con la differenza che specificano gli indirizzi di destinazione.

Osservando il traffico ARP di qualsiasi host, è facile arrivare a capire come tale protocollo viene utilizzato,
analizzando una pacchetto ‘request’:

Ethernet II, Src: Micro-St_cc:63:87 (8c:89:a5:cc:63:87), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Micro-St_cc:63:87 (8c:89:a5:cc:63:87)
    Type: ARP (0x0806)
Address Resolution Protocol (request)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    Sender MAC address: Micro-St_cc:63:87 (8c:89:a5:cc:63:87)
    Sender IP address: 192.168.0.14 (192.168.0.14)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 192.168.0.247 (192.168.0.247)

Nel pacchetto di richiesta il campo, ‘Target MAC address’ è posto a zero ad indicare l’informazione che si sta richiedendo. Di conseguenza nel frame ethernet l’indirizzo fisico di destinazione è settato come ‘broadcast‘.
Quando il pc che possiede IP 192.168.0.247 riceve tale richiesta risponderà, e sarà l’unico che lo farà, riempiendo con il proprio indirizzo fisico il campo sorgente e copiando i campi sorgente nei target. In questo modo l’informazione giunge all’host mittente, ora in grado di inviare pacchetti all’host ‘Target’.

Ethernet II, Src: ZyxelCom_28:06:c8 (50:67:f0:28:06:c8), Dst: Micro-St_cc:63:87 (8c:89:a5:cc:63:87)
    Destination: Micro-St_cc:63:87 (8c:89:a5:cc:63:87)
    Source: ZyxelCom_28:06:c8 (50:67:f0:28:06:c8)
    Type: ARP (0x0806)
Address Resolution Protocol (reply)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    Sender MAC address: ZyxelCom_28:06:c8 (50:67:f0:28:06:c8)
    Sender IP address: 192.168.0.247 (192.168.0.247)
    Target MAC address: Micro-St_cc:63:87 (8c:89:a5:cc:63:87)
    Target IP address: 192.168.0.14 (192.168.0.14)

Questo esempio è il modo principale di funzionamento.

Per riassumere la breve introduzione sul sistema, il seguente schema mostra le tabelle di risoluzione di alcuni host in una LAN:

Esempio tabelle in una LAN

Esempio tabelle in una LAN

Come vedete le cache sono impostate correttamente rispetto la situazione della rete. Dal prompt dei comandi o shell potete visualizzare la situazione della vostra cache, ad esempio sul mio locale ecco come appare in questo istante:

C:\Documents and Settings\matteo>arp -a

Interfaccia: 192.168.4.23 --- 0x2
  Indirizzo Internet    Indirizzo fisico      Tipo
  192.168.4.201         00-07-9b-c1-0e-9e     dinamico
  192.168.4.205         00-20-48-27-31-83     dinamico
  192.168.4.206         00-56-c4-65-95-06     dinamico
  192.168.4.251         00-00-94-06-ef-65     dinamico


ARP poisoning

Tale sistema presenta un grave problema di sicurezza, sfruttando la debolezza di ARP, è possibile manipolare arbitrariamente le cache di qualsiasi host a livello della rete locale.
Da questo, deriva la possibilità di veicolare il traffico a piacimento senza alterare ne il funzionamento ne il rendimento delle comuniazioni. In altre parole, in mancanza di un sistema di protezione per questo particolare attacco, è possibile acquisire informazioni circa il traffico di rete generato da un qualsiasi host da parte dell’attaccante.

Se le tabelle sopra descritte vengono alterate in modo oppurtuno, è possibile fare in modo che una ipotetica ‘vittima’ spedisca dati verso un host diverso rispetto il reale destinatario prescelto.

Schema attacco man in the middle classico

Schema attacco man in the middle classico

Tale scenario, relativamente agli host della LAN presentata come esempio, sottointende una modifica delle tabelle ARP nel modo seguente (supponendo che B sia l’attaccante):

Alterazione tabelle

Alterazione tabelle

Questa alterazione è possibile dato che non esiste una sistema di autenticazione a questo livello.
Ovvero, i mittenti delle risposte ARP non possono essere verificati, pertanto, è possibile applicare questa tecnica semplicemente inviando delle ARP reply falsificate verso l’host vittima ed il secondo endpoint di comunicazione, solitamente un router.
Inoltre non è necessario attendere una richiesta ARP, dato che le reply, vengono sempre accettate!
E’ possibile creare allora un flusso ARP reply che periodicamente aggiorni la cache ARP della vittima con informazioni falsificate.

L’implementazione di un siffatto programma richiede di scendere a livello di collegamento, in altre parole, richiede l’utilizzo delle librerie socket per implementare manualmente il protocollo ARP a livello di programmazione, cosa che di prassi viene fatta in modo automatico e trasparente dal sistema operativo.

Una volta creato il flusso di reply, sull’host attaccante arriveranno tutti i pacchetti destinati in realtà ai due endpoint attaccati. E’ necessario abilitare la funzionalità di routing per poter instradare correttamente i pacchetti e evitare che i due host vadano in fault di rete.

*L’autore non si ritiene responsabile dell’uso improprio del codice e informazioni riportate. Il testo vuole essere esclusivamente a scopo informativo.

*The author is not responsible for improper use of the code and the information showed. The text is intended for informational purposes only.

Bibliografia:
.1 RFC sourcebook, http://www.networksorcery.com/enp/default1101.htm
.2 PHRACK, http://www.phrack.org/


Archiviato in:C, Hacking, Informatica, Linux, Networking, Programmazione Tagged: ARP, hacking, Man in the middle

Potrebbero interessarti anche :

Ritornare alla prima pagina di Logo Paperblog

Possono interessarti anche questi articoli :