Attacco RADIUS: panoramica dettagliata

Il protocollo RADIUS (Remote Authentication Dial-In User Service) è fondamentale per l’infrastruttura di rete moderna ed un attacco inciderebbe molto su scala globale. Sebbene progettato nel 1991, rimane lo standard de facto per l’autenticazione leggera utilizzata per l’accesso remoto a dispositivi di rete. RADIUS è supportato da quasi tutti i prodotti di switch, router, access point e concentratori VPN venduti negli ultimi venti anni.

Meccanismo del Protocollo RADIUS

In RADIUS, un NAS (Network Access Server) funge da client che verifica le credenziali dell’utente finale tramite richieste RADIUS a un server centrale. Il client RADIUS e il server condividono un segreto fisso. Il server risponde con un messaggio di accettazione o rifiuto (Access-Accept o Access-Reject).

Le richieste e le risposte possono contenere campi etichettati chiamati “attributi” che specificano vari parametri, come nome utente e password nella richiesta o accesso alla rete nella risposta. I pacchetti di richiesta includono un valore chiamato Request Authenticator, essenzialmente un nonce casuale, mentre i pacchetti di risposta includono un valore chiamato Response Authenticator, che dovrebbe proteggere l’integrità delle risposte del server.

Vulnerabilità di RADIUS

Costruzione del Response Authenticator

Il Response Authenticator viene calcolato come segue: MD5(Code∣∣ID∣∣Length∣∣Request Authenticator∣∣Packet Attributes∣∣Shared Secret)\text{MD5}(\text{Code} || \text{ID} || \text{Length} || \text{Request Authenticator} || \text{Packet Attributes} || \text{Shared Secret})MD5(Code∣∣ID∣∣Length∣∣Request Authenticator∣∣Packet Attributes∣∣Shared Secret) Dove:

• ID e Request Authenticator sono valori casuali nella richiesta.
• Code, Length, e Packet Attributes sono valori nella risposta del server.
• Shared Secret è il segreto condiviso tra client e server, sconosciuto all’attaccante.

Attacco contro RADIUS

L’attacco permette a un uomo nel mezzo tra il client e il server RADIUS di falsificare una risposta Access-Accept valida a una richiesta di autenticazione fallita. L’attaccante inietta un attributo Proxy-State malevolo in una richiesta client valida. Questo attributo viene garantito di essere restituito dal server nella risposta. L’attaccante costruisce il Proxy-State in modo che i valori Response Authenticator tra la risposta valida e quella che l’attaccante vuole falsificare siano identici. Questo inganno fa sì che il NAS conceda all’attaccante l’accesso ai dispositivi e servizi di rete senza dover indovinare o forzare le password o i segreti condivisi.

Passaggi dell’Attacco

1. L’attaccante inserisce il nome utente di un utente privilegiato e una password arbitrariamente errata.
2. Questo causa al client RADIUS di un dispositivo di rete vittima di generare una richiesta Access-Request, che include un valore casuale di 16 byte chiamato Request Authenticator.
3. L’attaccante intercetta questa richiesta e utilizza l’Access-Request per prevedere il formato della risposta del server (che sarà un Access-Reject poiché la password inserita è errata). L’attaccante quindi calcola una collisione MD5 tra l’Access-Reject previsto e una risposta Access-Accept che desidera falsificare.
4. Dopo aver calcolato la collisione, l’attaccante aggiunge RejectGibberish al pacchetto Access-Request, mascherato come attributo Proxy-State.
5. Il server che riceve questa richiesta modificata verifica la password dell’utente, decide di rifiutare la richiesta e risponde con un pacchetto Access-Reject, includendo l’attributo Proxy-State.
6. L’attaccante intercetta questa risposta e verifica che il formato del pacchetto corrisponda al modello previsto. Se sì, l’attaccante sostituisce la risposta con Access-Accept e AcceptGibberish e la invia con l’Response Authenticator non modificato al client.
7. A causa della collisione MD5, l’Access-Accept inviato dall’attaccante viene verificato con l’Response Authenticator, inducendo il client RADIUS a credere che il server abbia approvato la richiesta di login e concedendo l’accesso all’attaccante.

Questa descrizione è semplificata. In particolare, è stato necessario un lavoro crittografico per dividere il gibberish della collisione MD5 tra più attributi Proxy-State formattati correttamente e ottimizzare e parallelizzare l’attacco di collisione MD5 per eseguire in minuti invece che ore.

Per una descrizione completa, si prega di leggere il paper.