it-swarm.dev

Come funziona la modalità "Secure Desktop" di Windows?

Qualcuno può spiegare (o fornire un collegamento a una semplice spiegazione) di che cos'è la modalità "Secure Desktop" di Windows e come funziona?

Ne ho appena sentito parlare nella documentazione di KeePass ( KeePass - Inserisci chiave master su un desktop sicuro ) e vorrei capirlo meglio.

59
snth

Risposta breve

Esistono tre problemi separati che rivendicano il nome di "Desktop protetto":

  • Funzioni integrate di Windows come GINA e Credential Provider Model .
  • Separazione di applicazioni privilegiate e non privilegiate in esecuzione come lo stesso utente (prevenire nominalmente l'escalation dei privilegi), che possono o meno essere correlate a:
  • SwitchDesktop(), che è ciò che KeePass sta usando e potrebbe o meno (non sono sicuro) essere resistente a DLL Iniezione.

Risposta dettagliata

Come primer rapido su come sono costruite le GUI di Windows, praticamente tutto passa attraverso una funzione chiamata CreateWindow() (intendo tutto, ogni pulsante, ogni menu, tutto) e viene dato un hWnd o Window Maniglia. La modifica di queste finestre viene eseguita tramite un'altra funzione, SendMessage().

Ecco il trucco. Come applicazione in modalità utente, effettuando le giuste chiamate API posso abbastanza facilmente inviare messaggi ad altri Windows. È abbastanza banale far sparire i pulsanti dalle forme di altre persone. È un po 'più difficile eseguire l'iniezione DLL e agganciare il loop di messaggi che riceve i messaggi (il sistema operativo invia messaggi di Windows quando accadono loro cose) ma non molto più difficile. Se riesco ad agganciare quegli eventi, potrei inviare automaticamente il tuo modulo "sì/no". Oppure, potrei cambiare l'etichetta da ReallyDodgyVirus.exe A Explorer.exe E non saresti più saggio.

Inserisci: n articolo davvero valido sulle varie tecniche di inserimento del codice nello spazio degli indirizzi di un processo in esecuzione.

Ora, cosa stanno facendo KeePass?

Una breve panoramica della fonte mostra che stanno usando CreateDesktop(), SwitchDesktop() e CloseDesktop() per creare un secondo desktop collegato al dispositivo di visualizzazione fisico in cui ti trovi. In inglese, stanno chiedendo al kernel di creare per loro un desktop isolato i cui oggetti hWnd sono al di fuori dell'intervallo individuabile di SendMessage() di qualsiasi altra applicazione.

Devo sottolineare che SwitchDesktop sospende l'aggiornamento dell'interfaccia utente del desktop predefinito. Non sono sicuro che anche i loop dei messaggi siano bloccati - sospetto di no dal momento che il desktop è stato creato come nuovo thread.

In questo caso, KeePass è disegnando l'interfaccia utente, quindi l'esecuzione è non, come ho capito, come NT AUTHORITY/SYSTEM. Invece, il nuovo desktop viene creato in modo isolato dal resto del desktop corrente, che lo protegge. Sarò felice di essere corretto su questo. Tuttavia, vedere MSDN per SwitchDesktop :

La funzione SwitchDesktop ha esito negativo se il desktop appartiene a una stazione a finestra invisibile. SwitchDesktop fallisce anche quando viene chiamato da un processo associato a un desktop protetto come i desktop WinLogon e ScreenSaver. I processi associati a un desktop protetto includono processi UserInit personalizzati. Tali chiamate in genere falliscono con un errore "accesso negato".

Credo che ciò significhi che queste finestre di dialogo (salvaschermi, Accesso a Windows) sono integrate più profondamente in Windows in modo tale che vengano sempre eseguite come NT AUTHORITY\SYSTEM E il processo UserInit crea i processi secondari con autenticazione valida livello di privilegio.

Il motivo per cui ho sollevato questo problema è perché credo che ci siano due problemi: desktop diversi e separazione dei privilegi. Da Mark Russinovich's discussione sull'argomento di Secure Desktop :

Il meccanismo di integrità di Windows e UIPI sono stati progettati per creare una barriera protettiva attorno ad applicazioni elevate. Uno dei suoi obiettivi originali era impedire agli sviluppatori di software di prendere scorciatoie e di sfruttare applicazioni già elevate per eseguire attività amministrative. Un'applicazione in esecuzione con diritti utente standard non può inviare input di mouse o tastiera sintetici in un'applicazione elevata per fare le sue offerte o iniettare codice in un'applicazione elevata per eseguire operazioni amministrative.

Come dice SteveS, UAC esegue un processo desktop separato come NT AUTHORITY/SYSTEM. Se riesci a catturare UAC in azione (consent.exe) Tramite Process Explorer, è simile al seguente:

UAC under process Explorer

L'escalation dei privilegi come processo di cui non ho i dettagli, ma ecco cosa penso di capire: credo che il processo di escalation di privilegi nell'API di Windows provochi un processo in esecuzione come NT AUTHORITY/SYSTEM (Quindi in grado di eseguire il nuovo processo con qualunque privilegio voglia, in questo caso un amministratore). Quando un'applicazione richiede privilegi più elevati, questa domanda ti viene posta su un nuovo desktop localmente, a cui nessuna delle tue applicazioni può ottenere l'handle del desktop o uno degli handle dell'elemento della GUI. Quando acconsenti, consent.exe Crea il processo come utente privilegiato. Pertanto, il processo in esecuzione come NT AUTHORITY\SYSTEM È una conseguenza della necessità di creare un nuovo processo privilegiato, non come metodo per creare un desktop sicuro. Il fatto che il desktop sia diverso da quello predefinito è ciò che aggiunge sicurezza in entrambi i casi.

Credo che ciò che Mark intende sopra sia che, oltre a questi desktop sicuri, stanno accadendo due cose:

  • Il desktop dell'amministratore predefinito è infatti in esecuzione senza privilegi, contrariamente a Windows XP e precedenti e
  • Esistono ora applicazioni senza privilegi e privilegiate su desktop separati (dichiarazione di non responsabilità: potrebbero essere solo ACL sugli oggetti in memoria, non ne sono sicuro), assicurando che il codice senza privilegi non possa accedere agli oggetti privilegiati.

L'interfaccia utente di accesso a Windows è di nuovo diversa in Vista/7.

Chiaramente, nessuno di questi metodi ti difenderà dai rootkit in modalità kernel, ma impediscono l'escalation dei privilegi e il compromesso dell'integrità dell'interfaccia utente isolando le applicazioni privilegiate o, nel caso di KeePass, la finestra di dialogo sensibile.

Modifica

Avendo guardato più da vicino il codice KeePass, ho visto questo utile pezzo di C #:

Bitmap bmpBack = UIUtil.CreateScreenshot();
if(bmpBack != null) UIUtil.DimImage(bmpBack);
/* ... */

SecureThreadParams stp = new SecureThreadParams();
stp.BackgroundBitmap = bmpBack;
stp.ThreadDesktop = pNewDesktop;

Da questo puoi vedere che in effetti per imitare il consenso.exe, KeePass prende uno screenshot dello sfondo, lo attenua e crea il suo nuovo desktop con lo sfondo del vecchio desktop. Sospetto quindi che il vecchio desktop continui a funzionare anche se non viene visualizzato. Questo penso che confermi che nessuna azione magica NT AUTHORITY\SYSTEM Sta avvenendo sia con KeePass che consent.exe (Sospetto che il consenso.exe stia facendo la stessa cosa nell'interfaccia utente, sembra essere lanciato nel contesto di NT AUTHORITY\SYSTEM).

Modifica 2

Quando dico DLL Injection, sto specificamente pensando a DLL injection per corrompere l'interfaccia utente. DLL L'iniezione rimane possibile su KeePass come processo, non sono sicuro che possa essere usato per influenzare quell'interfaccia utente sicura. Potrebbe, tuttavia, essere utilizzato per accedere alla memoria del processo e dei relativi thread, acquisendo in tal modo la pre-crittografia della password immessa. Difficile, ma penso sia possibile. Apprezzerei qualcuno che ti consigli su questo se lo sanno.

63
user2213

Un "Desktop sicuro" è un desktop che può essere eseguito solo dal sistema stesso. Sembra un po 'strano, e probabilmente non spiega molto.

In Windows, un desktop è una vista che ti consente di interagire con i processi. Quando accedi a Windows (il prompt di accesso) sei su un desktop. Una volta effettuato l'accesso e visualizzato il menu Start, ci si trova su un desktop separato. Quando blocchi il PC, sei su un altro desktop. Quando viene visualizzato UAC, ci si trova su un altro desktop. Esistono diversi desktop in Windows.

Un desktop sicuro è un desktop che non rientra nell'ambito dell'accessibilità di altre applicazioni. Il desktop di accesso è un desktop sicuro (creato da winlogon.exe), così come il desktop UAC. Nessun altro processo può interagire con il desktop, quindi nessun altro processo può fare cose come attivare un pulsante o leggere il contenuto di una casella di testo. Questo è il motivo per cui UAC è (in teoria) utile.

Le applicazioni di terze parti possono creare un desktop sicuro per richiedere informazioni (come una password principale) e quindi passarle all'applicazione in questione. In questo modo nessun altro processo può, in teoria, ficcare la password.

Un buon inizio su desktop sicuri è la prima metà di questo articolo su come funziona UAC sul desktop sicuro: http://blogs.msdn.com/b/uac/archive/2006/05/03/589561 aspx .

16
Steve

il desktop sicuro viene eseguito con l'account di sistema locale e nessun altro processo può interagire con esso tranne OSK, Narratore ecc., è avviato da winlogon.exe e puoi disabilitarlo nel registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System modificando il valore di PromptOnSecureDesktop da 1 a 0 se si esegue cmd.exe con l'account di sistema, non interagirà ancora con il desktop sicuro e il desktop oscuro che si vede quando si fa clic su Esegui come amministratore sotto UAC Prompt è un desktop sicuro e quando si preme ctrl + Alt + Canc e la schermata skyblue che vedi con poche opzioni come bloccare questo compter ecc è anche un desktop sicuro, Windows per impostazione predefinita ha tre desktop 1 winlogon 2 screensaver 3 userdesktop

1
Mudasir