Riduzione dello spoofing del protocollo Blast-RADIUS (CVE-2024-3596)

Introduzione

In questo documento viene descritto come mitigare lo spoofing del protocollo Blast RADIUS.

Panoramica

Il 7 luglio 2024, i ricercatori nel campo della sicurezza hanno rivelato questa vulnerabilità nel protocollo RADIUS: CVE-2024-3596: Il protocollo RADIUS della RFC 2865 è suscettibile di attacchi di falsificazione da parte di un utente non autorizzato che può modificare qualsiasi risposta valida (Access-Accept, Access-Reject o Access-Challenge) a qualsiasi altra risposta utilizzando un attacco di collisione prescelto contro la firma dell'autenticatore di risposta MD5. In questo white paper viene pubblicato un documento dettagliato che illustra come ottenere una risposta efficace contro la falsificazione di messaggi in flussi che non utilizzano l'attributo Message-Authenticator.

Per un elenco aggiornato dei prodotti Cisco interessati da questa vulnerabilità e delle versioni che contengono correzioni, visitare: Vulnerabilità spoofing protocollo RADIUS (Blast-RADIUS): Luglio 2024. Questo articolo descrive le tecniche generali di mitigazione e il modo in cui si applicano ad alcuni prodotti Cisco, ma non a tutti, in cui è necessario consultare la documentazione dei singoli prodotti per le specifiche. In qualità di server di punta Cisco RADIUS, Cisco Identity Service Engine è trattato in modo più dettagliato.

Introduzione

Questo attacco sfrutta un attacco MD5 basato sul prefisso scelto utilizzando collisioni in MD5, che consente a un utente non autorizzato di aggiungere ulteriori dati al pacchetto di risposta RADIUS modificando al contempo gli attributi esistenti del pacchetto di risposta. È stato dimostrato, ad esempio, che è possibile modificare un rifiuto di accesso RADIUS in un rifiuto di accesso RADIUS. Ciò è possibile perché per impostazione predefinita RADIUS non include un hash di tutti gli attributi nel pacchetto. La RFC 2869 non aggiunge l'attributo Message-Authenticator, ma al momento è necessario includerlo solo quando si utilizzano i protocolli EAP, il che significa che l'attacco descritto in CVE-2024-3596 è possibile contro qualsiasi scambio non EAP in cui il client RADIUS (NAD) non include l'attributo Message-Authenticator.

Attenuazione

Message-Authenticator

1.- Il client RADIUS deve includere l'attributo Message-Authenticator.

Quando il dispositivo di accesso alla rete (NAD) include l'attributo Message-Authenticator nel pacchetto Access-Request, Cisco Identity Services Engine include Message-Authenticator nel pacchetto Access-Accept, Access-Challenge o Access-Reject risultante in tutte le versioni.

2.- Il server RADIUS deve imporre la ricezione dell'attributo Message-Authenticator.

Non è sufficiente includere l'autenticatore del messaggio nella richiesta di accesso, in quanto l'attacco consente di rimuovere l'autenticatore del messaggio dalla richiesta di accesso prima che venga inoltrata al server RADIUS. Il server RADIUS deve inoltre richiedere a NAD di includere Message-Authenticator in Access-Request. Non è l'impostazione predefinita su Cisco Identity Services Engine, ma può essere abilitata al livello di protocolli consentiti, che si applica al livello di set di criteri. L'opzione nella configurazione Protocolli consentiti è Richiedi autenticatore messaggio per tutte le richieste RADIUS:

Opzione Protocolli consentiti in Identity Services Engine

Autenticazioni corrispondenti a un set di criteri in cui la configurazione dei protocolli consentiti richiede Message-Authenticator, ma in cui Access-Request non contiene l'attributo Message-Authenticator viene eliminato da ISE:

È importante verificare se NAD invia Message-Authenticator prima di essere richiesto dal server RADIUS. Poiché non si tratta di un attributo negoziato, spetta a NAD inviarlo per impostazione predefinita o configurarlo per l'invio. Message-Authenticator non è uno degli attributi riportati da ISE; un packet capture è il modo migliore per determinare se un NAD/Use Case include Message-Authenticator. ISE ha integrato la funzionalità di acquisizione pacchetti in Operazioni > Risoluzione dei problemi > Strumenti diagnostici > Strumenti generali > Dump TCP. Tenere presente che casi di utilizzo diversi dello stesso NAD possono includere o meno l'opzione Message-Authenticator.

Questo è un esempio di acquisizione di una richiesta di accesso che include l'attributo Message-Authenticator:

Attributo message-authenticator in Radius access-request

Questo è un esempio di acquisizione di una richiesta di accesso che non include l'attributo Message-Authenticator:

Crittografia con TLS/IPSec

La soluzione a lungo termine più efficace per proteggere RADIUS è crittografare il traffico tra il server RADIUS e il server NAD. In questo modo viene aggiunta sia la privacy che una maggiore integrità crittografica rispetto all'utilizzo dell'autenticatore di messaggi derivato da MD5-HMAC. Che, se è possibile utilizzare tra il server RADIUS e il server AND, dipende da entrambi i lati che supportano il metodo di crittografia.

I termini utilizzati nel settore per la crittografia TLS di RADIUS sono:

• RadSec: si riferisce alla RFC 6614
• RadSec TLS: si riferisce alla RFC 6614
• RadSec DTLS: si riferisce alla RFC 7360

È importante implementare la crittografia in modo controllato, in quanto la crittografia TLS comporta un sovraccarico delle prestazioni e comporta considerazioni sulla gestione dei certificati. Anche i certificati devono essere rinnovati regolarmente.

RADIUS over DTLS

DTLS (Datagram Transport Layer Security) come livello di trasporto per RADIUS è definito dalla RFC 7360 che utilizza i certificati per autenticare reciprocamente il server RADIUS e il server NAD, quindi cripta il pacchetto RADIUS completo utilizzando un tunnel TLS. Il metodo di trasporto rimane UDP e richiede la distribuzione di certificati sia nel server RADIUS che in NAD. Tenere presente che quando si distribuisce RADIUS su DTLS, è necessario che la scadenza e la sostituzione dei certificati vengano gestite attentamente per impedire ai certificati scaduti di interrompere la comunicazione RADIUS. ISE supporta DTLS per le comunicazioni da ISE a NAD, in quanto ISE 3.4 Radius over DTLS non è supportato per i server proxy RADIUS o i server token RADIUS. RADIUS over DTLS è supportato anche da molti dispositivi Cisco che fungono da servizi di rilevamento di virus (NAD), quali switch e controller wireless con Cisco IOS-XE®.

RADIUS over TLS

La crittografia TLS (Transport Layer Security) per RADIUS è definita dalla RFC 6614, imposta il trasporto su TCP e usa TLS per crittografare completamente i pacchetti RADIUS. Questo è comunemente usato dal servizio eduroam come esempio. A partire dalla versione ISE 3.4, RADIUS over TLS non è supportato, ma è supportato da molti dispositivi Cisco che agiscono come NAD, ad esempio switch e controller wireless con Cisco IOS-XE.

IPSec

Identity Services Engine dispone di supporto nativo per i tunnel IPSec tra ISE e NAD, che supportano anche la terminazione dei tunnel IPSec. Questa è una buona opzione quando RADIUS over DTLS o RADIUS over TLS non è supportato ma deve essere usato con moderazione in quanto solo 150 tunnel sono supportati per ISE Policy Services Node. ISE 3.3 e versioni successive non richiedono più una licenza per IPSec, ma sono ora disponibili in modalità nativa.

Riduzione parziale

Segmentazione RADIUS

Segmentare il traffico RADIUS verso le VLAN di gestione e i collegamenti protetti e crittografati, ad esempio tramite SD-WAN o MACSec. Questa strategia non azzera il rischio di attacco ma può ridurre notevolmente la superficie di attacco della vulnerabilità. Ciò può costituire una buona misura di interruzione durante l'implementazione del requisito Message-Authenticator o del supporto DTLS/RadSec. L'attacco richiede che l'autore di un attacco riesca a gestire correttamente la comunicazione RADIUS, in modo che se un utente non riesce a accedere a un segmento di rete con quel traffico, l'attacco non è possibile. Questa limitazione è solo parziale in quanto una configurazione errata o il danneggiamento di una parte della rete può esporre il traffico RADIUS.

Se il traffico RADIUS non può essere segmentato o crittografato, è possibile implementare funzionalità aggiuntive per impedire il corretto funzionamento del protocollo MITM su segmenti a rischio, quali: Protezione origine IP, ispezione ARP dinamica e snooping DHCP. È inoltre possibile utilizzare altri metodi di autenticazione basati sul tipo di flusso di autenticazione, ad esempio TACACS+, SAML, LDAPS e altri.

Stato vulnerabilità Identity Services Engine

Nelle tabelle vengono descritti i componenti disponibili a partire da Cisco ISE 3.4 per proteggere i flussi di autenticazione da Blast-RADIUS.

Per evitare che il flusso sia vulnerabile, è necessario che i tre elementi seguenti siano disponibili per un flusso che utilizza solo l'autenticatore del messaggio e non la crittografia DTLS/RadSec/IPSec:

• Il dispositivo di accesso alla rete DEVE inviare l'attributo Message-Authenticator in Access-Request.
• Il server RADIUS DEVE richiedere l'attributo Message-Authenticator in Access-Request.
• Il server RADIUS DEVE rispondere con l'attributo Message-Authenticator in Access-Challenge, Access-Accept e Access-Reject.

Fare riferimento all'ID bug Cisco CSCwk67747 che sta tracciando le modifiche per chiudere le vulnerabilità quando Cisco ISE funziona come client RADIUS.

ISE come server RADIUS

ISE come client RADIUS

Aggiornamenti client RADIUS ISE

I miglioramenti apportati a Cisco ISE come client RADIUS sono inclusi nelle seguenti versioni: 3.1 patch 10, 3.2 patch 8, 3.3 patch 5, 3.4 patch 2, 3.5 e versioni successive. Usare l'ID bug Cisco CSCwk67747. Dopo l'installazione della patch o dell'aggiornamento, tutte le nuove risorse hanno creato una configurazione predefinita più sicura. Le risorse esistenti devono essere modificate per utilizzare una configurazione più sicura dopo l'applicazione della patch o l'aggiornamento. Nuova casella di controllo aggiunta: "Message Authenticator Required On Response" (Autenticatore messaggi richiesto in risposta), se selezionata, ha un duplice scopo: Cisco ISE invia sempre l'autenticatore del messaggio e l'autenticazione ha esito negativo se viene ricevuta una risposta senza l'autenticatore del messaggio. Il comportamento è il seguente:

Case	NAD ha incluso l'autenticatore del messaggio nella richiesta	NAD non ha incluso l'autenticatore del messaggio nella richiesta
Prima di patch/aggiornamento	ISE invia l'autenticatore del messaggio al token RADIUS, al server RADIUS esterno o al CoA	ISE non invia l'autenticatore del messaggio al token RADIUS, al server RADIUS esterno o al CoA
Dopo l'applicazione della patch o dell'aggiornamento e la casella di controllo Autenticatore messaggi obbligatorio in risposta è deselezionata.	ISE invia l'autenticatore del messaggio al token RADIUS, al server RADIUS esterno o al CoA	ISE non invia l'autenticatore del messaggio al token RADIUS, al server RADIUS esterno o al CoA
Dopo l'applicazione della patch o dell'aggiornamento è selezionata la casella di controllo Autenticatore messaggi obbligatorio in risposta.	ISE invia l'autenticatore del messaggio al token RADIUS, al server RADIUS esterno o al CoA	ISE invia l'autenticatore del messaggio al token RADIUS, al server RADIUS esterno o al CoA

Server token RADIUS

Una nuova casella di controllo: Message Authenticator Required On Response è stata aggiunta nella scheda Authentication (Autenticazione) per la configurazione del server token RADIUS:

Se la casella è selezionata, se viene ricevuta una risposta RADIUS senza l'autenticatore del messaggio, nel log di autenticazione dettagliato viene registrato un messaggio di errore a cui è possibile accedere tramite Live Log o un report di autenticazione RADIUS:

Server RADIUS esterno

Una nuova casella di controllo: L'autenticatore del messaggio richiesto in risposta è stato aggiunto alla configurazione del server RADIUS esterno:

Se la casella è selezionata, se viene ricevuta una risposta RADIUS senza l'autenticatore del messaggio, nel log di autenticazione dettagliato viene registrato un messaggio di errore a cui è possibile accedere tramite Live Log o un report di autenticazione RADIUS:

Cambiamento di autorizzazione (CoA)

Le modifiche CoA sono state apportate ai profili dei dispositivi di rete nel cassetto delle modifiche di autorizzazione (CoA):

L'opzione Send Message-Authenticator è una funzionalità precedente, la nuova opzione è Message-Authenticator Required on response. Cisco ISE invia l'attributo autenticatore del messaggio se l'opzione Invia autenticatore messaggio richiesta in risposta è selezionata indipendentemente dal fatto che sia selezionata o meno. Send Message-Authenticator viene mantenuto per le configurazioni esistenti. Se il NAD non include Message Authenticator nella risposta CoA, nel report di autenticazione dettagliato disponibile tramite Live Logs viene visualizzato il seguente errore:

Non è possibile modificare i profili di dispositivo di rete predefiniti forniti da Cisco. Per utilizzare la nuova opzione, è possibile duplicare il profilo del dispositivo di rete e abilitare l'impostazione sul profilo duplicato. Ai dispositivi di rete deve quindi essere assegnato il nuovo profilo di dispositivo di rete. Questa operazione è stata effettuata per ridurre il rischio di causare un'interruzione della rete a seguito di una patch o di un aggiornamento introducendo un'incompatibilità tra Cisco ISE e i dispositivi NAD esistenti. Se è in uso un profilo definito dall'utente esistente, si consiglia di duplicarlo e provare almeno 1 di ogni tipo di dispositivo sulla rete che utilizza quel profilo prima di apportare una modifica al profilo del dispositivo di rete esistente.

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
2.0	21-Aug-2026	Formattazione principale, modifiche al testo alternativo, sezione Introduzione, collegamenti
1.0	07-Aug-2024	Versione iniziale