Mi sono chiesto: supponendo una moderna edizione di Windows (> = 7) e che il controllo dell'account utente sia abilitato, quali sono i vantaggi se utilizzo ulteriormente il sistema come utente standard? Da quello che ho capito, l'unica differenza è che, invece di fare semplicemente clic su "sì" nella finestra di dialogo, dovrò fornire una password di amministratore, ma i programmi saranno comunque impediti da azioni amministrative senza il mio consenso a causa del controllo dell'account utente.
Il blog DFIR ha un grande riassunto di UAC
Nell'articolo, l'autore raccomanda l'approccio Notifica sempre, in particolare per gli amministratori e i server critici. Oltre agli attacchi di social engineering come il modulo exploits / windows / local / ask nel metasploit-framework, ci sono anche decine di bypass UAC. L'autore copre le tecniche e gli strumenti per aggirare l'UAC meglio di molti altri.
L'autore non fa menzione, e non conosco uno strumento o una tecnica per aggirare sempre Notifica - tuttavia, l'escalation dei privilegi - specialmente per l'account SYSTEM - può essere possibile attraverso un exploit di privilegio-escalation e / o un problema di configurazione errata (sebbene l'exploit privesc di qualsiasi data non debba richiedere privilegi di amministratore, che non è necessariamente raro, ma una condizione che deve esistere affinché alcuni exploit funzionino). Le configurazioni errate includono in genere il percorso UNC e / o problemi di file / cartella / autorizzazione del servizio. In genere, queste tecniche di escalation dei privilegi richiedono una conoscenza avanzata dell'ambiente Windows che anche la maggior parte degli amministratori NT non possiede, tuttavia, di nuovo, alcune sono disponibili nel metasploit-framework e altri motori di sfruttamento (o in bundle con i kit di exploit) - abbassando così la barriera di accesso a chiunque abbia un intento contraddittorio. Altre volte, gli amministratori o gli strumenti di amministrazione lasciano semplicemente la password in chiaro (o in un formato facilmente reversibile) nei file sul sistema operativo, su una nota adesiva o su altri OPSEC con assistenza ridotta.
La maggior parte degli utenti si rivoltano contro Notifica sempre, ma forse non l'impostazione successiva più bassa, il processo di integrità media (a cui molte tecniche di bypass UAC funzionano).
Come per gli account degli amministratori locali o di dominio per i computer degli utenti finali, è una pratica molto scorretta, poiché gli utenti possono semplicemente fare clic con il pulsante destro su qualsiasi eseguibile e scegliere "Esegui come amministratore" per elevare i privilegi e distruggere la potenza di UAC (NB, questo può anche essere fatto tramite cmd.exe se una password dell'account amministratore separata è nota a qualsiasi utente finale). Un sacco di malware, in particolare le tecniche di persistenza, si basano sull'accesso dell'amministratore (ad es. Per l'installazione del servizio di Windows). Se UAC deve essere impostato su qualcosa di inferiore a Always Notify, la strategia migliore è anche quella di non consentire alcun accesso di amministratore (accesso privilegiato) e fornire protezioni aggiuntive contro l'installazione dell'app dell'utente finale. La mia piattaforma preferita per Privileged Identity Management è STEALTHbits e può essere combinata con BeyondTrust e altre soluzioni di gestione dei privilegi.
Come protezione aggiuntiva per gli account non amministratori, le autorizzazioni per le cartelle AppData \ LocalLow specifiche dell'utente consentono inoltre l'attivazione e la persistenza del malware. Un altro a cui prestare attenzione è che alcune organizzazioni imposteranno la chiave di registro AlwaysInstallElevated per consentire ai non amministratori di installare applicazioni. Tuttavia, i privilegi elevati di MSI possono essere violati e c'è anche un modulo metasploit-framework per farlo (es. Exploit / finestre / local / always_install_elevated).
Un'altra distinzione da fare è per i prompt di elevazione (le app possono essere scritte per richiedere automaticamente, ma il comportamento del controllo dell'account utente può sovrascrivere / annullare questa capacità). Il libro Least Privilege Security per Windows 7, Vista e XP copre questo e dice:
Microsoft recommends that in corporate environments, system administrators should configure UAC to automatically deny elevation requests using the User Account Control: Behavior of the elevation prompt for standard users local or Group Policy setting. This ensures that malware can't intercept an elevation prompt and harvest the credentials of an admin account.
Le risposte esistenti coprono la maggior parte delle cose importanti. Voglio solo aggiungere che in caso di ransomware il software non ha bisogno di privilegi elevati. Se il malware non ha i privilegi per persistere da qualche parte questo non sarebbe nemmeno un problema. Se l'utente ha accesso in scrittura a (alcuni dei) file importanti che è molto probabile, il ransomware semplicemente lo crittografa e lascia una buona nota visibile con ulteriori istruzioni.
Il vantaggio sarebbe che TUTTI i diritti sarebbero eseguiti come utente standard, non come amministratore. Gli installatori che attivano l'UAC sono lontani dalle cose più spaventose che vanno a sbattere nella notte.
Quello che stai descrivendo è ciò che vedrebbe un utente standard, non ciò che accade a livello di SO. UAC da solo non ti rende sicuro.
Leggi altre domande sui tag windows