Snake: il malware dell’intelligence russa e l’approccio alla cyber defense

Mai come oggi chi lavora nel campo della cybersecurity ha forte la consapevolezza di come il momento storico in cui viviamo sarà interpretato dalla storia come un punto di svolta, in cui chi ha investito con lungimiranza (dal cui corrispettivo inglese, «farsight», non a caso deriva il nome di questo magazine) e creduto nel valore della superiorità tecnologica avrà guadagnato un vantaggio strategico incolmabile per i competitor (sia che si parli di equilibri geopolitici, di competizione industriale o, realisticamente, di un misto di entrambe le cose).

In questa sede, che ha le limitazioni di uno spazio divulgativo, l’obiettivo prefisso è quello di condividere una riflessione su temi di interesse per il settore della sicurezza, al fine di stimolare e alimentare una costruttiva discussione tra chi svolge questo mestiere.

Abbiamo nel tempo affrontato il tema della cybersecurity (ma è più corretto parlare di sicurezza, poiché è ormai evidente oggi la profonda interconnessione dei tanti ambiti in cui i responsabili di un perimetro di difesa devono sapersi muovere) da più punti di vista, sottolineandone ad esempio l’importanza nel conflitto russo-ucraino ed evidenziandone la rilevanza anche in un contesto globale di crescita dei fenomeni di hacktivismo, ma sempre seguendo il leitmotiv di un principio di condivisione delle informazioni e di accrescimento culturale.

Una corretta cultura della sicurezza è legata indissolubilmente ad una corretta informazione, ma se da un lato è vero che c’è sempre una maggior attenzione dei media mainstream verso i temi della cyber security, dall’altro è impossibile non notare una certa superficialità e approssimazione nel modo in cui tali argomenti vengono proposti al grande pubblico: la prassi di molti organi di informazione generalisti del «fare di tutta l’erba un fascio» aumenta il rischio di appiattimento e banalizzazione dell’attività di analisi: se l’enfasi della notizia è sul clamore del momento (e lo stile è quello della cronaca nera di provincia) si perde consapevolezza del quadro generale, delle strategie avversive messe in atto dagli attaccanti, degli equilibri politici nazionali e internazionali che condizionano l’attività di difesa dei perimetri, oltre che la capacità di valutare l’impatto di breve, medio e lungo periodo (reputazionale, operativo etc.).

Non ci sorprende dunque che, in questo scenario, venga sovente dedicato più spazio da telegiornali e quotidiani a notizie riguardanti banali attacchi DDoS piuttosto che alla compromissione di sistemi SCADA^[1]SCADA (acronimo dall’inglese Supervisory Control And Data Acquisition, cioè «controllo di supervisione e acquisizione dati»), nel lessico dei controlli automatici, indica un sistema informatico distribuito per il monitoraggio e la supervisione di sistemi fisici., così come che quasi mai venga considerata – quando presente – la «visione di insieme» e il tema dell’attribution («chi ha portato l’attacco realmente? con quale obiettivo? il target finale è realmente quello più ovvio?»).

Il caso del gruppo APT Snake e dell’omonimo malware a questi associato può essere ritenuto esemplificativo dell’approccio prospettico che ogni apparato di sicurezza dovrebbe mostrare nell’analisi dei fenomeni cyber: il fatto che si tratti di un malware particolarmente evoluto (e costantemente manutenuto), che sfugge alla maggior parte dei controlli standard e può rimanere residente e silente all’interno dei sistemi infettati a tempo indefinito (esfiltrando al contempo eventuali dati sensibili), costituisce evidenza che vi sono scenari di minaccia per la sicurezza delle informazioni e delle infrastrutture critiche di rilevanza molto maggiore rispetto alle conseguenze del defacement^[2]Atto illecito che consiste nel modificare la home page o le pagine interne di un sito web, per creare un danno o per dimostrare la propria abilità e la scarsa sicurezza del sistema. di un sito istituzionale o dell’indisponibilità di un sito web come conseguenza di un attacco DDoS.

La CISA (Cybersecurity and Infrastructure Security Agency), agenzia statunitense per la sicurezza cyber, ha pubblicato un’interessante analisi (che vale la pena qui approfondire) del malware Snake, evidenziandone caratteristiche peculiari, punti di forza (da conoscere) e di debolezza (da sfruttare per il rilevamento e la difesa).

Che cos’è il malware Snake?

Con il nome “Snake” (anche noto con gli pseudonimi di Turla, Venomous Bear, Uroburos, Group 88, Waterbug e Turla Team) si indica uno dei più evoluti ed avanzati gruppi APT riconducibili alla galassia hacker sotto la direzione, diretta o indiretta, della Federazione Russa.

Con il termine omonimo è indicato altresì il più famoso e ingegnoso malware sviluppato negli anni dal suddetto gruppo APT: si ritiene ad oggi che Snake sia infatti lo strumento di cyberspionaggio più sofisticato nell’arsenale dell’FSB^[3]Il «Servizio federale per la sicurezza della Federazione Russa» (in russo Federál’naja služba bezopásnosti Rossijskoj Federácii), noto con la sigla FSB, è uno speciale organo federale della Federazione Russa che, nei limiti della sua autorità, svolge compiti … continua..., impiegato dal Centro 16 del Servizio di Sicurezza Federale russo per la raccolta di informazioni a lungo termine su obiettivi sensibili.

Per condurre in modo efficace le proprie operazioni con questo strumento, l’FSB ha creato una rete segreta peer-to-peer (P2P) composta da innumerevoli computer infettati da Snake in ogni parte del mondo. Molti sistemi di questa rete P2P fungono da “nodi relè” che instradano il traffico operativo occultato da e verso gli zombie^[4]Sistemi informatici inconsapevolmente sotto il controllo del malware. Snake contro gli obiettivi finali dell’FSB. I protocolli di comunicazione customizzati di Snake utilizzano crittografia e frammentazione per la massima segretezza e sono progettati per ostacolare il rilevamento e ogni tentativo di raccolta di informazioni.

La Cybersecurity and Infrastructure Security Agency americana ha identificato la presenza di Snake in oltre 50 Paesi in Nord America, Sud America, Europa, Africa, Asia e Australia, compresi gli Stati Uniti e la stessa Russia. Sebbene Snake sfrutti infezioni di ogni settore industriale, il suo target finale è specifico e di natura strategica: a livello globale, l’FSB ha utilizzato Snake per raccogliere informazioni sensibili da obiettivi ad alta priorità, come reti governative, strutture di ricerca e giornalisti.

Solo come esempio, è noto che gli agenti dell’FSB abbiano utilizzato Snake per ottenere accesso e garantire l’esfiltrazione di documenti sensibili su relazioni internazionali e comunicazioni diplomatiche, da target facenti parte di paesi NATO. All’interno degli Stati Uniti, poi, l’FSB ha colpito settori come l’istruzione, le piccole imprese e i media, oltre a infrastrutture critiche come strutture governative, servizi finanziari, industria manifatturiera e telecomunicazioni.

In questa sede, cercheremo di fornire un quadro generale dei motivi che portano l’attribution di Snake all’FSB, nonché descrizioni tecniche dell’architettura host e delle comunicazioni di rete del sistema.

Livello di sofisticazione

La sofisticazione di Snake deriva da tre aspetti sostanziali:

• in primo luogo, Snake adotta metodi molto specifici per raggiungere un alto livello di occultamento dei suoi componenti nell’host e nelle comunicazioni di rete;
• in secondo luogo, l’architettura tecnica interna di Snake consente di incorporare facilmente componenti nuovi o sostitutivi. Questo design facilita anche lo sviluppo e l’interoperabilità delle istanze di Snake in esecuzione su sistemi operativi host diversi. Si sono osservati impianti Snake interoperabili per i sistemi operativi Windows, MacOS e Linux;
• infine, Snake dimostra un’attenta progettazione e implementazione del software, con l’impianto che presenta sorprendentemente pochi bug, data la sua complessità.

Inoltre, in seguito alle molte segnalazioni delle società di cybersicurezza e di threat intelligence sulle tattiche, tecniche e procedure^[5]Con l’acronimo di tattiche, tecniche e procedure si identifica generalmente un particolare approccio di analisi sul funzionamento di una minaccia APT. (TTP) di Snake, l’FSB ha implementato nuove tecniche per eludere il rilevamento. Le modifiche all’impianto hanno ulteriormente alzato l’asticella della sfida al rilevamento e identificazione di Snake e dei relativi artefatti, minando significativamente l’efficienza dei tool difensivi automatici basati su analisi host e di rete.

L’efficacia di questo tipo di sistema di spionaggio cibernetico dipende interamente dal suo occultamento a lungo termine poiché un’operazione di spionaggio su vasta scala implica la permanenza sull’obiettivo per mesi o addirittura anni, fornendo un accesso costante e continuo a un’intelligence di rilievo. In quest’ottica, l’elevata sofisticazione di Snake è rappresentativa dell’enorme sforzo (ed investimento) compiuto dall’FSB nel corso di molti anni, al fine di consentire una tale affidabilità di accesso sotto copertura.

Evoluzione nel tempo

L’FSB ha iniziato a sviluppare Snake come “Ouroboros” alla fine del 2003. Lo sviluppo delle versioni iniziali del sistema sembra essere stato completato all’inizio del 2004, con il primo uso operativo seguito poco dopo. Il nome Ouroboros (il celebre serpente circolare che morde la propria coda, simbolo della ciclicità della vita) è pertinente, in quanto l’FSB lo ha fatto passare attraverso numerosi cicli di aggiornamento e miglioramento – senza mai dismetterlo – anche dopo public disclosures.

Non è fatto secondario per studiarne evoluzione e attribuzione, il fatto che il nome appaia in tutte le prime versioni del codice e che gli sviluppatori dell’FSB abbiano lasciato anche altre stringhe identificabili (tra cui “Ur0bUr()sGoTyOu#”) nel sorgente, tornate utili agli analisti per tracciarne origine e cambiamenti.

Tra le altre caratteristiche uniche delle prime versioni di Ouroboros, era inclusa un’immagine a bassa risoluzione di una parte di un’illustrazione storica di un Uroboro del filosofo e teologo tedesco Jakob Böhme. Un accesso a una backdoor terziaria utilizzava questa immagine come chiave. La stessa immagine era stata incorporata anche in altri componenti legati a Snake.

I primi sviluppatori FSB del sistema Snake hanno lasciato inoltre intere porzioni di codice univocamente identificabile in tutto l’applicativo, rivelando scambi di battute interne, interessi personali e prese in giro rivolte agli analisti di sicurezza (ad esempio, la stringa “Ur0bUr()sGoTyOu#” di cui sopra è stata sostituita con “gLASs D1cK” nel 2014 a seguito di alcune segnalazioni pubbliche effettuate dalla community di sicurezza).

Attribuzione

La CISA attribuisce le operazioni di Snake a un’unità nota all’interno del Centro 16 dell’FSB. Questa unità gestisce in modo esteso i numerosi elementi del set di strumenti Turla e ha sottounità sparse in tutta la Russia, retaggio delle storiche operazioni di intelligence dei servizi del KGB nell’Unione Sovietica.

Snake è stato un componente centrale delle operazioni di questa unità per quasi tutto il periodo in cui il Centro 16 ha fatto parte dell’FSB. L’ampia influenza di Snake in tutto il set di strumenti di Turla dimostra il suo impatto su praticamente ogni aspetto delle operazioni informatiche dell’era moderna dell’unità.

Le operazioni standard con Snake pare siano state condotte a partire da una struttura dell’FSB a Ryazan, in Russia (con l’evidenza di un incremento dell’attività di Snake nella fascia oraria lavorativa, approssimativamente dalle 7:00 alle 20:00, del fuso orario di Mosca).

Risulta inoltre che, in origine, i principali sviluppatori fossero ufficiali dell’FSB con sede a Ryazan, identificati grazie ai nickname inclusi nel codice di alcune versioni di Snake. Oltre a sviluppare Snake, gli ufficiali dell’FSB con sede a Ryazan lo utilizzavano per condurre operazioni su scala planetaria, distinte da altre lanciate da Mosca o altri siti dell’FSB per tipo di infrastrutture e tecniche adottate.

Mentre lo sviluppo e il riadattamento di Snake è stato storicamente effettuato da funzionari dell’FSB con sede a Ryazan, le operazioni vere e proprie di Snake sono state lanciate anche da un edificio occupato dal Centro 16 dell’FSB a Mosca. Le indagini hanno identificato casi di operatori dell’FSB capaci di sfruttare Snake al massimo delle sue funzionalità, ma anche di operatori dell’FSB che sembravano non avere familiarità con le capacità più avanzate di Snake: queste evidenze testimoniano la difficoltà nell’utilizzare un set di strumenti così avanzato dei gruppi geograficamente eterogenei che compongono l’unità del Centro 16 dell’FSB.

Il governo americano ha monitorato Snake e gli strumenti ad esso correlati per quasi 20 anni. In questo periodo, risulta che l’FSB abbia utilizzato Snake in molteplici operazioni di rilievo. Il codice di Snake e i molteplici strumenti da esso derivati hanno rappresentato un punto di partenza e un fattore di ispirazione per una vasta gamma di altri sistemi e strumenti operativi altamente prolifici della famiglia Turla. In particolare, si può citare Carbon (alias Cobra) – derivato dalla base di codice di Snake – e il sistema altrettanto affine a Snake, Chinch (attualmente conosciuto su fonti aperte come ComRAT).

Target strategici

La CISA ha identificato l’infrastruttura di Snake in oltre 50 Paesi in Nord America, Sud America, Europa, Africa, Asia e Australia, compresi gli Stati Uniti e la stessa Russia. Sebbene Snake miri in prima istanza ad infettare qualsiasi sistema in modo automatico, nel caso di target strategici l’effort profuso comprende azioni di controllo gestite da operatori umani: ad esempio, se un sistema bersaglio precedentemente infettato non risponde alle comunicazioni di Snake, gli attori dell’FSB si adoperano per recuperarne il controllo attraverso una nuova infezione.

Modus operandi e violazione delle infrastrutture

Secondo il modus operandi tipico, l’FSB cerca di infiltrare Snake attraverso i nodi di un’infrastruttura esposti su internet; una volta violati i sistemi periferici adotta altri strumenti e TTP per scalare la rete interna e condurre ulteriori operazioni di exploitation.

Dopo aver ottenuto e consolidato l’accesso ad una rete target, l’FSB in genere censisce la rete (al fine di identificare risorse e informazioni utili) e lavora per ottenere le credenziali di amministratore e accedere ai controller di dominio. Per raccogliere le credenziali degli utenti e degli amministratori, al fine di espandersi trasversalmente sulla rete, è stata adottata un’ampia gamma di meccanismi, tra cui keylogger, sniffer di rete e anche strumenti open source.

In genere, dopo che gli operatori dell’FSB hanno mappato una rete e ottenuto le credenziali di amministratore per i vari sotto-domini della rete, iniziano le operazioni di raccolta regolari. Nella maggior parte dei casi assieme a Snake non vengono dispiegati malware e si predilige l’uso di credenziali trafugate e strumenti “leggeri” di accesso remoto presenti all’interno della rete.

Vi sono casi in cui è stata installata anche una piccola reverse shell remota insieme a Snake per consentire operazioni e controllo interattivi in tempo reale. Questa reverse shell (attivabile alla bisogna), in uso all’FSB da circa 20 anni, può essere anche utilizzata come vettore di accesso di backup alla rete, oppure sfruttata per garantire una presenza minima nel sistema senza insospettire i gestori di rete durante le fasi di lateral movement^[6]Il Lateral Movement è una tecnica malevola usata per spostarsi progressivamente da un punto di ingresso compromesso al resto della rete cercando dati sensibili o altre risorse di alto valore da sottrarre: per questo motivo è difficile da rilevare e contrastare..

Architettura di Snake

Modularità e ridondanza

Il design dell’architettura di Snake rispecchia le più classiche prassi professionali dell’ingegneria del software. I percorsi critici all’interno dell’applicativo sono costituiti da pile di componenti in accoppiamento loosy coupled^[7]Un’architettura loosely coupled (debolmente accoppiata) è uno stile architetturale nel quale i singoli componenti di un’applicazione sono costruiti in modo indipendente l’uno dall’altro (si tratta del paradigma opposto a quello delle architetture tightly coupled, cioè … continua... che implementano interfacce progettate ad hoc.

Oltre a facilitare lo sviluppo e il debug del software, questa struttura consente a Snake di utilizzare più componenti distinti e funzionalmente ridondanti per lo stesso scopo, scegliendo poi l’implementazione specifica in base a valutazioni circostanziali.

I protocolli di comunicazione di rete personalizzati di Snake, ad esempio, funzionano come uno stack: tutte le implementazioni utilizzano un livello di crittografia e un livello di trasporto (come un protocollo HTTP o il socket TCP raw customizzati). Ogni livello dello stack di protocolli di rete di Snake, inoltre, implementa esclusivamente un’interfaccia specifica per l’operatività con i due livelli adiacenti. Il livello di encryption e il livello di trasporto sottostante funzionano quindi in modo indipendente, per cui qualsiasi protocollo di rete Snake personalizzato può impiegare un overlay di encryption senza alcuna modifica al codice del livello di encryption.

Linguaggi di programmazione

La cura e la sofisticazione tecnica di Snake partono dall’architettura del software fino all’implementazione del codice nella programmazione a basso livello. Le versioni originali di Snake sono state sviluppate già nel 2003, prima che fossero disponibili molti dei moderni linguaggi di programmazione e dei framework che facilitano questo tipo di sviluppo modulare.

Snake è scritto interamente in C, che offre vantaggi significativi nel controllo e nell’efficienza a basso livello, ma che non fornisce un supporto diretto per gli oggetti o le interfacce a livello di linguaggio e non fornisce assistenza per la gestione della memoria. Gli sviluppatori di Snake hanno implementato con successo il complesso design architetturale in C con pochissimi bug, riuscendo ad evitare abilmente le comuni insidie legate alle stringhe null-terminated e alla mescolanza di numeri interi signed e unsigned^[8]In informatica, numeri relativi o interi positivi..

Inoltre, i creatori del malware hanno dimostrato una profonda padronanza dei principi della programmazione informatica durante l’implementazione delle specifiche funzionali, che si tratti di una corretta selezione e codifica di algoritmi asintoticamente ottimali, di progettazione e utilizzo di efficienti metodologie di codifica custom in grado di confondersi con schemi di codifica standard oppure di gestione dei numerosi errori potenziali associati alla programmazione a livello di sistema.

Sfruttare le vulnerabilità degli attaccanti

Sebbene l’impianto Snake nel suo complesso sia uno strumento di spionaggio altamente sofisticato, non sfugge all’errore umano. Uno strumento come Snake richiede una maggiore esperienza e competenza per essere usato correttamente rispetto a sistemi meno evoluti ed in diversi casi gli operatori di Snake non si sono dimostrati all’altezza nel gestirne la complessità: diversi errori nello sviluppo e nel funzionamento di Snake hanno fornito agli analisti un punto di partenza per comprenderne le meccaniche interne e ciò è stato determinante nel tempo per lo sviluppo delle conoscenze necessarie ad isolare i processi di Snake e effettuare un reverse engineering del codice.

Per fare un esempio, l’FSB ha utilizzato la libreria OpenSSL per gestire il suo scambio di chiavi Diffie-Hellman. Il set di chiavi Diffie-Hellman creato da Snake durante lo scambio di chiavi è troppo breve per essere sicuro. L’FSB ha fornito la funzione DH_generate_parameters con una lunghezza del primo di soli 128 bit, che è inadeguata per i sistemi a chiave asimmetrica.

Inoltre, in quelle che sono sembrate implementazioni “precipitose” di Snake, gli operatori hanno trascurato di effettuare lo strip^[9]Lo “strip” del codice binario (dall’inglese to strip) è l’operazione con la quale il compilatore, nel passare dal codice sorgente al codice eseguibile, anonimizza o pseudonimizza parti rilevanti del codice, sia per ottimizzazione delle prestazioni che per protezione del … continua... del codice binario di Snake. Ciò ha permesso la scoperta di numerosi nomi di funzioni, stringhe in chiaro e commenti degli sviluppatori, come si può vedere nella figura seguente.

Misure preventive e di mitigazione

Si noti che le misure di mitigazione che seguono non sono intese a proteggere dal vettore di accesso iniziale e sono pensate solo per contrastare le tecniche di persistenza e di occultamento di Snake. Si tratta inoltre di suggerimenti che non esauriscono necessariamente le azioni di mitigazione possibili o necessarie.

Cambiare le credenziali e applicare gli aggiornamenti

Ai gestori di sistemi che si ritiene siano stati compromessi da Snake si consiglia di cambiare immediatamente le proprie credenziali (da un sistema non compromesso) e di non utilizzare alcun tipo di password simile a quelle usate in precedenza. Snake impiega una funzionalità di keylogger che restituisce periodicamente i log agli operatori FSB. Si raccomanda di cambiare le password e i nomi utente con valori che non possono essere forzati o indovinati in base alle vecchie password.

Si consiglia ai gestori di sistemi di applicare gli aggiornamenti ai loro sistemi operativi. Le versioni moderne di Windows, Linux e MacOS rendono molto più difficile per gli attori antagonisti operare nello spazio del kernel. Questo renderà molto più difficile per gli agenti FSB caricare il driver kernel di Snake sul sistema di destinazione.

Attuare l’Incident Response Plan dell’organizzazione

Se i gestori dei sistemi registrano firme di rilevamento di attività di installazione di Snake o hanno altri indicatori di compromissione associati a potenziali attori malevoli che utilizzano Snake, l’organizzazione colpita dovrebbe avviare immediatamente il proprio piano di risposta agli incidenti.

È consigliabile implementare i seguenti Cross-Sector Cybersecurity Performance Goals (CPG) per migliorare la postura difensiva contro gli operatori che utilizzano Snake, nonché per mitigare eventuali impatti negativi post-compromissione:

• CPG 2.A: Cambiare le password predefinite impedirà agli attori dell’FSB di compromettere le credenziali predefinite per ottenere l’accesso iniziale o muoversi trasversalmente all’interno di una rete.
• CPG 2.B: Imporre la forza minima delle password in tutta l’organizzazione impedirà agli attori dell’FSB di condurre con successo operazioni di password spraying^[10]Il password spraying (o attacco di password spray) avviene quando l’aggressore usa password comuni per tentare di accedere a più account presenti su uno stesso dominio. Utilizzando un elenco di password deboli molto gettonate, come 123456 o password1, l’aggressore può potenzialmente … continua... o cracking.
• CPG 2.C: Richiedere credenziali univoche impedirà agli attori dell’FSB di compromettere gli account validi attraverso password spraying o brute force.
• CPG 2.E: La separazione degli account utente e con privilegi renderà più difficile per gli attori FSB l’accesso alle credenziali di amministrazione.
• CPG 2.F: Segmentazione della rete per negare tutte le connessioni per default, a meno che non siano esplicitamente richieste per specifiche funzionalità del sistema, e garantire che tutte le comunicazioni in entrata passino attraverso un firewall propriamente configurato.
• CPG 2.H: Implementazione di un’autenticazione multifattore resistente al phishing, che aggiunge un ulteriore livello di sicurezza anche quando le credenziali dell’account sono compromesse e può mitigare una serie di attacchi verso account validi, tra cui il brute forcing delle password e l’exploit di servizi remoti esterni.
• CPG 4.C: Implementare i file Security.txt per garantire che tutti i domini web esposti al pubblico abbiano un file security.txt conforme alle raccomandazioni della RFC 9118.