Zerologon: hacking dei server Windows con un mucchio di zeri

Il bug della settimana si chiama Zerologon ed è un by-pass di autenticazione.

Lo vedrai anche indicato come CVE-2020-1472 e la buona notizia è che è stato corretto nell’aggiornamento di agosto 2020 di Microsoft .

In altre parole, se pratichi il corretto patching, non devi andare nel panico. (Sì, questo è un indizio non mascherato: se non hai ancora patchato i tuoi server Windows dall’agosto 2020, per favore fallo ora, per il bene di tutti, non solo per il tuo.)

Tuttavia, Zerologon è una storia affascinante che ricorda a tutti noi due lezioni molto importanti, ovvero che:

La crittografia è difficile da ottenere correttamente.
Gli errori crittografici possono richiedere anni per essere individuati.
I dettagli cruenti del bug non sono stati divulgati da Microsoft nell’agosto 2020, ma i ricercatori della società olandese di sicurezza informatica Secura hanno scavato nel componente Windows interessato, Netlogon, e hanno individuato una serie di gravi buchi crittografici nella versione senza patch e come farlo sfruttarli.

In questo articolo, non costruiremo un attacco o mostreremo come creare pacchetti di rete per sfruttare il difetto, ma esamineremo i problemi crittografici che sono rimasti inosservati nel protocollo Microsoft Netlogon Remote per molti anni.

Dopo tutto, coloro che non ricordano la storia sono condannati a ripeterla.

Autenticazione tramite Netlogon
Netlogon è un protocollo di rete che, nelle sue stesse parole, “è un’interfaccia di chiamata di procedura remota (RPC) utilizzata per l’autenticazione di utenti e macchine su reti basate su dominio”.

A 280 pagine, la specifica del protocollo remoto Netlogon – è una specifica aperta al giorno d’oggi, non proprietaria di Microsoft – è molto più breve del Bluetooth, ma molto più lunga di quanto qualsiasi team di programmazione possa sopportare per un periodo di mesi o anni, figuriamoci giorni o settimane.

La sua lunghezza deriva in parte dal fatto che ci sono spesso molti modi diversi di fare la stessa cosa, a volte con più algoritmi di fallback diversi che sono stati mantenuti per garantire la retrocompatibilità con i dispositivi più vecchi.

Ironia della sorte, forse, la sezione 5, Considerazioni sulla sicurezza , ha solo due brevi parti: una sottosezione di una pagina intitolata Considerazioni sulla sicurezza per gli implementatori e una breve tabella (sebbene certamente utile) chiamata Indice dei parametri di sicurezza che si collega a varie sezioni importanti nelle specifiche. .

Elenco dei parametri di sicurezza del protocollo Netlogon.
Gli elementi evidenziati sono quelli che esaminiamo in questo articolo.
Iniziare con Netlogon
Un computer client che desidera comunicare con un server Netlogon come un controller di dominio Windows inizia inviando otto byte casuali (ciò che viene spesso chiamato nonce , abbreviazione di numero utilizzato una volta ) al server.

Il server risponde con 8 byte casuali, come spiegato nella sezione 3.1.4.1, Negoziazione chiave di sessione :

RICHIESTA -> ClientChallenge (8 byte casuali, ad esempio 452fdbfd2e38b9e0) ->
REPLY <- ServerChallenge (8 byte casuali, ad esempio 7696398fe5417372) <-
Come mostrato sopra, Microsoft si riferisce a queste nonce rispettivamente come ClientChallenge(CC) e ServerChallenge(SC), se si desidera abbinare questa discussione alla documentazione del protocollo.

Entrambe le parti poi mescolano le due stringhe casuali insieme a un segreto condiviso per inventare una chiave di crittografia una tantum, nota come SessionKey(SK).

Su una rete Windows, il componente segreto è la password di dominio del computer da cui ti connetti.

Sul client, questo viene archiviato in modo sicuro da Windows nel registro; sul controller di dominio, è archiviato nel database di Active Directory.

Questo SessionKeyrimescolamento viene eseguito utilizzando l’hash crittografico con chiave chiamato HMAC-SHA256 .

L’algoritmo è specificato nella sezione 3.1.4.3.1, AES Session-Key , e nello pseudocodice ha questo aspetto:

Supponendo che il client che richiede l’accesso abbia la stessa password memorizzata localmente come il server Netlogon ha registrato centralmente e dato che ogni parte ha già detto all’altro la sua sfida casuale di 8 byte, entrambe le parti dovrebbero ora essere arrivate allo stesso, uno- off SessionKeyvalue (SK) per proteggere il resto della loro comunicazione.

Questa configurazione della chiave di sessione evita di utilizzare la password segreta direttamente nella crittografia del traffico Netlogon e garantisce una chiave univoca per ogni sessione, in cui entrambe le parti iniettano la propria casualità. (Questo è un approccio comune: la configurazione di una connessione wireless WPA-2 utilizzando una chiave precondivisa segue un processo simile .)

In teoria, il server potrebbe presumere ciecamente che il client conosca la vera password semplicemente accettando immediatamente chiamate di funzioni crittografate; se il client avesse imbrogliato finora utilizzando una password inventata, le richieste non sarebbero state decriptate correttamente e lo stratagemma fallirebbe.

La buona pratica, tuttavia, dice che ciascuna estremità deve verificare prima l’altra, ad esempio crittografando una stringa di test nota che l’altra estremità può convalidare, e questo è ciò che accade dopo.

Ovviamente, il client non può condividere direttamente la chiave di sessione perché ciò consentirebbe a chiunque altro sulla rete di rilevarla e dirottare la sessione.

Invece, il client dimostra di conoscere la chiave di sessione crittografando la chiave a ClientChallengecui si è impegnato all’inizio, utilizzando la chiave SessionKeyappena calcolata.

Microsoft chiama questo calcolo delle credenziali di accesso alla rete , descritto in dettaglio nella sezione 3.1.4.4.1:

All’altra estremità, il server fa la stessa cosa al contrario e verifica che l’originale ClientChallengeesca correttamente quando il testo cifrato viene decrittografato con la chiave di sessione.

A questo punto, sembra che un cliente impostore sia bloccato.

Senza la password segreta corretta, che puoi ottenere solo disponendo già dell’accesso a livello di amministratore a un computer attendibile sulla rete, non otterrai la stessa chiave di sessione del server.

Senza la chiave di sessione corretta, non si produrrà una versione crittografata della stringa casuale di 8 byte originale che il server accetterà per l’autenticazione.

Uno spiraglio nell’armatura
A questo punto, se sei interessato alla crittografia, probabilmente ti starai chiedendo: “Che diavolo è l’algoritmo di crittografia soprannominato AES-128-CFB8nello pseudocodice sopra?”

Investighiamo.

AES, abbreviazione di Advanced Encryption Standard, sembra una buona scelta perché è attualmente accettato come un algoritmo potente senza falle di sicurezza note.

Inoltre, una chiave da 128 bit è attualmente considerato soddisfacente perché ci vorrebbe troppo tempo per provare tutte le possibili 2 128 chiavi, anche se sfruttata tutta la potenza di calcolo del mondo per te.

Per la cronaca: AES non utilizza calcoli interni che potrebbero essere accelerati con i cosiddetti algoritmi quantistici , quindi è considerato sicuro post-quantistico . Anche se un computer quantistico veramente potente venisse costruito domani, non sarebbe di alcun uso speciale, per quanto ne sappiamo, per crackare AES più velocemente di quanto possiamo fare con i normali computer oggi.

Ma algoritmi come AES possono essere utilizzati in molte modalità diverse e non tutti sono adatti a tutti gli scopi.

La modalità più nota, che si può pensare come “crittografia diretta”, è chiamata AES-128-ECB, e codifica 16 byte di input alla volta, producendo direttamente 16 byte di output.

Si noti che abbiamo semplificato questi diagrammi fingendo che AES-128 funzioni su 4 byte (32 bit) alla volta invece che su 16 byte (128 bit), ma i principi sottostanti sono ancora perfettamente chiari:

 

ECB sta per Electronic Code Book , perché il cifrario in questa modalità funziona davvero come un codebook di dimensioni inimmaginabili.

Il moniker del codebook è del tutto teorico. In pratica, avresti bisogno di un codebook diverso per ognuna delle 2 128 chiavi diverse, con ogni libro che elenca tutti i valori di crittografia per ciascuna delle 2 128 diverse stringhe di input di 16 byte. E avresti bisogno di altri 2 128 (ovvero 300 milioni di milioni di milioni di milioni di milioni) di codebook per elencare anche tutte le possibili decifrazioni, se mai avessi lo spazio o il tempo per decodificare ciò che avevi precedentemente crittografato.

Sfortunatamente, anche la semplicità della modalità libro dei codici è un punto debole, perché ogni volta che c’è testo ripetuto in uno dei blocchi di input, lo saprai perché otterrai una ripetizione anche nel testo cifrato:

 

Nella migliore delle ipotesi, la BCE rivela se ci sono modelli nell’input, qualcosa che un algoritmo di crittografia dovrebbe nascondere.

Nel peggiore dei casi, significa che se mai riuscissi a capire quale fosse il testo in chiaro in una parte dell’input – un’intestazione di capitolo, ad esempio, o parte di un indirizzo Bitcoin – sarai automaticamente in grado di decrittografare quel testo ovunque appaia.

Esistono varie soluzioni per utilizzare algoritmi di crittografia basati su blocchi in modo che non rivelino schemi ripetuti, e una di queste è la modalità Cipher Feedback (CFB), che funziona in questo modo:

 

Invece di crittografare i blocchi di testo in chiaro con AES ogni volta, crittografate invece l’ultimo blocco di testo cifrato, quindi XOR quel “flusso di chiavi” con il successivo blocco di testo in chiaro.

In questo modo, anche se ottieni due blocchi di testo in chiaro identici di seguito, il testo cifrato non si ripeterà.

Ovviamente, non esiste un blocco di testo cifrato da utilizzare all’inizio, quindi la AES-128-CFBmodalità richiede non solo una chiave di 16 byte per il motore di crittografia, ma anche un vettore di inizializzazione (IV) di 16 byte come input iniziale per ottenere il keystream iniziato.

Notare che l’IV può, e di solito è, condiviso insieme al testo cifrato: l’IV non ha bisogno di essere tenuto segreto, perché la segretezza della crittografia è fornita dalla chiave che controlla il motore di crittografia AES.

Tuttavia, un vettore di inizializzazione CFB dovrebbe essere scelto in modo casuale e non dovrebbe mai essere riutilizzato, specialmente con la stessa chiave AES.

CFB8 spiegato
Uno svantaggio che AES-ECB e AES-CFB hanno in comune è che finché non si dispone di un blocco di input completo di 16 byte, non è possibile produrre alcun output, perché non possono funzionare su blocchi parziali: AES è progettato per mescolare -e-scambia-e-trita-e-munge blocchi di 128 bit alla volta.

Ciò significa anche che sei bloccato se hai byte rimanenti alla fine, ad esempio se hai 67 byte da crittografare, che è 4 × 16 + 3.

È necessario trovare un modo per riempire l’ultimo blocco alla dimensione corretta e quindi determinare in modo affidabile se sono stati aggiunti byte aggiuntivi che devono essere rimossi quando si decrittografano i dati.

Una soluzione a questo è AES-CFB8, una modalità che non abbiamo mai sentito prima di nessuno nella vita reale, ma progettata per utilizzare un ciclo di missaggio AES completo a 128 bit per ogni byte di input, quindi puoi crittografare anche solo un singolo carattere senza imbottitura.

Invece di crittografare l’ultimo blocco completo di testo cifrato per creare il successivo blocco completo di dati keystream, si utilizza ogni volta solo il primo byte del keystream e lo XOR con un byte di testo in chiaro anziché un blocco di testo in chiaro a 16 byte.

Quindi tagli il byte del keystream che hai appena usato e aggiungi il nuovo byte del testo cifrato alla fine del keystream, dandoti un blocco completo di dati da crittografare per generare il prossimo byte del keystream:

 

Netlogon CFB8 considerato dannoso
Purtroppo, il modo in cui Netlogon utilizza AES-128-CFB8è significativamente meno sicuro di quanto dovrebbe essere.

I ricercatori di Secura hanno individuato il problema molto rapidamente leggendo la documentazione di Microsoft, dove l’algoritmo non è definito genericamente (come lo abbiamo elencato sopra), ma dato in una forma pericolosamente semplificata.

La sezione 3.1.4.4.1 specifica il processo [Calcolo] delle credenziali AES come segue:

Se il supporto AES viene negoziato tra il client e il server,
le credenziali di accesso alla rete vengono calcolate utilizzando la crittografia AES-128
algoritmo in modalità CFB a 8 bit con vettore di inizializzazione zero.
[Sk sotto è l’abbreviazione di SessionKey]

ComputeNetlogonCredential (Input, Sk, Output)
SET IV = 0
CALL AesEncrypt (Input, Sk, IV, Output)
Probabilmente hai già notato l’errore crittografico: “le credenziali sono calcolate […] con un vettore di inizializzazione zero “.

Come abbiamo già accennato, gli IV dovrebbero essere scelti casualmente e usati solo una volta con qualsiasi chiave – in effetti, è per questo che sono spesso indicati come nonce , per i numeri usati una volta .

Ma c’è un problema ancora più grande con un IV tutto zero in modalità CFB8, come ha scoperto Secura.

Puoi visualizzare il problema se usi un IV tutto zero più un blocco tutto zero di byte di testo in chiaro:

 

Poiché AES è un codice di alta qualità senza pregiudizi statistici noti, puoi inserire qualsiasi input e crittografarlo con qualsiasi chiave e la possibilità che ogni singolo bit nell’output sia zero (o uno) è del 50%.

Il valore di ogni bit di uscita è come il lancio di una moneta digitale.

Quindi la possibilità che il primo byte di output sia zero è uguale alla possibilità che i primi 8 bit di output siano tutti zero, che è 50% × 50% × 50% … otto volte (50% è solo un altro modo di scrivere 0,50 , che è uguale a 1/2).

50% 8 è 2 -8 , o 1/256.

Ricorda quella probabilità.

Nel diagramma sopra abbiamo ipotizzato che il primo byte di output sia effettivamente risultato zero, e puoi vedere che se ciò accade, l’intero processo di crittografia viene essenzialmente “bloccato” in uno stato completamente zero.

Il byte keystream (nero) risulta come 00, quindi quando lo XOR con il primo byte di testo in chiaro (rosa) di 00 ottieni un byte di testo cifrato (rosso) di 00.

Quindi, quando tagli il primo 00 dall’estremità sinistra dell’IV (bianco) e aggiungi il nuovo testo cifrato 00 alla fine, sei esattamente di nuovo dove hai iniziato, con un altro IV tutto zero e un buffer di testo in chiaro rimanente di tutti zeri.

Quando si crittografa il “nuovo” IV con la chiave, si ottiene esattamente lo stesso risultato di prima, perché tutti gli input sono di nuovo uguali e ne esce un altro byte di 00, che XOR con il successivo testo in chiaro 00 per produrre un altro testo cifrato byte di 00, che ritorna nell’IV per riportarlo a zero.

Come ingannare Netlogon
I ricercatori di Secura si sono subito resi conto di cosa sarebbe successo se avessero tentato di autenticarsi su un server Netlogon più e più volte utilizzando un ClientChallengenonce composto da 8 zeri.

Circa una volta ogni 256 volte il server inventerebbe in modo casuale una chiave di sessione per la quale la versione correttamente crittografata del loro tutto zero ClientChallenge…

… sarebbe esso stesso tutti zeri.

Abbiamo provato un IV al-zero con un ClientChallenge tutto zero 2560 volte.
Una su 256 volte la chiave scelta ha dato anche un output tutto zero.
In altre parole, inviando un ClientChallengedi 0000000000000000 e poi ciecamente anche inviando un Netlogon Credential Computation (vedi sopra) di 0000000000000000, avrebbero ottenuto il calcolo delle credenziali corretto per caso 1/256 delle volte, anche se non avevano idea di cosa il il SessionKeyvalore corretto dovrebbe essere perché non avevano idea di quale password segreta usare.

In poche parole, 1/256 delle volte, sono finiti in una situazione in cui potevano sempre produrre dati crittografati correttamente da trasmettere al server, senza avere la più pallida idea di quale fosse la password o la chiave di sessione, purché ne avessero solo bisogno crittografare gli zeri !

Meglio ancora, il server li avviserebbe automaticamente quando hanno vinto il jackpot accettando la loro presentazione delle credenziali.

Sicuramente non è sfruttabile?
A questo punto probabilmente starai pensando: “Qual è la possibilità che ogni volta che hanno bisogno di inviare un token di autenticazione crittografato o di fornire dati di password crittografati, avrebbero solo bisogno di crittografare gli zeri?”

Ce lo chiedevamo anche noi, ma i nostri intrepidi ricercatori hanno trovato un modo.

Una delle funzioni della password di Netlogon, NetrServerPasswordSet2(sezione 3.4.5.2.5), può essere chiamata in remoto da una sessione Netlogon che ha già superato il controllo del calcolo delle credenziali di Netlogon .

Questa funzione, che fa quello che suggerisce il nome e cambia la password del server, richiede al chiamante di crittografare correttamente due blocchi di dati:

L’originale ClientChallenge, trattato come un numero a 64 bit, con l’ora corrente (in quello che è noto come “Secondi Posix” o forma di epoca Unix) aggiunta ad esso. Questi dati vengono utilizzati come controllo di autenticazione per assicurarsi che sia sempre lo stesso programma client che tenta di modificare la password.
Un buffer di 516 byte che specifica la nuova password, formattata come (512-N) byte di dati casuali, seguita da N byte che specificano la password, seguita dalla lunghezza della password N espressa come numero di 4 byte.
Il ClientChallengeè tutti gli zeri, perché ciò che era necessario per ottenere l’exploit iniziato, in primo luogo, ma il tempo corrente in POSIX secondi è qualcosa di simile a questo:

$ date –utc +% s
1600300026
Il tempo Posix denota il numero di secondi dall’inizio dell’epoca Unix, che iniziò, per definizione, alle 1970-01-01T00: 00: 00Z, una data ormai più di 50 anni fa.

I ricercatori si sono trovati sulle corna di un dilemma: ClientChallengeera zero, ma il tempo no, quindi la somma di quei due numeri non poteva essere zero, e quindi non sarebbe stata crittografata a zero …

… e quindi gli aggressori avrebbero bisogno della chiave di sessione originale, dopotutto, e per ottenere la chiave di sessione avrebbero bisogno di conoscere una password valida per un computer adatto sulla rete.

Cosa fare?

Bene, i ricercatori hanno semplicemente fatto finta che fosse di nuovo il 1970, hanno usato un timestamp di zero aggiunto a uno ClientChallengedi zero …

… e al server non importava: apparentemente non c’era alcun controllo per vedere se il timestamp era di decenni nel passato.

Ovviamente, i 516 byte tutto zero che i ricercatori dovevano ora fornire nel buffer delle password crittografate li costringevano a specificare una lunghezza della password pari a zero, che potresti pensare non sarebbe stata consentita dal server.

Ma i ricercatori ci hanno provato comunque …

… e al server non importava neanche quello, impostando la propria password di Active Directory su <nessuna password>.

E dopo?
Fortunatamente, o forse un po ‘meno sfortunatamente, la modifica della password che sono stati in grado di apportare non ha ripristinato la password di accesso effettiva del server, quindi i ricercatori non hanno potuto semplicemente accedere direttamente e assumere il controllo del server tramite un desktop Windows convenzionale.

Tuttavia, hanno segnalato che modificando la password di Active Directory del controller di dominio stesso, erano in grado di :

estrarre tutti gli hash degli utenti dal dominio tramite il protocollo DRS (Domain Replication Service). Ciò include gli hash dell’amministratore di dominio (inclusa la chiave “krbtgt”, che può essere utilizzata per creare biglietti d’oro) che potrebbero quindi essere utilizzati per accedere al controller di dominio (utilizzando un attacco pass-the-hash standard) e aggiornare la password del computer memorizzata in registro locale dei controller di dominio.
In altre parole, completa compromissione della rete.

Tutto a causa di una specifica crittografica eccessivamente semplificata che comportava ogni volta il peccato cardinale di un vettore di inizializzazione completamente zero.

Ovviamente, quel difetto è stato aggravato da molte altre sviste programmatiche in cui una maggiore attenzione alla sicurezza e alla correttezza avrebbe potuto impedire questo attacco, tra cui:

Consentendo un tutto zero ClientChallengein primo luogo. Partiamo dal presupposto che la causa più probabile di un buffer tutto zero all’inizio del processo di Netlogon sarebbe un programma client inizializzato in modo errato o con errori, quindi lo rifiuteremmo comunque come precauzione.
Consentire una password di lunghezza zero. Dato che Windows ha già un meccanismo sicuro per la memorizzazione dei segreti condivisi, e comunque fa molto affidamento su di esso, non sembra necessario consentire password vuote, anche per account in cui non ci si aspetta che nessun essere umano acceda.
Consentire un campo di autenticazione basato sulla data in cui il timestamp potrebbe non essere corretto. Saremmo propensi a considerare questo come un avvertimento di un cliente difettoso o un tentativo di tirare fuori un trucco di sicurezza.
Cosa fare?
Questo bug apre una grave falla di sicurezza per chiunque sia già all’interno della tua organizzazione e forse anche per gli estranei, a seconda della topologia della tua rete.

Se non hai ancora applicato la patch di agosto 2020, devi farlo: non stai solo deludendo te stesso, stai deludendo anche tutti gli altri rendendo la tua rete un bersaglio più facile per i truffatori, e quindi rendendola di più probabilmente sarai la fonte di problemi di sicurezza per altre persone.

Inoltre:

Non prendere scorciatoie crittografiche come la scelta di una modalità di crittografia conveniente per la tua applicazione, ma poi prenditi delle libertà su come la usi perché è conveniente per i tuoi programmatori.
Programma in modo difensivo ogni volta che accetti dati non attendibili, soprattutto se i dati possono essere facilmente controllati per valori chiaramente falsificati o errati come timestamp di 50 anni nel passato.
Ritira le parti vecchie dei tuoi prodotti o delle tue specifiche il prima possibile dopo che saranno disponibili di migliori. Sebbene l’exploit in questo caso si basasse su parti aggiornate del protocollo Netlogon, come l’utilizzo di AES invece di ricadere su algoritmi meno recenti, si può sostenere che questo bug potrebbe essere stato trovato molto prima se le specifiche del protocollo non fossero gravate da così tante alternative modi per eseguire tutti i tipi di controlli relativi alla sicurezza.
Ma la cosa importante da ricordare qui è: patch presto, patch spesso .

Fonte : https://nakedsecurity.sophos.com/2020/09/17/zerologon-hacking-windows-servers-with-a-bunch-of-zeros/