Perché Windows Credential Guard è sicuro, quando Windows è in grado di "accedere" alle credenziali usando RPC?

4

Ho letto alcuni blog che descrivono Windows Credential Guard: come funziona e quali sono i vantaggi di sicurezza che fornisce.

Tuttavia, alcuni di loro menzionano che Windows può "accedere" alle credenziali utilizzando le chiamate RPC alla modalità Virtual Secure (VSM).

Ma se il SO Windows è in grado di comunicare con VSM (Credential Guard), entrambi in esecuzione sull'hypervisor, perché un utente malintenzionato con privilegi amministrativi locali non è in grado di fare lo stesso?

NB: correggimi se alcuni dettagli riguardanti Windows Credential Guard sono errati.

    
posta Shuzheng 18.11.2018 - 12:36
fonte

1 risposta

5

Innanzitutto, è importante sapere cosa fa Windows Credential Guard e non protegge. Protegge le credenziali di dominio che sono state utilizzate per accedere al sistema corrente, così che strumenti come Mimikatz non possono semplicemente scaricare LSASS e ottenere credenziali memorizzate nella cache in un formato che può essere utilizzato per ruotare su altri sistemi sulla rete. Protegge anche le credenziali di dominio che sono state utilizzate per RDP. Non protegge gli account locali, i ticket del servizio Kerberos (Kerberos TGT è protetto però), le credenziali di digest o i verificatori di password di accesso memorizzati nella cache (questi sono gli hash, non le credenziali utilizzabili).

WCG fa parte della nuova funzionalità Virtualization Based Security (VBS) in Windows 10. Il modo in cui funziona consiste nell'utilizzare l'hypervisor Hyper-V per eseguire in tandem sia il sistema operativo primario sia un sistema operativo secondario sicuro. Il sistema operativo secondario sicuro è noto come Virtual Secure Mode (VSM) e comprende la modalità Secure Kernel (SKM) e la modalità utente isolato (IUM). In effetti, puoi pensare a VSM come a una specie di versione isolata di LSA, in esecuzione all'esterno del sistema operativo.

Uno dei principali requisiti di sicurezza per l'esecuzione corretta di VSM è l'attivazione di Secure Boot. Quando è abilitato, tutte le parti di codice dal caricatore di avvio di Windows all'hypervisor Hyper-V per SKM e IUM sono protette tramite una catena di trust firmata. Poiché la VM sicura ha numerose funzionalità di sicurezza abilitate (SMEP, TPM, IOMMU / VT-d, SLAT) diventa impossibile ottenere l'esecuzione del codice sulla VM sicura senza alcun tipo di vulnerabilità SMM o hardware. Poiché il sistema operativo normale (in cui un utente malintenzionato ottiene l'esecuzione di codice) è esso stesso virtualizzato separatamente da Hyper-V, è completamente isolato dalla VM sicura e non può influenzarlo se non tramite le API esposte.

Pertanto, l'unico modo per ottenere l'accesso ai dati memorizzati all'interno del VSM è tramite le API esposte. Queste API sono esposte solo al kernel (ring0) nel normale sistema operativo. Il principio operativo principale di WCG è che agisce come un oracolo. Chiedi di generare un token di accesso remoto per un particolare sistema utilizzando le credenziali memorizzate nella cache e lo fa. Non è possibile visualizzare le credenziali memorizzate nella cache e non è possibile utilizzare il token generato per ripristinare le credenziali memorizzate nella cache o generare altri token di accesso. Non puoi nemmeno usarlo per generare token dannosi, come un biglietto d'oro di Kerberos, che era possibile in passato tramite strumenti come Mimikatz.

La lettura futura che potresti trovare interessante:

risposta data 18.11.2018 - 13:29
fonte

Leggi altre domande sui tag