La riduzione dei
privilegi in Windows
Marco Russo
DevLeap
http://blogs.devleap.com/marco
[email protected]
Agenda
Cosa è un utente con privilegi minimi
Perché è giusto farlo
Vivere senza essere amministratori
Prepararsi al grande salto
Gli strumenti
Sviluppare senza essere amministratori
Novità in Windows Vista
Regole di scrittura (riferimenti)
Utente con privilegi minimi
La maggior parte degli utenti usa un account di
amministratore locale della macchina
Qualsiasi operazione è consentita
Comodo per installare software e accedere a tutte le
configurazioni del sistema operativo
Rischio latente: eseguire del codice che,
volontariamente o no, abusa di questo privilegio
Utente “normale”
Si dice “con privilegi minimi” perché non può installare
nuove applicazioni e accedere a molte componenti
critiche del sistema
È un meccanismo di difesa, anche dai propri errori
prima che da attacchi esterni e/o codice maligno
Chi deve usare un utente amministratore?
Nessuno, nella pratica quotidiana
Soprattutto non per navigare su Internet e leggere mail
Ma io sono un sistemista!
Bene, quindi hai già due utenti, uno amministrativo per
le operazioni amministrative e uno personale per tutto
il resto. Vero? Bravo!
Ma io sono un programmatore!
Beh, se scrivi software su un computer attaccato a
una rete e magari anche a Internet, sei pur sempre un
utente come molti altri
Ma soprattutto, le applicazioni che scrivete sono
utilizzabili da un utente normale? Come le provate con
un utente amministratore?
Perché è giusto farlo
Perché è giusto avere un utente non
amministratore
I rischi
Azione
Programma in run automatico
Installazione e avviamento servizi
Connessione a server di rete
Installazione keylogger
Invio dati su porte TCP/IP
Installazione driver
Analisi traffico di rete (sniffing)
Controllo remoto PC
PARZ. = Vulnerabilità parziale
Admin
SI
SI
SI
SI
SI
SI
SI
SI
User
PARZ.
NO
SI
NO
SI
NO
NO
PARZ.
Privilegi minimi
Run with Least Privilege
Significa eseguire con il minimo dei privilegi
Si applica ad applicazioni Web e Windows
LPA: Least Privileged Account
Utente con privilegi minimi
Si applica a un utente che non è amministratore
In Windows, un utente che appartiene al gruppo Users di
default
Perché è giusto farlo
Un’applicazione andrebbe eseguita con il minimo
dei privilegi necessari
Limita i danni in caso di errore o attacco
Sicurezza, insomma...
Un’applicazione dovrebbe essere eseguibile con
il minimo dei privilegi necessari
Il programmatore deve pensarci
Non tutti i programmatori lo fanno
È un motivo per cui i sistemisti odiano i programmatori
Perché è giusto farlo
I vantaggi:
Conseguenze di eventuali virus: limitate
Riduce superficie di attacco
No spyware
Difficile che si installino, non hanno diritti sufficienti
Esperimento:
Un anno di navigazione con un PC senza antivirus,
senza anti-spyware e senza firewall
Ma tutti gli aggiornamenti installati tempestivamente
Dopo un anno: nessun virus, nessuno spyware
Attenzione: non è una garanzia, ma aiuta al 95%
Si resta sempre e comunque esposti a vulnerabilità 0day
Utente consapevole, non può essere considerato un utente medio
Vivere senza essere
amministratori
L’esperienza da utente
Create un logon associato al gruppo Users
No Administrators
No Power Users
Al logon scoprirete che:
Non potete installare nuove applicazioni
Non potete installare plug-in e ActiveX su Internet
Explorer
Non potete aggiornare le applicazioni esistenti
Alcune applicazioni già installate non si possono più
avviare o presentano dei problemi di funzionamento
Cos’è che non va?
Perché le applicazioni smettono di funzionare:
60% - Accesso a file/directory non autorizzato
39% - Accesso a Registry non autorizzato
<1% - Mancanza di privilegi sufficienti
Soluzioni
1.
Scrivere meglio il codice…
Ma non sempre si può
2.
Individuare i problemi e aumentare gli accessi al
minimo indispensabile (su file e registry)
Su file e registry, work around fino a nuova versione
3.
Aumentare i diritti dell’utente
Non è una soluzione, è un tornare al problema
Guida alla sopravvivenza
Il 99% dei problemi è causato da accessi non
autorizzati al File System e al Registry
Due tool indispensabili per la diagnosi:
FileMon
RegMon
Entrambi su www.sysinternals.com
Problemi di File System
Directory leggibili da Everyone e modificabili solo
da amministratori e power users:
C:\
C:\WINDOWS
C:\WINDOWS\SYSTEM32
C:\PROGRAM FILES
Spesso i programmi aprono in scrittura file in
queste directory
Anche se poi fanno solo operazioni di lettura
Comunque è un errore scrivere in queste directory,
ogni utente dovrebbe avere configurazioni separate
Problemi di Registry
Hive leggibili da Everyone e modificabili solo da
amministratori
HKEY_LOCAL_MACHINE
Spesso i programmi aprono in scrittura queste
chiavi di registry
Anche se poi fanno solo operazioni di lettura
Comunque è un errore scrivere in questa parte di
registry, ogni utente dovrebbe avere configurazioni
separate e usare HKEY_CURRENT_USER
Accessi a File e Registry
Windows Explorer
RegEdit
Perché tutti questi problemi
Molti in buona fede
Windows 9x non ha ACL (Access Control List)
Tutti gli utenti possono fare tutto (o quasi) su
disco e registry
Le applicazioni sviluppate su Windows 9x
funzionano su Windows 2000/XP/2003, ma
ignorano l’aspetto della security
Altre applicazioni non sono state mai testate da
utenti non amministratori…
Preparazione al grande salto
La vita dura dell’utente
Si può e si deve sviluppare con un utente non
amministratore
È l’unico modo per capire subito cosa succede ai
programmi sviluppati
È anche una questione psicologica: vivere sulla
propria pelle certe esperienze fa aumentare la
sensibilità al problema
È un modo più sicuro di usare un PC
Indipendentemente da firewall e antivirus
Come fare il grande salto
Caratteristiche dell’utente:
No gruppo Administrators
No gruppo Power Users
Sì gruppo Users
Per uno sviluppatore
Creare un gruppo “Developer” o “Advanced User”
Si definiranno le permission sul gruppo e non sull’utente
In caso di nuovi utenti sviluppatori sarà facile abilitarli
Associare l’utente a tale gruppo
Come fare il grande salto
Tre strade:
Cambiare il proprio utente (amministratore locale della
macchina) in un utente “normale”
Problema: ciò che è già installato resta accessibile all’utente
solo perché è owner di registry e directory
Si rischia di non percepire alcuni problemi
Creare un nuovo utente
Strada consigliabile
Si perdono i profili
Reinstallare tutto
Si perdono i profili
Si evitano “eredità” del passato
Ci vuole un sacco di tempo!!
Prepararsi psicologicamente
Perché questo avvertimento?
Tanti programmi e tante operazioni non funzioneranno
più come prima!
I primi due giorni sono i più duri
Ci saranno delle crisi…
Resistete! Potete farcela!
Dopo una settimana:
Vi sentirete meglio di prima
Avvertirete un maggiore controllo sulla macchina
Vi chiederete come avete fatto prima
Gli strumenti
RunAs
Il primo strumento da usare è RunAs
Consente di avviare un programma con le
credenziali di un altro utente
Richiede un logon a ogni esecuzione
Si può fare uno script con le password in chiaro ma…
bye bye security!
Va usato solo per le applicazioni che necessitano
realmente di un amministratore:
Configurazione di sistema
Console amministrative
FileMon, RegMon, ProcessExplorer
RunAsAdmin
Utility free
http://sourceforge.net/projects/runasadmin/
Consente di fare logon come amministratore ma
usando dei privilegi ridotti
Utile per usare utenti Amministratori in maniera
più sicura
Si può fare il RunAs dei programmi scegliendo
come modificare il token da associare al
processo
PrivBar
Utility free
http://www.speakeasy.org/~aaronmar/NonAdmin/PrivBar.zip
Visualizza il livello di privilegio con cui sono eseguiti
Explorer e Internet Explorer
RunAs, RunAsAdmin
e PrivBar
RunAs su Explorer
RunAs da Command Prompt
RunAsAdmin
PrivBar
Riparare le applicazioni scritte male
Individuare Registry e Directory di cui modificare
le ACL
Usare RegMon e FileMon
Di solito si trova un Access Denied poco prima
dell’interruzione del programma
Abbassare al minimo indispensabile i diritti delle ACL
Solo sulla directory interessata
Meglio (quando possibile) solo sul file interessato
Usare gruppo “Developer”/“Advanced User” piuttosto che il
singolo utente
FileMon
Utility free
http://www.sysinternals.com/Utilities/Filemon.html
Monitor degli accessi al file system
Intercetta tutte le chiamate di I/O
Può rallentare le operazioni, in particolare se nella
finestra si visualizza tutto senza filtri
Utile anche per analizzare il responsabile di
eccessive operazioni di I/O
RegMon
Utility free
http://www.sysinternals.com/Utilities/Regmon.html
Monitor degli accessi al registry
Intercetta tutte le chiamate alle API del Registry
Può rallentare le operazioni, in particolare se nella
finestra si visualizza tutto senza filtri
Utile anche per analizzare dove risiede la
configurazione di un programma
Talvolta non è dove dovrebbe essere
Es. configurazione per utente in HKLM\Software
Uso di FileMon e RegMon
Filtrare le operazioni ACCESS DENIED
Errore che dipende da insufficienza di privilegi
Identificazione del problema e possibili soluzioni:
Garantire l’accesso da un utente normale a
file/directory interessate
Workaround temporaneo se non è una propria applicazione
Segnalare il bug e installare poi una versione corretta
Modificare il codice di accesso alla risorsa
Se è un proprio programma – durante il debug questi problemi
emergono quasi completamente se non si è amministratori
Riparare applicazioni
scritte male…
FileMon
RegMon
Application Compatibility Toolkit
Alcune funzionalità di ACT consentono di
bypassare alcuni dei problemi più frequenti
LUA shim
Crea file system e registry virtuale in modo analogo a
quanto fa Vista
Richiede .NET 1.1 e SQL Server 2000 (o MSDE)
Sviluppare senza essere
amministratori
Indicazioni specifiche per i programmatori
Setup di Visual Studio .NET 2003
Visual Studio .NET 2003 crea alcuni gruppi a cui
uno sviluppatore deve appartenere:
VS Developers
Debugger Users
Inserire a mano gli utenti sviluppatori in questi
gruppi
Alcune attività restano agli amministratori:
Registrazione di componenti COM (regsvr32/regasm)
Installazione di assembly nella GAC (gacutil)
Installazione di componenti .NET nel catalogo COM+
(regsvcs)
Setup di Visual Studio 2005
Visual Studio 2005 usa solo un gruppo speciale:
Debugger Users
Inserire a mano gli utenti sviluppatori in tale
gruppo
Alcune attività restano agli amministratori (come
in VS.NET 2003):
Registrazione di componenti COM (regsvr32/regasm)
Installazione di assembly nella GAC (gacutil)
Installazione di componenti .NET nel catalogo COM+
(regsvcs)
Problemi di debug
Gruppo Debugger Users
A questo gruppo è assegnato il privilegio
SeDebugPrivilege
Un virus potrebbe sfruttare questo privilegio per alcuni
attacchi ai processi in esecuzione
Per le applicazioni .NET (managed) il debug al processo di un
altro utente richiede utente admin
Non è così per applicazioni Unmanaged
Problemi per chi sviluppa servizi o siti web
Workaround: in debug eseguire il servizio/sito web con
lo stesso utente con cui si fa il debug
Se debug remoto: richiesto privilegio
SeDebugPrivilege anche su macchina remota
Debug ASP.NET
Due aspetti
L’utente con cui gira l’applicazione
Usare lo stesso utente con cui si sviluppa per fare debug
I diritti sulle directory usate da ASP.NET
Abilitare i diritti su tali directory all’utente con cui gira l’applicazione
ASP.NET
Windows 2000/XP:
L’utente associato a ASPNET_WP.EXE è uno solo per tutta la macchina
Workaround: eseguire VS.NET con RunAs _solo_ limitatamente alla fase di
debug
Windows 2003:
Gli application pool di II6 aiutano nella gestione di diverse applicazioni
con credenziali differenti
Visual Studio 2005:
Si può usare “Visual Web Developer Web Server”.
Modifica utente ASP.NET
IIS 5 (fino a Windows XP)
Modificare tag processModel del file web.config
<processModel enable="true"
userName="DOMAIN\username"
password="pwd" / >
Usare ASPNET_SETREG per cifrare la password
senza lasciarla in chiaro (KB 329290)
IIS 6 (Windows 2003)
Creare un Application Pool
Assegnare utente sviluppatore all’application pool
Assegnare utente sviluppatore a gruppo IIS_WPG
Altrimenti non funziona con ASP.NET
Assegnare la Virtual Directory all’Application Pool
VB6
Brutte notizie
Non è pensato per essere utilizzato da utenti non
amministratori
Si può ovviare con le tecniche descritte prima
Usare FileMon e RegMon
Individuare punti in cui modificare le ACL
Molti problemi causati da componenti (ActiveX)
di terze parti
Anche qua si può ovviare con modifica di ACL
Problema: è un lavoro immane e si rischia di
tornare al punto di partenza (bassa security)
Novità in Windows Vista
Aumento della protezione in Windows Vista
Servizi eseguiti con Least-Privileged Account
Driver in modalità utente se non richiedono
funzioni disponibili solo nel kernel
Gestione diretta I/O, interrupt, accesso hardware,
istruzioni privilegiate della CPU
Un driver per un dispositivo collegato su USB non ne
ha bisogno
User Account Control
Gestione automatizzata del RunAs per tutti gli utenti
Windows XP
User
Admin
System
Services
Kernel
1. Pochi
layer
2. La
maggior
parte con
alti
privilegi
3. Controllo
limitato
tra I layer
Vista
Service
Hardening
User
Account
Control
(LUA)
Low rights
programs
LUA User
Low Privilege
Services
Admin
1. Maggior
numero di
layer
System
Services
Svc 6
Kernel
Service
1
D DD
D D D Service
2
Service
3
Svc 7
DD
D
User mode
drivers
2. Servizi
ripartiti
3. Ridotta la
dimension
e di layer
ad alto
rischio
Service hardening
Esecuzione con privilegi minimi (Least-privilege Account)
Riduce al minimo accesso a risorse
Riduce il potenziale danno e il numero di vulnerabilità
critiche nei servizi
Estende il modello di sicurezza esistente e fornisce
opzioni diverse in base alle caratteristiche del servizio
Good
Spostamento a un least privilege account (LPA)
Ristrutturazione del servizio in due parti dove necessario (separazione
zona critica dalle altre che possono usare LPA)
Eliminazione di privilegi Windows non necessari per singolo servizio
Fornisce regole per firewall
Better
Garantisce accesso al Sid del servizio attraverso ACL su risorse specifiche
Best
Usa SID-Servizio, ACL e “write-restricted token” per isolare i servizi
Cambiamenti ai servizi di Vista
Servizi comuni alle due piattaforme
Windows XP SP2
LocalSystem
Wireless Configuration
System Event
Notification
Network Connections
(netman)
COM+ Event System
NLA
Rasauto
Shell Hardware
Detection
Themes
Telephony
Windows Audio
Error Reporting
Workstation
ICS
Vista client
RemoteAccess
DHCP Client
W32time
Rasman
browser
6to4
Help and support
Task scheduler
TrkWks
Cryptographic Services
Removable Storage
WMI Perf Adapter
Automatic updates
WMI
App Management
Secondary Logon
BITS
Firewall Restricted
Removable Storage
WMI Perf Adapter
Automatic updates
LocalSystem
BITS
LocalSystem
Demand started
Network Service
Fully Restricted
Network Service
Network Restricted
Local Service
No Network Access
Network
Service
DNS Client
Local Service
SSDP
WebClient
TCP/IP NetBIOS helper
Remote registry
WMI
App Management
Secondary Logon
Local Service
Fully Restricted
DNS Client
ICS
RemoteAccess
DHCP Client
W32time
Rasman
browser
6to4
Task scheduler
IPSEC Services
Server
NLA
TrkWks
Cryptographic Services
Wireless Configuration
System Event Notification
Network Connections
Shell Hardware Detection
Rasauto
Themes
COM+ Event System
Telephony
Windows Audio
TCP/IP NetBIOS helper
WebClient
SSDP
Error Reporting
Event Log
Workstation
Remote registry
User Account Control (UAC)
Nome precedente: “LUA”
Utenti fanno logon come non-admin per default
Interfaccia utente per elevare privilegi ad
amministratore per operazioni specifiche
Applicazioni e tool amministrativi devono essere
“UAC area”
Differenziare le funzionalità disponibili in base ai
privilegi dell’utente
Applicare controlli di sicurezza corretti alle funzionalità
del prodotto
Approccio UAC
Migliorare la produttività garantendo le
permission solo quando necessario
Consente a utenti standard di eseguire funzionalità
chiave senza impattare sulle impostazioni globali
Aiuta a isolare i file di sistema e i dati da codice
maligno o errato
Limita i danni potenziali ai dati personali usando
Protected Mode IE
Tutte le applicazioni sono eseguite come utente
standard se non sono configurate diversamente
Isolamento a livello di processo di applicazioni
amministrative e ad alto rischio
Windows Vista UAC Goals
Tutti gli utenti sono Standard User per default

Token filtrato creato durante il logon

Solo applicazioni marcate appositamente ricevono il token non filtrato
Amministratori usano i privilegi completi solo per
operazioni e applicazioni amministrative
L’utente fornisce un consenso esplicito prima di usare
privilegi elevati
Alta compatibilità delle applicazioni

Redirezione dei dati



Consente a vecchie applicazioni di essere eseguite come utente
standard
Le impostazioni scritte su chiavi riservate del registry sono salvate in
un’immagine virtuale del Registry, visibile solo dal programma che le
ha effettuate
Rilevamento procedure installazione
UAC Architecture
Standard User Rights
Administrative Rights
Standard
User
Mode
Admin
logon
Admin
SplitPrivileges
Token
Standard User Privilege
Admin Privilege
Abby
Admin Token
“Standard User” Token
Admin Privilege
• Change Time
Zone
• Run IT Approved
Applications
• Install Fonts
• Install Printers
• Run MSN
Messenger
Admin Privilege
• Etc.
User Process
Contenuti di uno Standard User Token
Privilegi tipici di Standard User token
Bypass traverse checking (SeChangeNotify)
Shut down the system (SeShutdown)
Increase Working Set Size (SeIncreaseWorkingSet)
Remove computer from docking station (SeUndock)
Change Time Zone (SeChangeTimeZone)
Nuovo in Vista
Tutti gli altri privilegi sono rimossi
RID privilegiati impostati a DENY_ONLY
Es. Administrators, Enterprise Admins, Policy Admins,
Power User, etc. – tutti i gruppi che determinano lo
split del token
Come eseguire codice con privilegi elevati
Configurare un’applicazione che richiede privilegi
di amministratore attraverso il manifest
Individuazione installer
Application Compatibility shims (automatismo)
Tab Compatibility in Program Properties
Right-click “Run as Administrator” (Run
Elevated… in beta precedenti di Vista)
Esempi interfaccia utente
Richiesta elevazione privilegi
Interfaccia con livelli di warning diversi
Applicazione sistema operativo
Applicazione signed
Applicazione Unsigned
Conclusione
La security è un problema di tutti,
non solo di Microsoft
Chiunque scriva software è parte del problema
Ciascuno deve fare la sua parte
Per cominciare:
Scrivere applicazioni utilizzabili da utenti “normali”
Sviluppare con un utente non amministratore
Link utili
Bug di Visual Studio, KB833896,
http://support.microsoft.com/default.aspx?scid=kb;EN-US;833896
Uso di aspnet_setreg, KB329290,
http://support.microsoft.com/default.aspx?scid=kb;EN-US;329290
Developing Software in Visual Studio .NET
with Non-Administrative Privileges
http://msdn.microsoft.com/library/en-us/dv_vstechart/html/
tchDevelopingSoftwareInVisualStudioNETWithNon-AdministrativePrivileges.asp
Keith Brown - Libri e blog
http://pluralsight.com/blogs/keith/default.aspx
Why non admin – Wiki
http://nonadmin.editme.com
Using a Least-Privileged Account
http://www.microsoft.com/technet/security/secnews/articles/lpuseacc.
mspx
Link utili
Blog User Account Control in Vista
http://blogs.msdn.com/uac/
Blog Aaron Margosis
http://blogs.msdn.com/aaron_margosis/default.aspx
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
Regole di scrittura del codice
4 semplici regole
Separare dati setup e configurazione utente
Aprire solo in lettura se si deve leggere
Accedere a risorse con privilegi minimi
Memorizzare i dati per utente
Dati setup e configurazione utente
Dati setup
Informazioni sull’installazione
Directory con risorse
Impostazioni “globali” come porte TCP/IP per un servizio
Configurazione di un servizio
Scrivere durante l’installazione su:
Registry: hive HKLM (HKEY_LOCAL_MACHINE)
C:\Program Files\...
Dati setup e configurazione utente
Configurazione utente (su file)
Modelli, configurazioni su file (XML o altro):
C:\Documents and Settings\NOMEUTENTE\Application
Data\NOMEAZIENDA\NOMEAPPLICAZIONE\...
Modelli, configurazioni su file (XML o altro) per tutti gli
utenti:
C:\Documents and Settings\All Users\Application
Data\NOMEAZIENDA\NOMEAPPLICAZIONE\...
Directory in sola lettura per utenti “normali”
Ci scrivono solo i gruppi Administrators e Power Users
Per ottenere queste directory usare:
System.Environment.GetFolderPath
Vedere parametro Environment.SpecialFolder
Molti casi specifici già definiti
Dati setup e configurazione utente
Configurazione utente (su registry)
Configurazione globale (directory con dati, percorsi, impostazioni
definite in fase di Setup)
HKEY_LOCAL_MACHINE (abbreviato in HKLM)
Solo in lettura per utenti “normali”
Ci scrive soltanto il gruppo Administrators
Configurazione di partenza per tutti gli utenti:
HKEY_USERS\.DEFAULT
Contenuto copiato nel profilo di un utente al primo logon sulla
macchina, non interviene sui profili già esistenti
Solo in lettura per utenti “normali”
Ci scrive soltanto il gruppo Administrators
Configurazione specifica per ogni utente
HKEY_CURRENT_USER (abbreviato in HKCU)
Diritti completi per l’utente
Impossibile vedere la configurazione di un utente diverso (a meno
che non si sia Administrators)
Aprire in sola lettura
Il setup viene eseguito da un amministratore
Crea e modifica qualsiasi file e/o chiave di registry
Il programma viene eseguito da un utente
Dopo il setup accedere solo in lettura alle
informazioni di configurazione
Eseguire Open con richiesta diritti sola lettura
Effettuare solo operazioni Read
Errore comune:
Fare la Open con diritti di lettura e scrittura
In seguito, fare solo Read senza fare Write
Il problema è che la Open fallisce subito…
Morale: Open va READ ONLY
Accedere a risorse con privilegi minimi
Più in generale, l’accesso a una risorsa va fatto
richiedendo privilegi minimi
Aprire un file in lettura se non serve scrivere
Accedere a processi, thread e semafori senza
richiedere diritti più alti del necessario
Se si scrive un servizio o un sito web, assegnare un
utente con privilegi minimi per accedere alle risorse
necessarie al programma
Evitare LocalSystem come utente di default
Un errore (o un attacco) può essere devastante
Memorizzare i dati per utente
I dati dell’utente per default vanno su My
Documents
Environment.GetFolderPath(
Environment.SpecialFolder.Personal )
Diritti di ownership per l’utente
Ogni applicazione può vedere “tutti i dati” dell’utente
Anche per questo è importante evitare l’installazione di virus e
spyware
Dove mettere dati visibili e modificabili da tutti gli
utenti?
Memorizzare i dati per utente
Dove mettere dati visibili e modificabili da tutti gli
utenti?
Non esiste uno standard
Problema latente di sicurezza: i dati sono pubblici
Esempio: un MDB con la contabilità… non è una
buona idea renderlo accessibile a tutti
Possibile soluzione:
Individuare una directory comune e cambiare le ACL durante
il setup (una potrebbe essere
SpecialFolder.CommonApplicationData)
Resta il problema di aggiungere dei nuovi utenti in futuro:
deve farlo l’amministratore
NON LASCIARE DIRITTI A EVERYONE!!!