Operazioni e sicurezza sono da sempre antagonisti. Richiedere maggiore sicurezza implica sempre un qualche costo nelle operazioni. A questa legge non scritta non si sfugge. 

Nell’aggiornamento di novembre, Microsoft ha fatto una scelta che molte altre realtà che maneggiano algoritmi di sicurezza hanno fatto o faranno: abbandonare algoritmi vulnerabili sacrificando la compatibilità con infrastrutture e configurazioni non più compatibili per la più elevata base di riferimento scelta. Certamente è una operazione che probabilmente viene mal digerita da una comunità di utenti abituata alla garanzia di compatibilità a ritroso nel tempo, anche decennale, da parte dei software Microsoft; ma il panorama delle minacce impone pur qualche sacrificio. 

Per risolvere il bypass della sicurezza e la vulnerabilità derivante dall'elevazione di privilegio presente nelle autenticazioni che utilizzino la negoziazione RC4-HMAC (CVE-2022-37966) del DES (Data Encryption Standard), Microsoft si è vista costretta a impostare l’algoritmo AES (Advanced Encryption Standard: è un cifrario a blocchi che sostituisce il DES) come tipo di crittografia predefinita per le chiavi di sessione (una chiave simmetrica negoziata dal client e dal server sulla base di un segreto condiviso e abbastanza forte da resistere alla crittoanalisi per l'intera durata della sessione) sugli account che non siano già contrassegnati con un tipo di crittografia diverso predefinito. Insomma, imposta una nuova configurazione di base, ereditata da tutti gli account che non indichino esplicitamente un'altra impostazione. 

La vulnerabilità CVE-2022-37966 (Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability) è stata classificata con gravità 8.1/7.1, che comunque le si intenda è alta (si veda https://nvd.nist.gov/vuln/detail/CVE-2022-37966">https://nvd.nist.gov/vuln/detail/CVE-2022-37966) in quanto consente l’elevazione di privilegio. Accade in una autenticazione Kerberos che utilizzi una sicurezza DES/RC4 e non AES, ovvero che utilizzi l’algoritmo RC4-HMAC: questo è un algoritmo basato su hash che vorrebbe garantire l'integrità e l'autenticità di un messaggio all’interno del protocollo crittografico RC4 (Rivest Cipher 4), ma risultando questo protocollo debole a partire dal 2015, ne consegue un problema di sicurezza oggettivo. Effettivamente è da tempo che RC4 è stato estromesso dal novero dei sistemi crittografici, come, ad esempio, nel TLS, così come imposto dalla RFC7465 che ne vieta l’uso. 

Dopo l’aggiornamento è evidente che l'autenticazione Kerberos (protocollo di rete per l’autenticazione basato su "ticket" per la dimostrazione della identità dei nodi in comunicazione) non riesca più su account utente, account computer, account di servizio e account del servizio gestito di gruppo (gMSA) che adottino RC4 come tipo di crittografia: l’aggiornamento ha rimosso questo algoritmo tra quelli supportati. La mitigazione dei problemi derivanti dalla mancata autenticazione nelle nuove condizioni potrebbe essere ovviamente il ripristino di RC4: ma ha un senso? Se si tratta di una metodologia insicura, perché rischiare? In ogni caso Microsoft, con la KB5021131, indica proprio i modi per gestire le modifiche al protocollo Kerberos che derivano da questa patch e come riportare indietro le lancette dell’orologio. 

Per capire la situazione pre aggiornamento (o in caso di aggiornamento eseguito), basta interrogare Active Directory alla ricerca della chiave “DefaultDomainSupportedEncTypes” per utenti e computer e confrontare lo stato dell’attributo “ms-DS-SupportedEncryptionType”: ovviamente, se abbiamo utilizzato un tipo non più sopportato, questo attributo non verrà trovato impostato dopo l’aggiornamento. 

L’alternativa è trovarsi un evento 42 (“Kerberos Key Distrbution Center non dispone di chiavi complesse per l'account”) come segnale del motivo dell’inutilizzabilità degli account precedentemente impostati all’uso di DES/RC4 come sistema crittografico. Molto probabilmente potrà essere risolto reimpostando le password del Ticket-granting Ticket (un tipo speciale di biglietto che può essere utilizzato per ottenere altri biglietti dal servizio Kerberos), proprio come suggerito da Microsoft, che tra le altre cose fornisce anche uno script PowerShell per realizzare questo compito: lo si ottiene dal sito GitHub Microsoft: https://github.com/microsoft/New-KrbtgtKeys.ps1 

Per maggiori dettagli è comunque possibile consultare la KB di Microsoft all’indirizzo: https://support.microsoft.com/en-gb/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d">https://support.microsoft.com/en-gb/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d

Tweet