LECS – ANGI Security Summit 2022
Roma, 28/04/2022 E’ stato un piacere presentare la tecnologia LECS durante l’ evento ANGI – Associazione Nazionale Giovani Imprenditori- E’ stata un occasione per incontrare i vertici della Sicurezza Nazionale e di come il CyberSpazio stia diventando il primo e principale terreno del cyberwarfare. “Tornare” alla tecnologia Italiana in ambito ICT è sicuramente una prerogativa del Governo sia Italiano che dalla Comunità Europea stessa e l’apporto di idee innovative è un perno centrale nei sistemi di difesa per contrastare le cyberminacce. #staysafe Roberto CamerinesiRicercatore appassionato di sicurezza informatica. Certificato eCCPT, eNDP, Sophos. Sviluppatore ed hacker etico, con la missione di estendere la CyberSecurity ovunque. Ideatore del progetto LECS.
Attacchi informatici in Ambienti Manifatturieri
Attacchi informatici a reti produttive È bene precisare anche che nonostante le reti di tipo IT e OT siano reti separate a livello di logica, di fatto cooperano attivamente. Ne consegue che quando si parla di sicurezza informatica per questi ambienti, sviluppare un approccio di security-by-design per un segmento IT significa supportare attivamente la sicurezza dei sistemi OT e viceversa. È possibile distinguere gli attacchi in relazione ad un obiettivo specifico: le compromissioni molto selettive che colpiscono solo certi target o aziende specifiche, e gli attacchi gestiti da bot automatici senza l’intervento umano che puntano alla compromissione massiva, ricercando falle generiche e non patchate. Se invece si vogliono dividere gli attacchi dal punto di vista tecnologico allora si distingue fra: Attacchi ai dati: Similmente alle reti IT, i malware, come i ransomware ad esempio, colpiscono i sistemi di controllo per compromettere i dati in essi contenuti, cifrando quando possibile anche file di configurazione e database per bloccare la produzione con il fine ultimo di raggiungere il pay-day. L’obiettivo può essere anche correlato alla data exfiltration di dati sensibili, per prendere possesso di proprietà intellettuali o progetti. Attacchi ai CNC o PLC: piuttosto che colpire i dati residenti o i flussi, questi attacchi sono principalmente diretti verso i macchinari connessi in rete; in questi casi il pericolo non è più solo virtuale, ma include l’ambito fisico con riflessi sulle persone: ad esempio si consideri l’uso di macchinari come presse, forni o miscelatori chimici. Nel caso di compromissione diretta dei PLC, è possibile scatenare reazioni esplosive, con conseguente compromissione di arti o parti fisiche di un operatore umano se non casistiche peggiori. In ambienti, come le industrie ad alto rischio di contaminazione o di esplosioni, il danno può estendersi ben oltre il perimetro dell’azienda stessa. Oltre ai sistemi produttivi, vi sono anche sistemi maggiormente ibridi, come le centrali di controllo aereo o del traffico dei treni che possono rientrare nel campo OT, tenendo conto del fatto che includono sistemi di gestione radio e centrali di controllo connesse in rete. La storia insegna che casi come quelli della centrale di Natanz (malware Stuxnet) possono ancora avvenire anche se sembra non facciano notizia. Attacchi infrastruttura della supply-chain: molti attacchi usano piccoli vettori per raggiungere bersagli più grandi e protetti. Questo è il caso di aziende Corporate che includono nel loco ciclo produttivo aziende minori e terze parti che lavorano e forniscono materiali o servizi software. Un’azienda che fornisce quindi servizi da remoto può essere strumentalmente usata come vettore per infezioni verso aziende maggiori, (caso SolarWind nel 2021). Roberto CamerinesiRicercatore appassionato di sicurezza informatica. Certificato eCCPT, eNDP, Sophos. Sviluppatore ed hacker etico, con la missione di estendere la CyberSecurity ovunque. Ideatore del progetto LECS.
Come Prevenire Data Breaches
Come Prevenire Data Breaches nel proprio perimetro di rete Quali sono gli approcci e le capacità di sicurezza da implementare per evitare una violazione e i relativi danni economici. Fin dallo scorso anno la pandemia COVID-19 ha aumentato i rischi di data breaches in ambito security per le aziende di tutto il mondo, perché si è assistito alla frettolosa adozione del lavoro da remoto, via smartworking senza una adeguata e correlata sicurezza. Infatti, l’utilizzo di PC e wi-fi casalinghi, la frettolosa abilitazione di servizi in cloud e l’estensione delle reti aziendali fino alle case dei singoli dipendenti, non è andata sempre di pari passo all’introduzione di appropriate misure di sicurezza a corredo di tali abilitazioni. Tutto questo ha contribuito all’aumento della superficie di attacco. I risultati sono evidenti e significativi sia in termini di vulnerabilità che gli attaccanti sfruttano senza perdere tempo, sia in temrini di attacchi andati a segno. Naturalmente esiste una significativa differenza fra incidenti di sicurezza e data breaches. I primi non sempre implicano una compromissione dei dati, mentre invece i data breaches sono sempre incidenti di sicurezza. Reagire è tuttavia possibile: non esiste certamente rischio zero, ma nemmeno l’attacco e le sue conseguenze sono ineluttabili, a patto naturalmente di gestire il rischio attraverso la difesa approfondita che richiede il monitoraggio continuo e una capacità di risposta in tempo reale basata su apprendimento automatico. Incidenza dei Data Breaches Dall’ultimo Report di Data Breach Investigations Report 2021 di Verizon basato sui dati del 2020, emerge un numero totale di 29.207 incidenti, di cui 5.258 sono stati confermati come data Breaches. Percentuali in aumento sono state registrate sugli attacchi di phishing per un +11% e sui ransomware per un + 6%, insieme al numero elevato di attacchi rivolti alle applicazioni Web. L’85% delle violazioni è stato determinato da una componente umana, mentre il 61% ha riguardato la esfiltrazione di credenziali e il 13% è stato causato da ransomware. In termini di impatti finanziari, il 95% dei data breaches ha causato danni finanziari tra gli 826 e i 653.587 dollari, ma in alcuni casi i ransomware sono arrivati anche a cifra superiori al milione di dollari di riscatto. Dopo questo avvilente quadro sui data breaches 2020, purtroppo si deve constata come l’avvio del 2021 non consenta una valutazione più ottimistica. Infatti, i dati sui più grandi breaches occorsi da gennaio 2021 evidenziano già 53 mega data breach (il più piccolo avvenuto in India su 500mila record di cittadini indiani, il più grande di 3,27 bilioni di record, denominato COMB e scoperto su RAID Forum) (Fonte dati e grafica Hackmageddon). Ambiti più vulnerabili ai data breaches Alcuni ambiti digitali sono maggiormente preferiti dagli attaccanti per effettuare un attacco e causare un data breach: gli attacchi alle applicazioni web continuano ad essere elevati e costituiscono il principale vettore di attacco nelle azioni di hacking, con oltre l’80% dei data breaches. Subito conseguente a questo dato anche l’incidenza aumentata della compromissione di credenziali (61%) per l’accesso illecito ai sistemi di posta elettronica basati su cloud. Tanto che anche la compromissione delle risorse cloud esterne si è rivelata più numerosa rispetto alle risorse locali e questo sia in relazione agli incidenti sia per i data breaches. (Fonte DBIR). Anche gli IoT sono soggetti a rischio data breaches perché seppure apparentemente insignificanti, rappresentano punti di accesso preziosi per vaste intrusioni di rete, e possono essere utilizzati per condurre attività di spionaggio, creare botnet, o estrarre criptovalute. L’IoT rappresenta di fatto un pericolosissimo punto cieco per le aziende a causa di prassi di produzione troppo veloci ed incuranti della sicurezza by design, per battere la concorrenza e guadagnare di più. In questi casi la security sembra quasi un “ripensamento”, una sorta di passaggio successivo nel processo di produzione. Ma è proprio questo comportamento che favorisce gli aggressori, e rende l’hacking molto più semplice: approfittando di configurazioni errate, forzando le credenziali di accesso, violando le comunicazioni fra devices e in generale sfruttando la mancanza di una appropriata progettazione della sicurezza (Fonte: Darktrace). Il DBIR ha evidenziato anche il fenomeno phishing (36%) che colpisce le vulnerabilità nell’essere umano, con una incidenza pari all’ottantacinque per cento dei data breach. Fra le tecniche di ingegneria sociale, le minacce BEC (Business E-mail compromise) sono state altamente utilizzate con un tasso di successo e di inganno di 15 volte superiore rispetto allo scorso anno. Cosa fare per minimizzare i data breaches? Per introdurre una protezione efficace contro i data breaches all’interno di un perimetro “fluido” costituito da porzioni di infrastruttura IT in Cloud, devices in smartworking, reti wifi, Iot, etc, l’approccio della difesa in profondità (in-depth defence) si rivela vincente. Si tratta di implementare misure di sicurezza a più livelli, sia nei comparti aziendali (formazione, valutazioni di rischio etc.), sia nel network (sui singoli livelli di rete e protocolli correlati – Pila Iso/osi), per garantire una continua valutazione della postura di sicurezza generale. Coniugato a questo, è consigliabile anche attuare il paradigma dello “Zero Trust”, perché è incentrato sulla protezione delle risorse e la premessa che la fiducia non viene mai concesso implicitamente ma deve essere continuamente valutata nel perimetro «fluido» aziendale. Questo approccio alle risorse dell’impresa include la gestione delle identità, delle credenziali, la gestione degli accessi, le operazioni, gli endpoint, e l’infrastruttura di interconnessione. Secondo la in-depth defence, tuttavia, proteggere ognuno di questi ambiti richiede di supervisionare ogni evento nella rete che li collega, istituendo quindi una capacità di monitoraggio continuo delle diverse porzioni di rete aziendale, prevenzione delle possibili azioni malevole, detection di anomalie e una risposta appropriata in tempo reale. Per scegliere l’azione più adatta al contesto il sistema di difesa, tutte le capacità possono essere collegate ad un sistema di apprendimento automatico (Machine Learning-ML) capace di analizzare e prevenire situazioni anomale, ma anche di gestirle prima che si palesi l’attacco vero e proprio e con esso il danno. Nei casi invece di anomalia conclamata queste stesse abilità decisionali automatiche, abilitano ad una risposta immediata e proporzionata alla situazione per impedire che il
LECS VS RCE: Eternal Blue
EternalBlue Vulns. CVE-2017-0144, meglio nota come “EternalBlue” è una vulnerabilità con score CVSSv2: 9.3 ossia, il praticamente quasi il massimo in termini di impatto. E’ critica non solo per l’impatto che può avere sul sistema, ma ovviamente sulla larga diffusione. Considerando che attacca il protocollo SMB, possiamo semplificare indicando che è pertanto vulnerabile tutto ciò che è condiviso in rete mediante questo protocollo. Evoluzione della minaccia: La prima disclosure avviene nella fine del 2017, ma non si limita qui. Infatti troviamo recenti revisioni. I sistemi affetti sono Microsoft Windows 2000, XP, 7, 8, 10 (fino alla build 16) Microsoft Server 2000, 2003, 2008, 2008 R2, 2012. Breve analisi della minaccia EternalBlue, nelle sue varianti, affligge pertanto i sistemie che utilizzando condivisioni basate su protocollo SMBv1. La sua pericolosità è dettata anche dal fatto che non richiede un intervento utente come ad esempio avviene negli altri vettori di attacco come il phishing via mail. Questo vulnerabilità pertanto viene sfruttata in RCE (Remote Code Execution), attaccando direttamente il servizio vulnerabile. Come anticipato, la diffusione è molto ampia, nonostante gli ultimi sistemi abbiano subito il patching, rimangono ad oggi molti sistemi che non sono aggiornati. Pertanto nonostante i moderni sistemi come Windows 11 abbiamo già la patch di sicurezza necessaria, rimangono ad oggi molti sistemi che per retrocompatibilità o semplice mancanza di aggiornamenti non eseguiti utilizzano ancora il protocollo SMBv1 o versioni di sistemi operativi datate. Cosa provoca Questa falla permette quindi di prendere il controllo iniettando una shellcode in esecuzione. Non solo attaccanti “fisici” ma anche molte minacce APT (Advanced Persistent Threat) hanno sfruttato e sfruttano questa vulnerabilità per prendere il controllo del sistema bersaglio. E’ possibile quindi prendere il controllo, avviare comandi, fare pivoting e movimenti laterali in modo indisturbato all’interno della rete. Ricordiamo inoltre che sfruttare questa falla porta molto spesso ad accessi di tipo privilegiati in termini di controllo del sistema remoto, con tutti i vantaggi da un punti di vista della persistenza e semplicità di infezione dei vari servizi. Cosa fare Microsoft ha rilascato diversi bulletin in relazione a questa vulnerabilità, che trovate qui sotto: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010 Qui infatti troviamo le diverse versioni dei sistemi vulnerabili e le relative patch o hotfix. Ovviamente tra i principali consigli, c’è quello di aggiornare il sistema operativo alla più recenti versioni, non solo per EternalBlue ma anche per molte altre vulnerabilità ancora presenti in sistemi datati. LECS VS EternalBlue L’algoritmo intelligente Specto, conosce già bene la minaccia, identificandola e classificandola immediatamente. Il posizionamento strategico del device o Virtual Appliance LECS, permette di identificare questa minaccia che si muove nella rete. Ma già nelle prime fasi della Kill-Chain può identificare la minaccia. Durante la ricognizione di una minaccia che vuole trovare host vulnerabili si genera un particolare traffico di rete che LECS già in questa primo step identifica immediatamente. Questo fa sì che si aumenti la soglia di trigger per minacce in quel contesto, mettendo il device in “allerta” ed inviando la notifica relativa all’amministratore. Diciamo che non è detto che tale servizio aperto permetta di sfruttare la falla, dipende da molti altri fattori. Pertanto l’attaccante può andare in “ricognizione avanzata” verso il target, testando la vulnerabilità di un numero elevato di host, per trarre maggior vantaggio in breve tempo. Anche in questa fase, non direttamente collegata quindi rispetto alla prima, LECS identifica il tentativo di ricerca SMB per EternalBlue. Qualora avvenga questo tentativo espressamente chiaro e finalizzato, LECS interviene immediatamente con la contromisura in base al tipo di appliance fisico o virtuale. Non solo, ovviamente anche nel caso statisticamente sfavorevole, ma praticamente devastante dove l’attaccante vada a “colpo sicuro” sul target, evitando scansioni, LECS blocca immediatamente il traffico, evitando quindi non solo che la minaccia completi il suo ciclo. Questo fa si che non solo si quindi che si vada a spezzare la kill-chain, ma evita che la minaccia si muova lateralmente, Impendendo quindi proliferazione ed infezioni ulteriori. Ricordiamo infatti che queste RCE possono essere pericolosissimi vettori di ulteriori malware come ransomware, in quanto permettono di aprire un canale diretta con la rete bersaglio e muoversi liberamente. Con EternalBlue infatti si potrebbe benissimo fare del pivot, ovvero sfruttare l’ host già compromesso per entrare ancora più all’interno della rete, muovendosi contro bersagli molto meno protetti come gli IoT e creando una pericolosissima persistenza difficilmente (se non impossibile) identificabile se non con una misura come LECS, che agisce indistintamente anche contro le altre forme nella quale la minaccia cibernetica può trasformarsi nei casi più gravi e di difficile detection. In blu le fasi dove LECS interviene automaticamente in caso di EternalBlue. La mancanza di misure di controllo all’interno di un’area, avrebbe quindi causato un danno devastante in quanto nessun sistema avrebbe identificato la minaccia, permettendogli quindi di agire in modo indisturbato in milioni di reti aziendali e private. Salvaguardare una rete aziendale da gravi danni semplicemente collegando un device alla rete, è esattamente la nostra mission. Threat Hunting Team Roberto CamerinesiRicercatore appassionato di sicurezza informatica. Certificato eCCPT, eNDP, Sophos. Sviluppatore ed hacker etico, con la missione di estendere la CyberSecurity ovunque. Ideatore del progetto LECS.
LOG4J2 VULNERABILITY “LOG4SHELL” VS LECS
Apache Vulns. CVE-2021-44228, meglio nota come “log4shell” è una vulnerabilità con score CVSSv3: 10 ossia, il massimo livello Critical.E’ critica non solo per l’impatto che può avere sul sistema, ma ovviamente sulla sua estrema diffusione.Tanto per fornire un idea, parliamo di circa 1,2 miliardi di applicativi vulnerabili di ogni genere. Attenzione all’evoluzione Difatti CVE-2021-45046, secondo il NIST: “È stato rilevato che la correzione per l’indirizzo CVE-2021-44228 in Apache Log4j 2.15.0 era incompleta in alcune configurazioni non predefinite.” Breve analisi della min Log4shell affligge un componente specifico basato su Java, nello specifico di Log4j, nelle sue versioni 2.0 fino alla 2.14.1, che utilizza l’interfaccia JNDI (Java Naming and Directory Interface) per la gestione dei LOG. Nello specifico, durante la fase di generazione dei LOG, sono utilizzati tag ben specifici, e proprio grazie a questo vettore che è possibile innescare l’esecuzione di codice arbitrario sfruttando queste stringhe non gestite.Siamo quindi nel pieno della classificazione di minacce RCE, ovvero “remote code execution”.Infatti log4shell non necessita di autenticazioni o interventi dall’interno del sistema bersaglio e siamo ben lontani dal phishing ed dagli attacchi mirati all’utente: qui infatti l’attaccante mira direttamente all’infrastruttura, sparando quasi a colpo sicuro.Eseguire exploit di questa vulnerabilità apre scenari di attacco incredibilmente efficaci.Difatti potrebbe essere sfruttati di Actor Threat impotranti per mettere a segno colpi nel giro di poco tempo, compromettendo il sistema prima che vengano patchati, con una facilità quasi disarmante.Ad esempio, nulla vieta ad un malware ben progettato di sfruttare questa vulnerabilità in autonomia e procedere a generare reverse shell su altri server ed effettuare una proliferazione massiva di infezione ed accessi a livelli interni della rete, prima maggiormente raggiungibili. Cosa fare Direttamente si può provare su sistemi linux: sudo egrep -I -i -r ‘$({|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^n]+’ /var/log oppure qualora fosse offuscato: sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$\{jndi:(ldap[s]?|rmi)://[^\n]+’ Su sistemi Windows invece, riportiamo una guida: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ LECS, grazie agli aggiornamenti rapidi e modulati pensati da Tiresia, permette di supportare attivamente ed efficacemente la mitigazione la minaccia sia in termini di detection e contro futuri prossimi pattern di attacco che possano sfruttare che in termini di proliferazione. Andiamo nel dettaglio.Di base la CVE infatti è relativa alla vulnerabilità, poi come viene sfruttata rimandiamo chiaramente èall’abilità dell’attaccante ed al modo di muoversi all’interno di una rete compromessa.Durante la kill-chain di un attacco, le minacce evolvono e lasciano tracce “laterali”.Pertanto il sistema LECS, è efficace in due sensi contemporaneamente, sia nella detection diretta che in quella indiretta.Difatti in ambienti LAN, durante la ricognizione, scansioni contro porte web e web ssl sono già un primo monito di ricognizione.Questo perché ovviamente per innescare lg4s, è necessario avere servizio http ed https attivi.Questo già innesca immediatamente allarmi. Ora, l ‘attaccante trovando un server Apache tenterà l’invio della richiesta malformata. Tale richiesta è generalmente identificabile tramite la regex (rif. GitHub – log4shell): \${(\${(.?:|.?:.?:-)(‘|”|)*(?1)}*|[jndi:lapsrm]('|"|)}*){9,11} al quale LECS rilevando tale pattern specifico, attiva immediatamente la contromisura. Questo fa si che non solo si va a spezzare la kill-chain, ma evita che la minaccia si muova lateralmente, impendendo quindi proliferazione ed infezioni ulteriori.Ricordiamo infatti che queste RCE possono essere pericolosissimi vettori di ulteriori malware come ransomware, in quanto permettono di aprire un canale diretta con la rete bersaglio e muoversi liberamente.Con log4shell si potrebbe benissimo fare del pivot, ovvero sfruttare l’ host già compromesso per entrare ancora più all’interno della rete, muovendosi contro bersagli molto meno protetti come gli IoT e creando una pericolosissima persistenza difficilmente (se non impossibile) identificabile se non con una misuracome LECS, che agisce indistintamente anche contro le altre forme nella quale la minaccia cibernetica può trasformarsi nei casi più gravi e di difficile detection. In blu le fasi dove LECS interviene automaticamente in caso di log4shell. Roberto CamerinesiRicercatore appassionato di sicurezza informatica. Certificato eCCPT, eNDP, Sophos. Sviluppatore ed hacker etico, con la missione di estendere la CyberSecurity ovunque. Ideatore del progetto LECS.