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

Introduzione

Il 7 luglio 2024, i ricercatori nel campo della sicurezza hanno rivelato la seguente 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. Hanno pubblicato un documento dettagliato dei risultati su https://www.blastradius.fail/pdf/radius.pdf che dimostra la riuscita della risposta falsificata contro i 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: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-radius-spoofing-july-2024-87cCDwZ3. Questo articolo tratta delle tecniche generali di mitigazione e del modo in cui si applicano ad alcuni prodotti Cisco, ma non a tutti, è necessario consultare la documentazione dei singoli prodotti per le specifiche. In qualità di server RADIUS di punta di Cisco, Identity Service Engine verrà descritto più dettagliatamente.

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-Authentication.

Quando il dispositivo di accesso alla rete (NAD) include l'attributo Message-Authenticator nel pacchetto Access-Request, Identity Services Engine includerà 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 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

Le autenticazioni che corrispondono 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 verranno eliminate 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 Operations (Operazioni) -> Troubleshoot (Risoluzione problemi) -> Diagnostic Tools (Strumenti diagnostici) -> General Tools (Strumenti generali) -> TCP Dump. Tenere presente che casi di utilizzo diversi dello stesso NAD possono includere o meno l'opzione Message-Authenticator.

Di seguito viene riportato un esempio di acquisizione di un oggetto Access-Request che include l'attributo Message-Authenticator:

Attributo message-authenticator in Radius access-request

Di seguito è riportato un esempio di acquisizione di un oggetto Access-Request 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 dovranno 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 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 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 con successo la comunicazione RADIUS (Man-in-the-Middle, MITM) in modo che se l'autore di un attacco non riesce ad 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. Può essere inoltre possibile utilizzare altri metodi di autenticazione basati sul tipo di flusso di autenticazione, ad esempio TACACS+, SAML, LDAPS, ecc.

Stato vulnerabilità Identity Services Engine

Nelle tabelle seguenti vengono descritti i dati disponibili a partire da ISE 3.4 per proteggere i flussi di autenticazione da Blast-RADIUS. Affinché il flusso non sia vulnerabile, per un flusso che utilizza solo l'autenticatore del messaggio e non la crittografia DTLS/RadSec/IPSec è necessario che siano presenti i tre elementi seguenti:
1) Il dispositivo di accesso alla rete DEVE inviare l'attributo Message-Authenticator in Access-Request.

2) Il server RADIUS DEVE richiedere l'attributo Message-Authenticator in Access-Request.

3) Il server RADIUS DEVE rispondere con l'attributo Message-Authenticator in Access-Challenge, Access-Accept e Access-Reject.

Fare riferimento a CSCwk67747 per verificare le modifiche e chiudere le vulnerabilità quando ISE agisce come client RADIUS.

ISE come server RADIUS

ISE come client RADIUS

Aggiornamenti client RADIUS ISE

I miglioramenti apportati all'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 tramite CSCwk67747. Dopo l'installazione della patch o dell'aggiornamento, le nuove risorse create utilizzeranno la nuova configurazione 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: ISE invierà sempre l'autenticatore del messaggio e ISE non riuscirà se viene ricevuta una risposta senza l'autenticatore del messaggio. Il comportamento è il seguente:

Server token RADIUS

È stata aggiunta una nuova casella di controllo: "Message Authenticator Required On Response" (Autenticazione messaggio richiesta in risposta) 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, verrà registrato un messaggio di errore nel log di autenticazione dettagliato a cui è possibile accedere tramite Live Log o un report di autenticazione RADIUS:

**Nota: L'autenticazione complessiva può comunque essere superata in base alla configurazione dei criteri, tramite l'autenticazione potrebbe corrispondere a un criterio imprevisto.

Server RADIUS esterno

È stata aggiunta una nuova casella di controllo: "Autenticatore messaggio richiesto in risposta" alla configurazione del server RADIUS esterno:

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

**Nota: L'autenticazione complessiva può comunque essere superata in base alla configurazione dei criteri, tramite l'autenticazione potrebbe corrispondere a un criterio imprevisto.

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 funzione precedente, mentre la nuova opzione è "Message-Authenticator Required on response. ISE invierà l'attributo autenticatore del messaggio se l'opzione Message-Authenticator Required on response è selezionata indipendentemente dal fatto che l'opzione "Send Message-Authenticator" sia selezionata o meno. L'opzione "Send Message-Authenticator" viene mantenuta per le configurazioni esistenti. Se il NAD non include Message Authenticator nella risposta CoA, nel report di autenticazione dettagliato disponibile tramite Live Logs verrà visualizzato il seguente errore:

 **Nota: Il CoA potrebbe avere esito positivo sul NAD anche se si è verificato un errore durante l'accesso ad ISE, in quanto il NAD potrebbe aver elaborato il CoA ma non aver incluso l'autenticatore del messaggio nella risposta.

Non è possibile modificare i profili dei dispositivi di rete predefiniti "Cisco forniti". Per utilizzare la nuova opzione, è possibile duplicare il profilo dei dispositivi di rete e abilitare l'impostazione sul profilo duplicato. Ai dispositivi di rete dovrà quindi essere assegnato il profilo dei dispositivi di rete appena creato. 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 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.