Come vengono archiviate le credenziali di Windows memorizzate nella cache sul computer locale?

26

Come vengono archiviate le credenziali del dominio di Active Directory memorizzate nella cache su un client Windows? Sono archiviati nel database SAM locale, rendendoli così suscettibili agli stessi attacchi di tabelle arcobaleno a cui sono sensibili gli account utente locali o sono archiviati in modo diverso? Si noti che mi rendo conto che sono salati e con hash, in modo da non essere archiviati in testo normale, ma sono hash nello stesso modo degli account locali e sono memorizzati nella stessa posizione?

Mi rendo conto che almeno sono suscettibili a un attacco di forza bruta, ma questa è una situazione molto migliore rispetto alla vulnerabilità ai tavoli arcobaleno in caso di furto di una macchina.

windows active-directory security

— MDMarra
fonte

17

"Credenziali memorizzate nella cache"

Le credenziali memorizzate nella cache per un dominio AD sono in realtà due hash della password salati e archiviati nell'hive HKLM \ Security. Il percorso del file dell'alveare è: %systemroot%\System32\config\SECURITY

Solo l'utente "di sistema" ha accesso alle chiavi di registro:
HKLM\Security\Cache\NL$ndove si ntrova un indice 1 per il numero massimo di credenziali memorizzate nella cache.

Suscettibilità agli attacchi

Da WinNT a WinXP sono stati utilizzati gli hash "Lan Manager" per gli account locali , che possono essere facilmente interrotti su hardware moderno. Il cracking di solito richiede diversi minuti (di recente ho fatto 3 password in 00:08:06) con un computer desktop "normale". Gli hash di Lan Manager non sono salati, quindi ci sono anche tavoli arcobaleno pubblicamente disponibili.

Vista e versioni successive utilizzano gli hash NT per gli account locali . Windows 2000 e versioni successive utilizzano hash NT anche per gli account di dominio . Gli hash NT sono hash doppio MD4 salati. Il salt per voce impedisce l'uso di tabelle arcobaleno, ma MD4 può essere eseguito molto velocemente su hardware moderno: circa 6 anni di calcolo per una password a 60 bit. Con un po 'di fortuna e un cluster a 6 GPU, un cracker può rompere questo tipo di password in circa 6 mesi. Portandolo sul cloud, circa $ 35k su GPU Amazon EC2 - a seconda della disponibilità, potrebbero essere ore.

— Chris S
fonte

Immagino che la maggior parte della mia domanda fosse se queste credenziali archiviate fossero o meno suscettibili agli stessi attacchi basati su tabelle arcobaleno degli account locali di se fossero stati sottoposti a hash in un metodo diverso

— MDMarra,

Aggiornato ... Vista + è tutto uguale. Le versioni precedenti erano diverse.

— Chris S,

"L'hash NT della password viene calcolato utilizzando un algoritmo hash MD4 non salato." - Direttamente da TechNet: technet.microsoft.com/en-us/library/hh994565(v=ws.10).aspx

— thepip3r

Quella pagina è sbagliata, gli hash NT sono salati. Vedi la risposta di Joe qui sotto per un link a un KB.

— Chris S,

4

Le credenziali non sono effettivamente memorizzate nella cache sul computer locale. Vedi questo estratto dalla SM:

Sicurezza delle credenziali di dominio memorizzate nella cache

Il termine credenziali memorizzate nella cache non descrive accuratamente il modo in cui Windows memorizza nella cache le informazioni di accesso per l'accesso al dominio. In Windows 2000 e nelle versioni successive di Windows, il nome utente e la password non vengono memorizzati nella cache. Al contrario, il sistema memorizza un verificatore crittografato della password. Questo verificatore è un hash MD4 salato che viene calcolato due volte. Il doppio calcolo rende effettivamente il verificatore un hash dell'hash della password dell'utente. Questo comportamento è diverso dal comportamento di Microsoft Windows NT 4.0 e versioni precedenti di Windows NT.

http://support.microsoft.com/kb/913485

— joeqwerty
fonte

Bene, capisco che le credenziali stesse non sono effettivamente memorizzate nella cache, ma la mia domanda era più sulla falsariga di "sono gli hash risultanti memorizzati nel database SAM locale allo stesso modo degli account locali, rendendoli così vulnerabili agli stessi attacchi. " Lo modificherò tra un minuto per essere un po 'più chiaro.

— MDMarra,

1

meh .. per me questo è tritare le parole. la natura di "hashing" è un processo unidirezionale che crea sostanzialmente un valore offuscato della password utilizzando un algoritmo crittograficamente sicuro. Il problema è che MD4 potrebbe essere stato crittograficamente sicuro 10-15 anni fa, ma non è nemmeno più vicino (né MD5 o SHA1 sono nemmeno dal punto di vista di un crittografo). Quindi, se hai hardware di oggi che può rapidamente forzare lo spazio chiave dell'algoritmo o scoprire una collisione, puoi facilmente derivare la password

— dall'hash

Se le credenziali sono archiviate in qualsiasi modo o forma in modo che possano essere verificate in modalità offline - quindi sono a tutti gli effetti memorizzate nella cache, indipendentemente dall'aspetto dei dati in quella cache

— NiKiZe,

4

Sono gestiti da Credential Manager, per il quale esiste un'API Credential Manager. Gli hash salati vengono archiviati in modo un po 'sicuro sul disco e sono accessibili tramite HKLM \ Security. (Che è accessibile solo da LocalSystem per impostazione predefinita, ma è facile ignorare, ad esempio, da psexec -i -s regedit.exe.)

Su un sistema Windows in esecuzione, tuttavia, la situazione è più terribile, poiché le credenziali utilizzate di recente possono essere ottenute e invertite facilmente in testo semplice agganciando una DLL in Lsass. (Vedi Mimikatz.)

Quindi sì, troverai una sorta di hash (o hash di un hash, o 'verificatore' o come vuoi chiamarlo) su HKLM \ Security \ Cache sul client. Ma non credo che ci sia alcun modo possibile per attaccare l'hash sul disco. Non è lo stesso vecchio tipo di hash NTLM ad essere attaccabile.

— Ryan Ries
fonte

Il cracking offline delle password nel SAM è completamente diverso dall'aggancio di LSASS in memoria come fanno Mimikatz e WCE. E a seconda della complessità della password, il cracking offline della password del SAM può essere MOLTO facile (vedi samdump2)

— thepip3r