Nota: questo articolo è stato pubblicato per la prima volta nel numero di luglio 2021 della newsletter mensile Network Security e viene qui riportato con l'autorizzazione dell'editore.qui con l'autorizzazione dell'editore.
Tornare indietro di 21 anni fino all'inizio del millennio sarebbe
un'esperienza strana, visto il mondo in cui viviamo oggi. Anche mettendo da parte la pandemia di Covid-19
e le sue conseguenze ancora da definire, negli ultimi due decenni la vita è cambiata
moltissimo.
Nel 2000, Spotify, Facebook, Instagram e Uber non esistevano ancora, mentre Netflix (ricordate il noleggio di DVD e CD su abbonamento?) e Amazon erano nuovissimi. Internet era ancora un po' una novità e l'iPhone non sarebbe apparso prima di sette anni. L'elenco potrebbe continuare, ma il punto è che lo sviluppo tecnologico nel mondo dell'IT ha subito un'accelerazione esponenziale negli ultimi 20 anni circa.
Nonostante questa evoluzione, un'innovazione fondamentale ha prevalso, in gran parte invariata, durante tutto questo periodo.
Lettura correlata
Punto dolente
Negli anni '90, le directory rappresentavano una delle principali criticità amministrative dell'IT per le aziende. Il mondo del lavoro era supportato da una serie di piccole directory che rendevano la condivisione di dati e file chiave un compito complicato e laborioso. Per accedere ai file condivisi, gli utenti dovevano accedere a ogni singolo file system, richiedendo diverse credenziali, software e applicazioni.
Con l'introduzione di Windows NT a metà degli anni '90, Microsoft aveva già aiutato molte aziende ad adottare il concetto di "dominio", consentendo di unire più sistemi in un circolo di fiducia, riducendo di fatto la segmentazione delle identità degli utenti in directory separate. Tuttavia, se da un lato Windows NT ha permesso a Microsoft di entrare con successo nei data center aziendali, dall'altro i limiti di scalabilità intrinseci dei domini Windows NT hanno reso necessaria la creazione e la gestione di più directory di dominio in aree geografiche diverse, con trust tra di esse per condividere l'accesso dei vari utenti di un'azienda. Ciò diventava sempre più impegnativo man mano che non solo le aziende, ma anche i loro sistemi informatici salivano sul carro della globalizzazione.
Microsoft Active Directory (AD) era all'epoca una tecnologia rivoluzionaria, rilasciata inizialmente con il sistema operativo Windows 2000 e che continua a supportare gran parte del mondo del lavoro iperconnesso che abitiamo nell'era moderna.
È stato per molti versi innovativo. Le aziende globali potevano scalare le loro directory, non dovendo più fare affidamento su molti domini piccoli e difficili da gestire. In effetti, c'erano altre directory che lottavano per offrire gli stessi vantaggi alle aziende. Novell eDirectory, ad esempio, era molto utilizzato. Tuttavia, Microsoft AD ha prevalso su tutti gli altri per una ragione fondamentale: era aperto.
Aperto o sicuro?
"Aperto", nel caso dei servizi di directory, significa "leggibile da chiunque", che è ancora oggi l'impostazione predefinita di qualsiasi configurazione AD, almeno per l'utente autenticato, cioè qualsiasi utente che abbia effettuato l'accesso a un computer con il proprio account AD. Novell ha scelto un percorso più sicuro con eDirectory, richiedendo agli amministratori di concedere in modo specifico le autorizzazioni di lettura a tutte le sezioni necessarie per gli utenti e le applicazioni, aggiungendo un ostacolo operativo per l'inserimento e l'integrazione di nuove applicazioni.
Questa apertura, che 21 anni fa era il principale punto di forza di Microsoft Active Directory, da allora è diventata la sua debolezza più preoccupante.
Al momento del lancio è stato molto apprezzato per la sua capacità di integrarsi facilmente con le applicazioni e di fornire il single sign-on in un ambiente aziendale completo, riducendo così il fastidio della gestione delle password e delle directory con un'autenticazione ad ampio raggio. Grazie a questa apertura e facilità di integrazione, AD rimane un elemento fondamentale dell'infrastruttura per il 90% delle aziende. Il suo utilizzo è talmente ampio che oggi la maggior parte delle applicazioni aziendali non dispone nemmeno di una propria directory, ma si affida all'autenticazione dell'utente da parte di Windows.
Tuttavia, questa apertura ha creato anche delle vulnerabilità.
Delega non vincolata
Prendiamo ad esempio le caratteristiche specifiche di Kerberos. Kerberos è un protocollo di autenticazione per reti di computer che funziona con una struttura di ticketing per consentire ai nodi che comunicano su reti aziendali di fornire la propria identità in modo sicuro. Si trattava di un protocollo altamente sicuro per l'epoca, come sottolineato dal significato del suo nome: Nella mitologia greca, Kerberos è un cane a tre teste che sorveglia le porte degli Inferi per impedire ai morti di uscire.
Una capacità speciale offerta da Kerberos era quella della delega, che funzionava per garantire che un utente che accedeva a un'applicazione su un sistema fosse in grado di accedere solo a informazioni specificamente condivise (spesso un file o dati specifici in un database) con quell'applicazione su un altro sistema, impedendo l'accesso ad altri dati. Da un punto di vista tecnico, ciò è stato ottenuto impersonando l'utente da parte dell'applicazione mentre questa accedeva all'altro servizio per conto dell'utente. L'applicazione, o meglio il server che ospita l'applicazione, è stata "delegata" a utilizzare l'autenticazione Kerberos di qualcun altro, ovvero le è stato concesso il diritto di inoltrare il ticket Kerberos dell'utente a un altro sistema come se l'utente stesse accedendo direttamente all'altro sistema. Con l'introduzione di AD nel 2000, era possibile configurare la delega Kerberos solo in modo "non vincolato", ovvero l'applicazione era in grado di passare il ticket Kerberos dell'utente a qualsiasi altro sistema.
Oggi, questa pratica è stata resa obsoleta da modalità di condivisione dei dati molto più sicure e senza interruzioni. Tuttavia, le impostazioni di delega non vincolate sono ancora prevalenti in un numero significativo di sistemi, spesso perché il potenziale impatto non è compreso dagli operatori di AD o dai proprietari dell'oggetto server specifico scelto per essere configurato in questo modo. Gli hacker di oggi possono sfruttare questa possibilità per impersonare qualsiasi utente AD su qualsiasi altro computer. Se a questo si aggiunge la consapevolezza che un hacker può utilizzare qualsiasi account AD non privilegiato per leggere quasi tutti gli attributi e gli oggetti in AD, comprese le loro autorizzazioni, consentendo di trovare account di computer in qualsiasi dominio di una foresta AD configurati con una delega non vincolata, si ha un'idea del perché l'apertura predefinita di AD sia diventata una vulnerabilità.
Nel peggiore dei casi, l'intruso potrebbe accedere a questo sistema e scoprire che i controller di dominio hanno ancora il servizio di stampa (spooler) attivo. Il servizio di stampa è sempre attivo per impostazione predefinita, su qualsiasi server Windows;dovrebbe essere disattivato dagli amministratori IT su qualsiasi server che non ne abbia bisogno, ma molti non lo fanno. Nel nostro scenario, un hacker può quindi invocare un controller di dominio per autenticarsi al computer con la delega non vincolata e utilizzare il cosiddetto bug della stampante per invocare una richiesta di autenticazione dal controller di dominio al computer catturato. Anche se non c'è nulla da stampare, attraverso questo processo un attore delle minacce può assicurarsi il ticket Kerberos di un controller di dominio e quindi compromettere il dominio e la foresta AD.
La delega vincolata è un po' più sicura, ma è ancora attaccabile.
Opportunità per gli attori delle minacce
Ci sono altri esempi di come il cane a tre teste abbia perso nel tempo parte della sua forza protettiva. Sempre più vettori di attacco contro di esso sono stati trovati e documentati pubblicamente, consentendo così ai criminali informatici di utilizzarli durante il loro percorso di attacco contro l'AD.
Un altro buon esempio è dato dai nomi dei principali servizi (SPN), ovvero il modo in cui un client Kerberos identifica in modo univoco un'istanza di un servizio per un determinato computer di destinazione Kerberos (ad esempio, un database SQL) e aiuta anche a individuare l'account del servizio correlato (ad esempio, l'account del servizio SQL), che viene utilizzato dal servizio stesso per autenticarsi in AD.
Questo meccanismo consente agli utenti di sfruttare Kerberos per l'autenticazione a un database SQL, anziché autenticarsi con il protocollo meno sicuro NTLM, ed è diventato lo standard per l'integrazione dell'autenticazione AD nelle implementazioni SQL nella maggior parte delle aziende. L'aspetto negativo è che i ricercatori di sicurezza hanno scoperto che gli SPN stessi sono facilmente attaccabili attraverso le informazioni che trasmettono durante l'autenticazione Kerberos al servizio - in particolare l'hash della password dell'account del servizio stesso - anche se il richiedente non procede all'autenticazione al servizio.
Questo hash è ora soggetto a tentativi di cracking offline, che una serie di strumenti disponibili pubblicamente, come John the Ripper, sono felici di aiutare.
Grazie all'apertura di AD, un intruso è facilmente in grado di trovare SPN privilegiati nell'ambiente (si pensi a un SPN collegato a un account amministratore di dominio), creando un altro facile vettore di attacco in grado di essere manipolato per fornire privilegi elevati e piena visibilità. Questa combinazione di controllo e visibilità può essere incredibilmente pericolosa. Quando si dispone dei massimi permessi, si ha il pieno controllo e si può far fallire un'azienda e chiedere un riscatto.
Ma è anche possibile utilizzarlo per la ricognizione precedente. "Quali sono gli account privilegiati? Quali sono le vulnerabilità che posso sfruttare?". Per gli attori delle minacce, Active Directory agisce come una mappa, evidenziando i punti deboli dell'ambiente. Una volta entrato nella vostra rete, un hacker userà AD per cercare e colpire i vostri dati importanti, estrarli, criptarli e chiedere un riscatto. E molte aziende non sono semplicemente preparate a questa eventualità. Si crea un conflitto. Disponete di backup adeguati per ripristinare l'intera azienda, compresa l'Active Directory, senza dover pagare un riscatto?
Per molti la risposta è no: sono costretti a pagare il riscatto e gli hacker passano a un altro obiettivo altrettanto impreparato, creando un circolo vizioso.
L'esempio di SolarWinds
Ma quanto spesso l'AD viene sfruttato in questo modo dagli attori delle minacce? La violazione di SolarWinds, nota come Solorigate, è uno degli esempi recenti più famosi, in cui l'AD è stato determinante per un attacco alla catena di fornitura su larga scala che ha colpito decine di migliaia di organizzazioni di alto profilo, tra cui enti governativi statunitensi. SolarWinds stessa è un fornitore leader a livello mondiale di soluzioni IT e il suo strumento di gestione della rete Orion è uno dei principali software utilizzati da queste organizzazioni per proteggere, sostenere e proteggere le proprie reti. Nell'attacco a SolarWinds, gli hacker sono riusciti a iniettare con successo un trojan nel software Orion, che si è poi diffuso attraverso un meccanismo di download periodico installato dai clienti dell'azienda. Iniziato già nel marzo 2020, questo attacco sponsorizzato dallo Stato e il suo trojan sono stati scoperti solo nel dicembre dello stesso anno.
Si è trattato di un attacco altamente dannoso che ha colpito innumerevoli aziende Fortune 500 ed enti governativi di importanza vitale negli Stati Uniti. Ma come è stato possibile un attacco così potente alla catena di approvvigionamento? È qui che entrano in gioco l'AD e le falle on-premises.
SolarWinds aveva creato un servizio di federazione tra i propri servizi di directory on-premises e il cloud, dove gestiva il codice del software Orion. In questa configurazione, il cloud si affida completamente al servizio di federazione per dimostrare correttamente l'identità di un utente, consentendo all'utente di accedere con la propria identità in sede, spesso abbinata a una soluzione di autenticazione multifattoriale (MFA) di terze parti.
Accedendo in questo modo e ricevendo un token di federazione correttamente firmato, il cloud provider si fida dell'autenticazione e autorizza gli utenti autenticati fornendo loro l'accesso alle risorse cloud richieste.
Nel caso dell'attacco di SolarWinds, gli intrusi sono stati in grado di utilizzare questa federazione a loro vantaggio per accedere furtivamente al codice sorgente di Orion ospitato nel cloud, rubando il certificato di firma del token. Si tratta del primo attacco di questo tipo di cui si abbia notizia che abbia utilizzato un linguaggio di markup per l'accesso sicuro (SAML). La federazione avviene tramite protocolli come SAML, utilizzati per trasmettere un token di sicurezza alla parte fidata. Ma come ha fatto l'intruso a ottenere questo certificato di firma del token?
Torniamo al punto in cui si è verificata la violazione: il certificato di firma del token era protetto dall'account di servizio per i servizi di federazione AD, ospitato come qualsiasi altro account nell'AD on-premise. Una volta che gli attori delle minacce hanno ottenuto l'accesso all'AD on-premise e all'account di servizio ADFS, hanno avuto modo di leggere il certificato e di utilizzarlo per creare il proprio token SAML e accedere alle risorse del cloud SolarWinds. Di conseguenza, la catena di eventi dimostra che la sicurezza di Active Directory è stata una delle debolezze principali nel percorso di attacco di questa grave violazione.
Si tratta infatti di un esempio emblematico di un'azienda che ha creduto che i suoi sistemi cloud fossero sicuri quando invece non lo erano, a causa dell'AD e della sua dipendenza dalla sede. Mentre il cloud era separato, la fiducia tra i sistemi vulnerabili on-premises e il cloud forniva l'accesso alla rete, creando un ponte che gli attori delle minacce potevano utilizzare per intromettersi nelle risorse cloud dell'azienda.
Affrontare le sfide
Dal punto di vista della sicurezza, AD è la fonte di molti problemi. Microsoft non ha investito in un aggiornamento di sicurezza per AD dal 2016, anche se questo sistema di identità principale è ancora utilizzato dal 90% delle aziende.
La soluzione più semplice sarebbe quella di eliminare l'AD, ma questo non accadrà mai. Si tratta di una soluzione legacy, ma non è destinata a scomparire presto, visto che molte aziende e centinaia di migliaia di applicazioni line-of-business fanno ancora affidamento su questa tecnologia. Detto questo, non è una causa persa e le aziende possono adottare misure per proteggersi.
Si tratta infatti di un processo: l'implementazione di protocolli di protezione adeguati, a partire dal riconoscimento e dalla comprensione delle potenziali vulnerabilità. Fate una sessione di brainstorming e chiedetevi: "Cosa succederebbe se i sistemi critici andassero in tilt?".
Le aziende possono affrontare le interruzioni operando con doppi datacenter o con una soluzione ibrida di datacenter e cloud, ma devono andare oltre e considerare cosa potrebbe accadere se un sistema critico come la gestione delle identità venisse compromesso. Prendetevi il tempo necessario per comprendere le dipendenze da tutte le vostre applicazioni aziendali. Ed esplorate le dipendenze tra il vostro processo di autenticazione e il cloud. Con un sistema di autenticazione basato sulla federazione, potreste finire molto rapidamente nei guai.
Una volta comprese queste dipendenze, si può iniziare a identificare, comprendere e dare priorità alle vulnerabilità da affrontare. Deve essere un processo olistico che non lasci nulla di intentato per raggiungere la piena preparazione. Se una barca perde e non avete l'attrezzatura per ripararla, la barca affonderà. Allo stesso modo, se si individua solo una delle molteplici falle che perdono, la barca affonderà comunque.
È fondamentale che un'azienda comprenda a fondo tutte le potenziali vulnerabilità per affrontarle e prepararsi come necessario. Se non altro, l'attacco di SolarWinds serve come importante curva di apprendimento, dimostrando gli effetti catastrofici che potrebbero verificarsi quando si verifica un attacco basato su AD. Dato l'ambiente di minacce sempre più complesso e in crescita, non è mai stato così importante affrontare le vulnerabilità legate all'AD come oggi.
