Scovate vulnerabilità in alcune implementazione di IPSec

Riporto integralmente un interessante articolo pubblicato su Zone-H.org.

05/10/2005

Stando ad un advisory del NISCC ( National Infrastructure Security Co-ordination Centre) alcune falle risiederebbero in alcune implementazioni di IP security, l'insieme di protocolli sviluppato dall' IETF ( Internet Engineering Task Force ) per garantire autenticità,segretezza ed integrità a livello IP di una comunicazione tra due peer di una rete.

Le vulnerabilità sono state riscontrate in alcune configurazioni di IPSec; in particolare le configurazioni che usano l' Encapsulating Security Payload (ESP) in tunnel mode senza funzionalità di controllo dell'integrità dei dati, ed anche in configurazioni con verifica dell'integrità presente a layer superiori. Anche alcune configurazioni che usano l'Authentication Header (AH) risultano vulnerabili.

In queste configurazioni un attaccante può essere in grado di modificare delle sezioni del pacchetto IPSec in modo che una volta ricevuto dal gateway questo lo instradi (dopo averlo decriptato) verso un host controllato dall'attaccante stesso, oppure 'forzando' il gateway a genere un messaggio di errore. Tali messaggi di errore sono inviati attraverso il protocollo ICMP, il quale per sua natura conterrà l'header IP e parte del payload (del pacchetto che ha generato l'errore ) in chiaro.

La causa principale del problema è dovuta al fatto che l' ESP usa l' algoritmo CBC ( Cipher Block Chaining ) per criptare i dati; tale algoritmo è infatti notoriamente vulnerabile ad attacchi di tipo 'bit flipping'.

Per sfruttare queste vulnerabilità è ovviamente necessario che l'attaccante si trovi in una situazione tipo "man in the middle", ovvero l'attaccante deve essere in grado di intercettare il traffico passante tra i due gateway.

Un tipico attacco potrebbe essere il seguente:

1)L'attaccante, attraverso un operazione di 'bit flipping' sul pacchetto criptato, modifica l'indirizzo di destinazione del pacchetto IP originale ;

2) Il gateway decripta il pacchetto in modo da ottenere il pacchetto originale ( che risulterà modificato a causa dell'operazione di bit flipping precedente );

3)Il gateway routa il pacchetto decriptato verso l'ip di destinazione contenuto nell'header IP.

4)Se l'attacco ha successo il testo in chiaro del datagramma arriverà all'host scelto dall'attaccante.

Un altro scenario potrebbe essere il seguente:

1)l'attaccante, attraverso un operazione di 'bit flipping' sul pacchetto criptato, modifica il campo 'Protocol' e il campo ' source address' dell' header IP.

2)Il gateway decripta il pacchetto in modo da ottenere il pacchetto originale ( che risulterà modificato a causa dell'operazione di bit flipping precedente ) e lo invia al destinatario presente nel campo 'destination address' dell'header IP;

3)Il destinatario analizzerà il pacchetto IP ricevuto e noterò che il campo 'Protocol' è errato; a questo punto invierà un messaggio ICMP di tipo 'protocol unreachable' all' indirizzo presente nel campo 'source address' (modificato dall'attaccante) dell' header IP. Il messaggio ICMP conterrà tra le altre cose anche parte del payload in chiaro.

4) l'attaccante intercetterà il messaggio ICMP ottenendo così parte del payload in chiaro.

Le possibili soluzioni al problema possono essere le seguenti:

1- Configurare ESP con le funzionalità di segretezza ed integrità .

2- Usare il protocollo AH affiancato ad ESP in modo da fornire protezione dell'integrità dei dati. Da notare che ciò deve essere fatto attentamente dato che la configurazione di AH in transport mode incapsulata all'interno di ESP è ancora vulnerabile.

3- Rimuovere la generazione dei messaggi ICMP o filtrare gli stessi tramite firewall .