Impedire a LSASS di memorizzare password in chiaro nell'ambiente Kerberos

Naviga le tue risposte
9

È un noto rischio per la sicurezza che LSASS memorizza le password di testo non crittografato se un utente ha eseguito un accesso interattivo da tastiera su una macchina, sia che si tratti di accesso locale alla propria workstation o che utilizzi RDP su una workstation remota.

C'è anche una classica soluzione a questo - disabilitare wdigest e tspkg. Fin qui tutto bene, ma se Kerberos è supportato, apparentemente ha bisogno della password di testo chiaro per rinnovare il Ticket Granting Ticket (TGT) e quindi sei lasciato tra un rock e un luogo difficile - non supportare Kerberos e goderti tutto i rischi associati all'hash che passa o supporta Kerberos e accetta il rischio di password di testo di cleat. Il post collegato fornisce il seguente consiglio che ritengo inaccettabile:

Therefore, the most effective protection is to avoid interactive logons to any untrusted hosts.

Una grande azienda ha migliaia di server, come fai a sapere quale è compromessa e il login dovrebbe essere evitato?

La mia domanda: esistono misure pratiche oltre a quella di implementare un accesso 2FA (su questi problemi in un secondo momento) che consenta un accesso interattivo da tastiera sicuro?

P.S. Informazioni su 2FA. I metodi più comuni sono passcode + OTP e X.509 PKI su una smart-card. Non sono neanche impeccabili:

  1. se hai violato il processo di lsass, allora potresti tranquillamente usare il codice otp + passcode per accedere ad altri server mentre il passcode lo è valido. Usando l'auotmazione, questo potrebbe significare che hai effettuato l'accesso a decine di server o più durante la finestra di 60 secondi
  2. In base a questo articolo di TechNet l'utente invia il PIN al server e rende la smart card disponibile per il server RDP. Lo stesso processo del primo elemento può essere utilizzato per violare molti server mentre l'amministratore fa clic sul server compromesso.

°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸

Aggiornamento 2018 : a partire da Windows Server 2012 R2 e Windows 8.1, LSASS può essere eseguito come processo protetto abilitando il RunAsPPL impostazione e blocco del dumping delle credenziali. A partire da Windows 10 e Server 2016, Windows Credential Guard è abilitato per impostazione predefinita e raggiunge risultati simili.

°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸°º¤ø,¸¸,ø¤º°'°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°'°º¤ø,¸

    
posta Konrads 10.07.2013 - 11:03
fonte

2 risposte

1

Per rispondere alla tua domanda: credo che il modo più sicuro sarebbe usare psexec per ottenere una shell cmd remota. Questo metodo non dovrebbe comportare la memorizzazione di una password in chiaro. O intendi interattivo, E con una GUI?

Sfortunatamente la soluzione migliore è quella di evitare l'accesso interattivo quando possibile.

Fortunatamente ci sono alcuni modi sicuri per gestire da remoto le macchine:

  • winrm (incluso powershell Invoke-Command)
  • psexec (solo se NON si utilizza l'opzione "-u")
  • Assistenza remota

Sono abbastanza sicuri. Generi un token sulla macchina ma quello è parte dell'architettura di Windows e non un bug / difetto.

Dovresti evitare di usare quanto segue quando possibile, dato che è possibile scaricare le password in chiaro usando mimikatz:

  • RDP
  • psexec con l'opzione "-u"

Con Windows 8.1 (e Windows 2012R2?), la password di wdigest in chiaro è disabilitata per impostazione predefinita. Tuttavia, come dimostrato in questo articolo, è possibile semplicemente riattivare la memorizzazione della password in chiaro nel registro. E, ci sono sempre attacchi kerberos .

    
risposta data 22.01.2016 - 06:31
fonte
1

Anche se la tua risposta potrebbe non piacermi, non vedo alcun problema. Ok, avere la password in memoria in chiaro non è l'ideale, è necessario in questi casi. Come sarebbe un rischio per la sicurezza? Bene, per sfruttare questo, hai bisogno dei diritti di amministrazione, perché lsass viene eseguito sotto l'account di sistema protetto. E accedi come lo stesso utente che vuoi sfruttare. Quindi non vi è alcuna escalation dei privilegi che ne deriva; l'amministratore che ha effettuato l'accesso ha accesso alla propria password di chiaro. Sarebbe un problema se un programma potesse accedere a quella password di testo libero senza l'intervento dell'utente. Questo non è il caso (controllo dell'account utente, accesso al codice inietti, ecc.) Quindi è necessario disporre di ulteriori difetti per ottenerlo.

Per la tua domanda specifica: come sapere? Non lo sai Come quando gli utenti comunicano la loro password ad un amico. Non puoi proteggerti da questo.

Sì, l'uso di 2FA o Smartcard è generalmente una buona idea, poiché non inserisci direttamente una password.

    
risposta data 11.07.2013 - 21:07
fonte

Leggi altre domande sui tag

Sementi casuali non si propagano ai pozzi entropici in modo tempestivo Un firewall senza funzionalità extra [chiuso]