Condividi tramite

Esposizione a possibili violazioni

  • Articolo

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Legge numero sette: la rete più sicura è quella ben amministrata. - 10 leggi immutabili dell'amministrazione della sicurezza

Nelle organizzazioni che hanno riscontrato eventi di compromissione irreversibili, le valutazioni rivelano in genere che queste hanno una visibilità limitata sullo stato effettivo delle proprie infrastrutture IT, che può differire significativamente dal relativo stato "documentato". Queste varianze introducono vulnerabilità che espongono l'ambiente a compromissione, spesso con un rischio minimo di individuazione fino a quando la compromissione non è arrivata al punto in cui gli utenti malintenzionati sono effettivamente "proprietari" dell'ambiente.

Valutazioni dettagliate della configurazione di Active Directory Domain Services, delle infrastrutture a chiave pubblica (PKI), dei server, delle workstation, delle applicazioni, degli elenchi di controllo di accesso (ACL) e di altre tecnologie rivelano configurazioni errate e vulnerabilità che, se risolte, avrebbero potuto impedire la compromissione iniziale.

L'analisi della documentazione, dei processi e delle procedure IT identifica le vulnerabilità introdotte da lacune nelle procedure amministrative che sono state sfruttate dagli utenti malintenzionati per ottenere infine privilegi usati per compromettere completamente la foresta Active Directory. Una foresta completamente compromessa è una foresta in cui gli utenti malintenzionati compromettono non solo i singoli sistemi, le applicazioni o gli account utente, ma ampliano l'accesso per ottenere un livello di privilegio in cui possono modificare o distruggere tutti gli aspetti della foresta. Quando un'installazione di Active Directory è stata compromessa in questo modo, gli utenti malintenzionati possono apportare modifiche che consentono loro di mantenere una presenza in tutto l'ambiente, o peggio, di distruggere la directory e i sistemi e gli account gestiti.

Anche se alcune delle vulnerabilità comunemente sfruttate nelle descrizioni che seguono non sono attacchi contro Active Directory, consentono agli utenti malintenzionati di stabilire un punto di accesso in un ambiente che può essere usato per eseguire attacchi di escalation dei privilegi (denominati anche elevazione dei privilegi) e per raggiungere e compromettere AD DS.

Questa sezione di questo documento descrive i meccanismi che gli utenti malintenzionati usano in genere per ottenere l'accesso all'infrastruttura e infine per avviare attacchi di elevazione dei privilegi. Vedere anche le sezioni seguenti:

Nota

Anche se questo documento è incentrato sui sistemi Active Directory e Windows che fanno parte di un dominio di Active Directory Domain Services, gli utenti malintenzionati raramente si concentrano esclusivamente su Active Directory e Windows. Negli ambienti con una combinazione di sistemi operativi, directory, applicazioni e repository di dati, è comune rilevare che anche i sistemi non Windows siano stati compromessi. Ciò è particolarmente vero se i sistemi forniscono un "ponte" tra ambienti Windows e non Windows, ad esempio file server a cui si accede da client Windows e UNIX o Linux, directory che forniscono servizi di autenticazione a più sistemi operativi o metadirectory che sincronizzano i dati tra directory diverse.

Active Directory Domain Services viene preso di mira a causa delle funzionalità centralizzate di gestione dell'accesso e della configurazione offerte non solo ai sistemi Windows, ma anche ad altri client. Qualsiasi altra directory o applicazione che fornisca servizi di gestione dell'autenticazione e della configurazione potrebbe essere presa di mira da determinati utenti malintenzionati. Anche se questo documento è incentrato sulle protezioni che possono ridurre la probabilità di compromissione delle installazioni di Active Directory, anche le organizzazioni che includono computer, directory, applicazioni o repository di dati non Windows devono prepararsi agli attacchi contro tali sistemi.

Obiettivi iniziali di violazione

Nessuno crea intenzionalmente un'infrastruttura IT che espone l'organizzazione a compromissione. Quando una foresta Active Directory viene costruita per la prima volta, è in genere intatta e corrente. Man mano che passano anni e vengono acquisiti nuovi sistemi operativi e applicazioni, questi vengono aggiunti alla foresta. Man mano che vengono riconosciuti i vantaggi della gestibilità offerti da Active Directory, alla directory vengono aggiunti sempre più contenuti, più persone integrano i computer o le applicazioni con Active Directory Domain Services e i domini vengono aggiornati per supportare nuove funzionalità offerte dalle versioni più recenti del sistema operativo Windows. Ciò che accade anche nel tempo, tuttavia, è che anche quando viene aggiunta una nuova infrastruttura, altre parti dell'infrastruttura potrebbero non essere mantenute così come erano inizialmente, i sistemi e le applicazioni funzionano correttamente e quindi non ricevono attenzione e le organizzazioni iniziano a dimenticare di non aver eliminato l'infrastruttura legacy. In base a ciò che vediamo nella valutazione delle infrastrutture compromesse, più l'ambiente è vecchio, grande e complesso e più è probabile che ci siano numerose istanze di vulnerabilità comunemente sfruttate.

Indipendentemente dalla motivazione dell'utente malintenzionato, la maggior parte delle violazioni della sicurezza delle informazioni inizia con la compromissione di uno o due sistemi alla volta. Questi eventi iniziali, o punti di ingresso nella rete, spesso sfruttano le vulnerabilità che potrebbero essere state risolte, ma che al momento non lo sono. Il Report sulle indagini sulle violazioni dei dati (DBIR) del 2012, che è uno studio annuale prodotto dal team che si occupa dei rischi presso Verizon in collaborazione con una serie di agenzie di sicurezza nazionali e altre aziende, afferma che il 96% degli attacchi era "non molto difficile" e che "il 97% delle violazioni era evitabile tramite controlli semplici o intermedi". Questi risultati possono essere una conseguenza diretta delle vulnerabilità comunemente sfruttate che seguono.

Lacune nelle distribuzioni antivirus e antimalware

Legge numero otto: uno scanner di malware non aggiornato è solo marginalmente migliore rispetto a non avere nessuno scanner. - 10 leggi immutabili della sicurezza (versione 2.0)

L'analisi delle distribuzioni antivirus e antimalware delle organizzazioni spesso rivela un ambiente in cui la maggior parte delle workstation è configurata con software antivirus e antimalware abilitati e aggiornati. Le eccezioni sono in genere workstation che si connettono raramente all'ambiente aziendale, oppure dispositivi dei dipendenti per cui i software antivirus e antimalware possono essere difficili da distribuire, configurare e aggiornare.

I popolamenti dei server, tuttavia, tendono a essere meno costantemente protetti in molti ambienti compromessi. Come segnalato nelle indagini sulle violazioni dei dati del 2012, il 94% di tutti i dati compromessi riguardava i server, rappresentando un aumento del 18% rispetto all'anno precedente, e il 69% degli attacchi incorporava malware. Nei popolamenti di server, non è insolito scoprire che le installazioni antivirus e antimalware siano configurate in modo incoerente, obsoleto, errato o siano perfino disabilitate. In alcuni casi, i software antivirus e antimalware sono disabilitati dal personale amministrativo, ma in altri casi gli utenti malintenzionati disabilitano il software dopo aver compromesso un server tramite altre vulnerabilità. Quando il software antivirus e antimalware è disabilitato, gli utenti malintenzionati piantano quindi malware sul server e si concentrano sulla propagazione della compromissione nella popolazione del server.

È importante non solo assicurarsi che i sistemi siano protetti con la protezione antimalware corrente e completa, ma anche monitorare i sistemi per verificare eventuali disabilitazioni o rimozioni di software antivirus e antimalware e riavviare automaticamente la protezione quando siano disabilitati manualmente. Anche se nessun software antivirus o antimalware può garantire la prevenzione e il rilevamento di tutte le infezioni, un'implementazione antivirus e antimalware configurata e distribuita correttamente può ridurre la probabilità di infezione.

Patch incomplete

Legge numero tre: se non si tiene il passo con le correzioni di sicurezza, la rete non sarà più propria per molto tempo. - 10 leggi immutabili dell'amministrazione della sicurezza

Microsoft rilascia i bollettini sulla sicurezza il secondo martedì di ogni mese, anche se in rari casi gli aggiornamenti sulla sicurezza vengono rilasciati tra gli aggiornamenti sulla sicurezza mensili (noti anche come aggiornamenti “fuori programma”) quando la vulnerabilità è destinata a rappresentare un rischio urgente per i sistemi dei clienti. Indipendentemente dal fatto che un'azienda di piccole dimensioni configuri i computer Windows per l'uso di Windows Update per gestire patch di sistema e applicazioni o che un'organizzazione di grandi dimensioni usi software di gestione come Microsoft Endpoint Configuration Manager per distribuire patch in base a piani gerarchici dettagliati, molti clienti applicano patch alle infrastrutture Windows in modo relativamente tempestivo.

Tuttavia, alcune infrastrutture includono solo computer Windows e applicazioni Microsoft e, in ambienti compromessi, è comune scoprire che la strategia di gestione delle patch dell'organizzazione contenga lacune. I sistemi Windows in questi ambienti presentano patch incoerenti. Ai sistemi operativi non Windows vengono applicate patch sporadicamente, o affatto. Le applicazioni commerciali (COTS) contengono vulnerabilità per le quali esistono patch, ma non sono state applicate. I dispositivi di rete vengono spesso configurati con credenziali predefinite e senza aggiornamenti del firmware anni dopo l'installazione. Le applicazioni e i sistemi operativi che non sono più supportati dai fornitori vengono spesso mantenuti in esecuzione, nonostante il fatto che non possano più essere applicate patch contro le vulnerabilità. Ognuno di questi sistemi senza patch rappresenta un altro potenziale punto di ingresso per gli utenti malintenzionati.

La gestione a livello consumer dell'IT ha introdotto ulteriori sfide in quanto i dispositivi di proprietà dei dipendenti vengono usati per accedere ai dati di proprietà dell'azienda e l'organizzazione potrebbe non avere alcun controllo sull'applicazione di patch e sulla configurazione dei dispositivi personali dei dipendenti. L'hardware di classe Enterprise viene in genere fornito con opzioni di configurazione e funzionalità di gestione pronte per l'organizzazione, a un costo di una minore scelta nella personalizzazione e nella selezione dei dispositivi. L'hardware incentrato sui dipendenti offre un'ampia gamma di produttori, fornitori, funzionalità di sicurezza hardware, funzionalità di sicurezza software, funzionalità di gestione e opzioni di configurazione e molte funzionalità aziendali potrebbero essere del tutto assenti.

Software di gestione delle vulnerabilità e delle patch

Se è disponibile un sistema di gestione delle patch efficace per i sistemi Windows e le applicazioni Microsoft, parte della superficie di attacco creata da vulnerabilità senza patch è stata risolta. Tuttavia, a meno che i sistemi non Windows, le applicazioni non Microsoft, l'infrastruttura di rete e i dispositivi dei dipendenti non vengano mantenuti aggiornati anche sulle patch e su altre correzioni, l'infrastruttura rimane vulnerabile. In alcuni casi, il fornitore di un'applicazione può offrire funzionalità di aggiornamento automatico; in altri, potrebbe essere necessario definire un approccio per recuperare e applicare regolarmente patch e altre correzioni.

Applicazioni e sistemi operativi obsoleti

"Non ci si può aspettare che un sistema operativo di sei anni possa proteggere da un attacco di sei mesi." - Professionista nel campo della sicurezza delle informazioni con 10 anni di esperienza nella protezione delle installazioni aziendali

Anche se "aggiornarsi e rimanere aggiornati" può sembrare una frase di marketing, le applicazioni e i sistemi operativi obsoleti creano rischi in molte infrastrutture IT delle organizzazioni. Un sistema operativo rilasciato nel 2003 potrebbe essere ancora supportato dal fornitore e dotato di aggiornamenti per risolvere le vulnerabilità, ma il sistema operativo potrebbe non contenere funzionalità di sicurezza aggiunte nelle versioni più recenti del sistema operativo. I sistemi obsoleti possono anche richiedere l'indebolimento di una determinata configurazione di sicurezza di Active Directory Domain Services per supportare le funzionalità minori di tali computer.

Le applicazioni scritte per l'uso di protocolli di autenticazione legacy da parte di fornitori che non supportano più l'applicazione in genere non possono essere riorganizzate per supportare meccanismi di autenticazione più avanzati. Tuttavia, il dominio di Active Directory di un'organizzazione può comunque essere configurato per archiviare hash LAN Manager o password crittografate reversibili per supportare tali applicazioni. Le applicazioni scritte prima dell'introduzione di sistemi operativi più recenti potrebbero non funzionare correttamente o non funzionare affatto in alcuni sistemi operativi correnti, richiedendo alle organizzazioni di mantenere sistemi meno recenti e, in alcuni casi, hardware e software completamente non supportati.

Anche nei casi in cui le organizzazioni hanno aggiornato i controller di dominio a Windows Server 2012, Windows Server 2008 R2 o Windows Server 2008, è tipico trovare parti significative del popolamento del server membro che eseguono Windows Server 2003, Windows 2000 Server o Windows NT Server 4.0 (che non sono affatto supportate). Più un'organizzazione gestisce sistemi precedenti, maggiore sono la disparità tra i set di funzionalità e la probabilità che i sistemi di produzione non siano supportati. Inoltre, più viene mantenuta una foresta Active Directory, più si osserva che nei piani di aggiornamento non vengono rilevati sistemi e applicazioni legacy. Ciò può significare che un singolo computer che esegue una singola applicazione può introdurre vulnerabilità a livello di dominio o di foresta perché Active Directory è configurato per supportare i protocolli legacy e i meccanismi di autenticazione.

Per eliminare i sistemi e le applicazioni legacy, è necessario concentrarsi prima di tutto sull'identificazione e la catalogazione, quindi sulla determinazione dell'aggiornamento o della sostituzione dell'applicazione o dell'host. Anche se può essere difficile trovare sostituzioni per applicazioni altamente specializzate per le quali non sono disponibili supporti né percorsi di aggiornamento, è possibile sfruttare un concetto denominato "distruzione creativa" per sostituire l'applicazione legacy con una nuova applicazione che fornisce le funzionalità necessarie. La pianificazione del compromesso è descritta in modo più approfondito in "Pianificazione del compromesso" più avanti in questo documento.

Errore di configurazione

Legge numero quattro: non è molto indicato installare correzioni di sicurezza in un computer che non è mai stato protetto sin dall'inizio. - 10 leggi immutabili dell'amministrazione della sicurezza

Anche negli ambienti in cui i sistemi vengono in genere mantenuti aggiornati e con patch, vengono comunemente identificate lacune o configurazioni errate nel sistema operativo, nelle applicazioni in esecuzione nei computer e in Active Directory. Alcune configurazioni errate espongono solo il computer locale a compromissione, ma dopo che un computer diventa “di proprietà”, gli utenti malintenzionati si concentrano in genere sulla propagazione ulteriore della compromissione in altri sistemi e alla fine in Active Directory. Di seguito sono riportate alcune delle aree comuni in cui vengono identificate le configurazioni che introducono rischi.

In Active Directory

Gli account in Active Directory più comunemente interessati dagli utenti malintenzionati sono quelli che sono membri dei gruppi con privilegi più elevati, ad esempio i membri dei gruppi Domain Admins (DA), Enterprise Admins (EA) o amministratori predefiniti in Active Directory. L'appartenenza a questi gruppi dovrebbe essere ridotta al minor numero di account possibile, in modo che la superficie di attacco di questi gruppi sia limitata. È anche possibile eliminare l'appartenenza "permanente" a questi gruppi con privilegi; ciò significa che è possibile implementare le impostazioni che consentono di popolare temporaneamente questi gruppi solo quando sono necessari i privilegi a livello di dominio e foresta. Quando vengono usati account con privilegi elevati, questi devono essere usati solo in sistemi designati e sicuri, come ad esempio controller di dominio o host amministrativi sicuri. Informazioni dettagliate per implementare tutte queste configurazioni sono disponibili in Riduzione della superficie di attacco di Active Directory.

Quando si valuta l'appartenenza ai gruppi con privilegi più elevati in Active Directory, si rileva in genere un numero eccessivo di appartenenze a tutti e tre i gruppi con privilegi più elevati. In alcuni casi, le organizzazioni hanno decine, se non centinaia di account nei gruppi DA. In altri casi, le organizzazioni inseriscono gli account direttamente nei gruppi Administrators predefiniti, pensando che il gruppo abbia "meno privilegi" rispetto al gruppo DA. Non è così. Spesso si trovano alcuni membri permanenti del gruppo EA nel dominio radice della foresta, nonostante il fatto che i privilegi EA siano raramente e temporaneamente necessari. Anche la ricerca di un account amministrativo quotidiano di un utente IT in tutti e tre i gruppi è comune, anche se si tratta di una configurazione effettivamente ridondante. Come descritto in Riduzione della superficie di attacco di Active Directory, sia che un account sia un membro permanente di uno di questi gruppi che di tutti, l'account può essere usato per compromettere e persino distruggere l'ambiente di Active Directory Domain Services e i sistemi e gli account gestiti da esso. Le raccomandazioni per la configurazione sicura e l'uso degli account con privilegi in Active Directory sono disponibili in Riduzione della superficie di attacco di Active Directory.

Controller di dominio

Quando si valutano i controller di dominio, spesso si riscontra che vengono configurati e gestiti in modo diverso rispetto ai server membri. I controller di dominio talvolta eseguono le stesse applicazioni e utilità installate nei server membri, non perché sono necessarie nei controller di dominio, ma perché le applicazioni fanno parte di una build standard. Queste applicazioni possono fornire funzionalità minime nei controller di dominio, ma aggiungere molto alla superficie di attacco richiedendo l'impostazione di configurazioni che aprono le porte, creano account del servizio con privilegi elevati o concedono l'accesso al sistema da parte degli utenti che non dovrebbero connettersi a un controller di dominio per scopi diversi dall'autenticazione e dall'applicazione Criteri di gruppo. In alcune violazioni, gli utenti malintenzionati hanno usato strumenti già installati nei controller di dominio non solo per ottenere l'accesso ai controller di dominio, ma anche per modificare o danneggiare il database di Active Directory Domain Services.

Quando si estraggono le impostazioni di configurazione di Internet Explorer nei controller di dominio, si scopre che gli utenti hanno eseguito l'accesso con account con privilegi elevati in Active Directory e hanno usato gli account per accedere a Internet e intranet dai controller di dominio. In alcuni casi, gli account hanno configurato le impostazioni di Internet Explorer nei controller di dominio per consentire il download del contenuto Internet e le utilità freeware sono state scaricate dai siti Internet e installate nei controller di dominio. Internet Explorer Enhanced Security Configuration è abilitato per utenti e amministratori per impostazione predefinita, ma spesso si osserva che è stato disabilitato per gli amministratori. Quando un account con privilegi elevati accede a Internet e scarica il contenuto in qualsiasi computer, tale computer viene messo a grave rischio. Quando il computer è un controller di dominio, l'intera installazione di Servizi di dominio Active Directory viene messa a rischio.

Protezione dei controller di dominio

I controller di dominio devono essere considerati componenti dell'infrastruttura fondamentali, protetti in modo più rigoroso e configurati più rigidamente rispetto ai server file, stampa e applicazioni. I controller di dominio non devono eseguire software non necessari per il funzionamento del controller di dominio o che non proteggano il controller di dominio da attacchi. I controller di dominio non devono essere autorizzati ad accedere a Internet e le impostazioni di sicurezza devono essere configurate e applicate dagli oggetti Criteri di gruppo. Le raccomandazioni dettagliate per l'installazione sicura, la configurazione e la gestione dei controller di dominio sono disponibili in Protezione dei controller di dominio dagli attacchi.

All'interno del sistema operativo

Legge numero due: se un malintenzionato può modificare il sistema operativo sul tuo computer, quel computer non è più tuo. - 10 leggi immutabili della sicurezza (versione 2.0)

Sebbene alcune organizzazioni creino configurazioni iniziali per server di tipi diversi e consentano una personalizzazione limitata del sistema operativo dopo l'installazione, l'analisi degli ambienti compromessi spesso rileva un numero elevato di server distribuiti in modo ad hoc e configurati manualmente e in modo indipendente. Le configurazioni tra due server che eseguono la stessa funzione possono essere completamente diverse, ma nessuno dei due server è configurato in modo sicuro. Al contrario, le linee di base di configurazione del server possono essere applicate in modo coerente, ma anche configurate in modo non corretto; ovvero, i server vengono configurati in modo da creare la stessa vulnerabilità in tutti i server di un determinato tipo. La configurazione errata include procedure come la disabilitazione delle funzionalità di sicurezza, la concessione di diritti e autorizzazioni eccessivi agli account (in particolare agli account del servizio), l'uso di credenziali locali identiche su più sistemi e l'installazione di applicazioni e utilità non autorizzate che creano vulnerabilità proprie.

Disabilitazione delle funzionalità di sicurezza

Le organizzazioni talvolta disabilitano Windows Firewall con sicurezza avanzata (WFAS) perché credono che WFAS sia difficile da configurare o che la configurazione richieda molto lavoro. Tuttavia, a partire da Windows Server 2008, quando un ruolo o una funzionalità sono installati in un server, questi vengono configurati per impostazione predefinita con i privilegi minimi necessari per il ruolo o la funzionalità e Windows Firewall viene configurato automaticamente per supportare il ruolo o la funzionalità. Disabilitando WFAS (e non usando un altro firewall basato su host), le organizzazioni aumentano la superficie di attacco dell'intero ambiente Windows. I firewall perimetrali forniscono una certa protezione contro gli attacchi rivolti direttamente a un ambiente da Internet, ma non forniscono alcuna protezione contro gli attacchi che sfruttano altri vettori di attacco, ad esempio attacchi drive-by download o attacchi che provengono da altri sistemi compromessi nella Intranet.

Le impostazioni di Controllo dell'account utente (UAC) vengono talvolta disabilitate nei server perché il personale amministrativo trova le richieste intrusive. Anche se l'articolo del supporto tecnico Microsoft 2526083 descrive gli scenari in cui il controllo dell'account utente può essere disabilitato in Windows Server, a meno che non si esegua un'installazione di base del server (in cui il controllo dell'account utente è disabilitato per impostazione predefinita), non è consigliabile disabilitare il controllo dell'account utente nei server senza prestare attenzione ed eseguire le opportune ricerche.

In altri casi, le impostazioni del server sono configurate in valori meno sicuri perché le organizzazioni applicano impostazioni di configurazione server obsolete ai nuovi sistemi operativi, ad esempio l'applicazione delle baseline di Windows Server 2003 ai computer che eseguono Windows Server 2012, Windows Server 2008 R2 o Windows Server 2008, senza modificare le baseline per riflettere le modifiche nel sistema operativo. Anziché trasportare le baseline del server precedente nei nuovi sistemi operativi, quando si distribuisce un nuovo sistema operativo, esaminare le modifiche di sicurezza e le impostazioni di configurazione per assicurarsi che le impostazioni implementate siano applicabili e appropriate per il nuovo sistema operativo.

Concessione di privilegi eccessivi

In quasi tutti gli ambienti valutati, viene concesso un privilegio eccessivo agli account locali e basati su dominio nei sistemi Windows. Agli utenti vengono concessi diritti di amministratore locale sulle workstation, i server membri eseguono servizi configurati con diritti che vanno oltre ciò per cui devono funzionare e i gruppi Administrators locali nella popolazione del server contengono decine o persino centinaia di account locali e di dominio. La compromissione di un solo account con privilegi in un computer consente agli utenti malintenzionati di compromettere gli account di ogni utente e servizio che accede al computer e di raccogliere e sfruttare le credenziali per propagare la compromissione ad altri sistemi.

Anche se gli attacchi pass-the-hash (PTH) e altri attacchi di furto di credenziali sono oggi onnipresenti, ciò avviene perché sono disponibili gratuitamente strumenti che semplificano l'estrazione delle credenziali di altri account con privilegi quando un utente malintenzionato ha ottenuto l'accesso a livello di amministratore o sistema a un computer. Anche senza strumenti che consentono la raccolta di credenziali dalle sessioni di accesso, un utente malintenzionato con accesso con privilegi a un computer può installare facilmente i logger di sequenze di tasti che acquisiscono sequenze di tasti, screenshot e contenuti degli appunti. Un utente malintenzionato con accesso con privilegi a un computer può disabilitare il software antimalware, installare i rootkit, modificare i file protetti o installare malware nel computer che automatizza gli attacchi o trasforma un server in un host di download drive-by.

Le tattiche usate per estendere una violazione oltre un singolo computer variano, ma la chiave per propagare il compromesso è l'acquisizione di accesso con privilegi elevati ad altri sistemi. Riducendo il numero di account con accesso con privilegi a qualsiasi sistema, si riduce la superficie di attacco non solo del computer, ma anche la probabilità che un utente malintenzionato raccolga dal computer credenziali preziose.

Standardizzazione delle credenziali di amministratore locale

Da molto tempo gli specialisti della sicurezza discutono per stabilire se abbia senso ridenominare gli account amministratore locali nei computer Windows. Ciò che in realtà è importante sugli account amministratore locale è se sono configurati con lo stesso nome utente e la stessa password in più computer.

Se l'account amministratore locale è denominato con lo stesso valore su più server e anche la password assegnata all'account è configurata con lo stesso valore, gli utenti malintenzionati possono estrarre le credenziali dell'account in un computer in cui è stato ottenuto l'accesso a livello di amministratore o sistema. L'utente malintenzionato non deve inizialmente compromettere l'account amministratore; deve compromettere solo l'account di un utente membro del gruppo Administrators locale o di un account del servizio configurato per l'esecuzione come LocalSystem o con privilegi di amministratore. L'utente malintenzionato può quindi estrarre le credenziali per l'account amministratore e riprodurre tali credenziali negli accessi di rete ad altri computer della rete.

Se un altro computer dispone di un account locale con lo stesso nome utente e la stessa password (o hash della password) delle credenziali dell'account che vengono presentate, il tentativo di accesso ha esito positivo e l'utente malintenzionato ottiene l'accesso con privilegi al computer di destinazione. Nelle versioni correnti di Windows, l'account amministratore predefinito è disabilitato per impostazione predefinita, ma nei sistemi operativi legacy l'account è abilitato per impostazione predefinita.

Nota

Alcune organizzazioni hanno intenzionalmente configurato gli account di amministratore locale in modo tale che siano abilitati nella convinzione che ciò fornisca un "piano B" nel caso in cui tutti gli altri account con privilegi siano bloccati da un sistema. Tuttavia, anche se l'account amministratore locale è disabilitato e non sono disponibili altri account che possono abilitare l'account o accedere al sistema con privilegi di amministratore, il sistema può essere avviato in modalità provvisoria e l'account amministratore locale predefinito può essere riabilitato, come descritto nell'articolo 814777 del supporto tecnico Microsoft. Inoltre, se il sistema applica ancora correttamente oggetti Criteri di gruppo, un oggetto Criteri di gruppo può essere modificato in modo da riabilitare (temporaneamente) l'account amministratore, o i gruppi con restrizioni possono essere configurati per aggiungere un account basato su dominio al gruppo Administrators locale. Le riparazioni possono essere eseguite e l'account amministratore può essere disabilitato di nuovo. Per evitare in modo efficace una compromissione laterale che usa le credenziali predefinite dell'account amministratore locale, è necessario configurare nomi utente e password univoci per gli account amministratore locale. Per distribuire password univoche per gli account amministratore locale tramite un oggetto Criteri di gruppo, vedere Soluzione per la gestione della password dell'account Administrator predefinito tramite l'oggetto Criteri di gruppo in TechNet.  

Autorizzazione all'installazione di applicazioni non autorizzate

Legge numero uno: Se un malintenzionato convince a eseguire il suo programma sul proprio computer, il computer non è più proprio. - 10 leggi immutabili della sicurezza (versione 2.0)

Se un'organizzazione distribuisce impostazioni iniziali coerenti su più server, l'installazione di applicazioni che non fanno parte del ruolo definito di un server non deve essere consentita. Consentendo l'installazione di software che non fanno parte della funzionalità designata di un server, i server vengono esposti all'installazione accidentale o dannosa di software che aumenta la superficie di attacco del server, introduce vulnerabilità dell'applicazione o causa l'instabilità del sistema.

Applicazioni

Come descritto in precedenza, le applicazioni vengono spesso installate e configurate per l'uso di account a cui vengono concessi più privilegi rispetto a quelli effettivamente richiesti dall'applicazione. In alcuni casi, la documentazione dell'applicazione specifica che gli account del servizio devono essere membri del gruppo Administrators locale di un server o devono essere configurati per l'esecuzione nel contesto di LocalSystem. Ciò spesso non è dovuto al fatto che l'applicazione richiede tali diritti, ma al fatto che la determinazione delle autorizzazioni e dei diritti necessari per gli account di servizio di un'applicazione richiede più tempo e lavoro. Se un'applicazione non viene installata con i privilegi minimi necessari per il funzionamento dell'applicazione e le relative funzionalità configurate, il sistema viene esposto agli attacchi che sfruttano i privilegi dell'applicazione senza alcun attacco contro il sistema operativo stesso.

Mancanza di procedure di sviluppo di applicazioni sicure

L'infrastruttura esiste per supportare i carichi di lavoro aziendali. Quando questi carichi di lavoro vengono implementati nelle applicazioni personalizzate, è fondamentale assicurarsi che le applicazioni vengano sviluppate usando procedure consigliate sicure. L'analisi della causa radice degli eventi imprevisti a livello aziendale spesso rivela che una compromissione iniziale viene applicata tramite applicazioni personalizzate, in particolare quelle con connessione Internet. La maggior parte di questi compromessi viene eseguita tramite compromissione di attacchi noti, ad esempio SQL injection (SQLi) e scripting intersito (XSS).

SQL Injection è una vulnerabilità dell'applicazione che consente all'input definito dall'utente di modificare un'istruzione SQL passata al database per l'esecuzione. Questo input può essere fornito tramite un campo nell'applicazione, un parametro (ad esempio la stringa di query o un cookie) o altri metodi. Il risultato di questo inserimento è che l'istruzione SQL fornita al database è fondamentalmente diversa da quella prevista dallo sviluppatore. Si supponga, ad esempio, una query comune usata nella valutazione di una combinazione di nome utente/password:

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

Quando viene ricevuta dal server di database, questa indica al server di esaminare la tabella degli utenti e restituire qualsiasi record userID in cui il nome utente e la password corrispondono a quelli forniti dall'utente (presumibilmente tramite un modulo di accesso di un certo tipo). Naturalmente lo scopo dello sviluppatore in questo caso è restituire un record valido solo se nome utente e password corretti possono essere forniti dall'utente. Se uno dei due non è corretto, il server di database non sarà in grado di trovare un record corrispondente e restituirà un risultato vuoto.

Il problema si verifica quando un utente malintenzionato esegue un'operazione imprevista, ad esempio fornendo il proprio SQL al posto di dati validi. Poiché SQL viene interpretato in tempo reale dal server di database, il codice inserito verrebbe elaborato come se lo sviluppatore lo avesse inserito. Ad esempio, se l'utente malintenzionato ha immesso l'amministratore per l'ID utente e xyz O 1=1 come password, l'istruzione risultante elaborata dal database sarà:

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

Quando questa query viene elaborata dal server di database, tutte le righe della tabella verranno restituite nella query perché 1=1 restituirà sempre True, pertanto non importa se il nome utente e la password corretti siano noti o specificati. Il risultato netto nella maggior parte dei casi è che l'utente verrà connesso come primo utente nel database dell'utente; nella maggior parte dei casi, si tratta dell'utente amministratore.

Oltre a eseguire semplicemente l'accesso, le istruzioni SQL in formato non valido, come questa, possono essere usate per aggiungere, eliminare o modificare i dati oppure rimuovere (eliminare) intere tabelle da un database. Nei casi più estremi in cui SQLi è usato insieme a privilegi eccessivi, i comandi del sistema operativo possono essere eseguiti per consentire la creazione di nuovi utenti, scaricare gli strumenti di attacco o eseguire qualsiasi altra azione degli utenti malintenzionati scelti.

Nello scripting tra siti, la vulnerabilità viene introdotta nell'output dell'applicazione. Un attacco inizia da un utente malintenzionato che fornisce dati in formato non valido all'applicazione, ma in questo caso i dati in formato non valido sono sotto forma di codice di scripting (ad esempio JavaScript) che verrà eseguito dal browser della vittima. Lo sfruttamento di una vulnerabilità XSS può consentire a un utente malintenzionato di eseguire qualsiasi funzione dell'applicazione di destinazione nel contesto dell'utente che ha avviato il browser. Gli attacchi XSS vengono in genere avviati da un messaggio di posta elettronica di phishing che incoraggia l'utente a cliccare su un collegamento che si connette all'applicazione ed esegue il codice di attacco.

XSS viene spesso sfruttato in scenari di online banking ed e-commerce in cui un utente malintenzionato può effettuare acquisti o trasferire denaro nel contesto dell'utente sfruttato. Nel caso di un attacco mirato su un'applicazione di gestione delle identità personalizzata basata sul Web, questo può consentire a un utente malintenzionato di creare le proprie identità, modificare autorizzazioni e diritti e causare una compromissione sistemica.

Anche se la descrizione completa dello scripting intersito e di SQL injection non rientra nell'ambito di questo documento, Open Web Application Security Project (OWASP) pubblica un elenco delle prime 10 discussioni approfondite sulle vulnerabilità e sulle contromisure.

Indipendentemente dall'investimento nella sicurezza dell'infrastruttura, se le applicazioni scritte e progettate in modo non adeguato vengono distribuite all'interno di tale infrastruttura, l'ambiente viene reso vulnerabile agli attacchi. Anche le infrastrutture ben protette spesso non possono fornire contromisure efficaci per questi attacchi all'applicazione. Per complicare il problema, le applicazioni progettate in modo non appropriato possono richiedere che agli account di servizio vengano concesse autorizzazioni eccessive per il funzionamento dell'applicazione.

Security Development Lifecycle (SDL) di Microsoft è un set di controlli strutturali sui processi che agisce per migliorare la sicurezza all'inizio della raccolta dei requisiti e l'estensione del ciclo di vita dell'applicazione fino a quando non viene rimossa. Questa integrazione di controlli di sicurezza efficaci non è fondamentale solo dal punto di vista della sicurezza, ma anche per garantire che la sicurezza delle applicazioni sia conveniente e pianificata. La valutazione di un'applicazione per rilevare eventuali problemi di sicurezza quando il codice è effettivamente completo richiede alle organizzazioni di prendere decisioni sulla sicurezza delle applicazioni solo prima o anche dopo la distribuzione dell'applicazione. Un'organizzazione può scegliere di risolvere i difetti dell'applicazione prima di distribuirla in produzione, incorrendo in costi e ritardi, oppure l'applicazione può essere distribuita in produzione con difetti di sicurezza noti, esponendo l'organizzazione a compromissioni.

Alcune organizzazioni applicano il costo completo per la correzione di un problema di sicurezza nel codice di produzione superiore a $ 10.000 per problema e le applicazioni sviluppate senza un SDL efficace possono avere una media di oltre dieci problemi di gravità elevata per 100.000 righe di codice. Nelle applicazioni di grandi dimensioni, i costi aumentano rapidamente. Al contrario, molte aziende impostano un benchmark di meno di un problema per 100.000 righe di codice nella fase finale di revisione del codice di SDL e puntano a non avere alcun problema nelle applicazioni ad alto rischio nell'ambiente di produzione.

L'implementazione di SDL migliora la sicurezza includendo i requisiti di sicurezza nelle fasi iniziali della raccolta e la progettazione di un'applicazione fornisce il modello delle minacce per le applicazioni ad alto rischio; richiede una formazione e un monitoraggio efficaci degli sviluppatori; e richiede standard e procedure di codice chiari e coerenti. L'effetto netto di SDL è un miglioramento significativo della sicurezza delle applicazioni, riducendo al contempo i costi per sviluppare, distribuire, gestire e rimuovere le autorizzazioni di un'applicazione. Sebbene una descrizione dettagliata della progettazione e dell'implementazione di SDL esula dall'ambito di questo documento, fare riferimento a Microsoft Security Development Lifecycle per ricevere indicazioni e informazioni dettagliate.