Articolo Pubblicazioni
SolarWinds: anatomia di un attacco alla supply chain del software
di Vincenzo Calabrò · Pubblicato il 28 dicembre 2020
Abstract
Il 13 dicembre 2020 FireEye e SolarWinds hanno reso noto che gli aggiornamenti della piattaforma di monitoraggio Orion, distribuiti tra marzo e giugno 2020, contenevano una backdoor inserita dagli attaccanti nel processo di produzione del software. Circa 18.000 clienti hanno installato le versioni compromesse. L’articolo ricostruisce quanto è noto a fine dicembre, descrive il funzionamento della backdoor e le azioni di risposta e indica le lezioni per la sicurezza della supply chain del software.
La scoperta
L’8 dicembre 2020 FireEye, una delle principali aziende di sicurezza statunitensi, ha comunicato di aver subito un’intrusione da parte di un attaccante molto sofisticato, che aveva sottratto strumenti usati dal suo gruppo di simulazione degli attacchi. Indagando sull’accesso iniziale, i ricercatori hanno scoperto che proveniva da un software di terze parti installato nella propria rete, la piattaforma di monitoraggio Orion di SolarWinds. Il 13 dicembre FireEye ha pubblicato un’analisi tecnica e SolarWinds ha confermato la compromissione.
La backdoor
Gli attaccanti erano riusciti a inserire codice malevolo in una libreria di Orion durante il processo di compilazione, in modo che il componente risultante fosse firmato digitalmente da SolarWinds e distribuito ai clienti come un normale aggiornamento. Le versioni coinvolte sono state pubblicate tra marzo e giugno 2020. La backdoor, chiamata SUNBURST, presentava caratteristiche studiate per non farsi notare:
- restava inattiva per circa due settimane dopo l’installazione;
- verificava di non trovarsi in un ambiente di analisi e la presenza di alcuni prodotti di sicurezza, fermandosi in certi casi;
- comunicava con l’esterno tramite richieste DNS verso sottodomini generati, che codificavano informazioni sul sistema infetto;
- imitava nel traffico il protocollo legittimo di Orion per l’invio di dati di telemetria;
- attivava una seconda fase solo sui bersagli selezionati dagli attaccanti.
Secondo SolarWinds circa 18.000 clienti hanno scaricato le versioni compromesse. Solo una parte di questi è stata scelta per la seconda fase, che prevedeva l’installazione di ulteriori strumenti e il movimento nella rete con credenziali rubate.
Le vittime
Tra le organizzazioni colpite che hanno confermato l’intrusione o di cui la stampa ha dato notizia ci sono diverse agenzie federali statunitensi, tra cui i dipartimenti del Tesoro e del Commercio, e aziende tecnologiche e di sicurezza. Le indagini sono in corso e l’elenco è destinato ad allungarsi. La portata dell’operazione, la pazienza degli attaccanti e la scelta dei bersagli indicano un’attività di spionaggio di un attore statale. Fonti governative statunitensi hanno indicato come probabile responsabile un servizio di intelligence russo, mentre una attribuzione formale non è ancora stata pubblicata.
Dal locale al cloud
Un aspetto rilevante riguarda il passaggio dalla rete locale ai servizi cloud. Secondo le analisi pubblicate, in alcuni casi gli attaccanti hanno ottenuto il controllo dei sistemi che emettono i token di autenticazione federata, come i server ADFS, e hanno potuto creare token validi per accedere a servizi cloud come la posta elettronica in Microsoft 365. Questa tecnica, nota come Golden SAML, permette di superare l’autenticazione a più fattori, perché il token falsificato viene accettato come se l’utente si fosse autenticato regolarmente.
La risposta
Il 13 dicembre la CISA statunitense ha emesso una direttiva di emergenza che ha imposto alle agenzie federali di scollegare o spegnere i sistemi con le versioni compromesse di Orion. Microsoft e altri partner hanno preso il controllo del dominio usato dalla backdoor, trasformandolo in un interruttore che disattiva SUNBURST nelle installazioni in cui non era ancora stata avviata la seconda fase. SolarWinds ha pubblicato versioni correttive. FireEye ha diffuso indicatori e regole di rilevamento, comprese quelle per riconoscere gli strumenti che le erano stati sottratti.
Che cosa fare se si usa Orion
Le indicazioni per le organizzazioni che usano o hanno usato le versioni coinvolte sono queste:
- isolare i server Orion e conservarne immagini forensi prima di qualsiasi intervento;
- cercare nei log DNS e del proxy le comunicazioni verso i domini indicati dagli avvisi;
- verificare la presenza degli indicatori della seconda fase e di attività anomale degli account amministrativi;
- considerare compromesse le credenziali gestite o raggiungibili da Orion e sostituirle;
- verificare i sistemi di autenticazione federata e i certificati di firma dei token, ruotandoli se c’è sospetto di compromissione;
- ricostruire i sistemi compromessi da fonti affidabili, senza limitarsi a rimuovere i file malevoli.
Gli aspetti forensi
Per chi indaga, il caso presenta difficoltà particolari. La backdoor è rimasta attiva per mesi prima della scoperta, e molte organizzazioni non conservano i log DNS, del proxy o di autenticazione per un periodo così lungo. Senza quei dati è difficile stabilire se un’installazione compromessa sia rimasta alla prima fase o se gli attaccanti abbiano proseguito. Gli attaccanti hanno inoltre usato infrastrutture diverse per ogni vittima e nomi di host coerenti con quelli dell’ambiente colpito, riducendo l’utilità degli indicatori condivisi. Le tracce più affidabili vengono dai log dei sistemi di identità e dei servizi cloud, che registrano accessi, emissione di token e modifiche alle configurazioni.
Le lezioni per la supply chain
Il caso mostra che un aggiornamento firmato da un fornitore legittimo può essere il vettore di un attacco. La firma garantisce che il file provenga dal fornitore. L’integrità del processo di produzione del fornitore è un’altra questione, che la firma non copre. Per le organizzazioni le contromisure sono di due tipi. Da un lato chiedere ai fornitori garanzie sulla sicurezza dello sviluppo e della compilazione, comprese la protezione degli ambienti di build e la verifica dell’integrità del codice. Dall’altro limitare i privilegi e le connessioni dei software di gestione, che hanno accesso a molti sistemi, e sorvegliarne il comportamento come quello di qualsiasi altro componente. Un server di monitoraggio non ha bisogno di comunicare liberamente con Internet.
Vedi anche: l’articolo del 2014 Target e il rischio dei fornitori, l’articolo del 2021 Log4Shell e l’articolo del 2022 Contrastare le minacce alla supply chain ICT.
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn