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.
2025 – La nuova normativa europea NIS2: cosa cambia per la sicurezza informatica in Italia
Dal 16 ottobre 2024 è entrato in vigore il decreto NIS (Network and Information Security), che ha l’obiettivo di rafforzare la sicurezza informatica di aziende e pubbliche amministrazioni in tutta Europa. Scopriamo insieme quali sono le principali novità, chi è coinvolto e quali obblighi ne derivano per le aziende italiane. Obiettivi e nuovi obblighi della normativa La normativa NIS ha un obiettivo chiaro: elevare gli standard di sicurezza informatica, promuovendo una cooperazione efficace tra gli Stati membri e assicurando che le infrastrutture digitali siano pronte ad affrontare minacce sempre più sofisticate. Rispetto al passato, la nuova versione amplia il campo d’azione, includendo un numero maggiore di settori e categorie di aziende considerate essenziali o strategiche. Ora, le imprese e le amministrazioni coinvolte devono adottare misure di sicurezza che coprano tutte le dimensioni della cyber security: riservatezza, integrità e disponibilità dei dati. Inoltre, la normativa introduce un sistema di notifica più tempestivo per segnalare eventuali incidenti, così da favorire una risposta rapida e coordinata. Un elemento di novità è anche la divulgazione coordinata delle vulnerabilità, che permette di affrontare in modo condiviso le minacce emergenti. Ambiti di applicazione e obblighi per le aziende La nuova normativa NIS amplia il suo raggio d’azione. comprendendo ora 18 settori totali rispetto agli 8 precedenti e distinguendo tra settori altamente critici e critici, ampliando notevolmente il suo campo d’azione: Settori altamente critici (già presenti e aggiornati): energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, settore sanitario, acqua potabile, acque reflue, infrastrutture digitali. Nuovi settori altamente critici: spazio, gestione dei servizi TIC (b2b), gestione dei rifiuti Nuovi settori critici: servizi postali e di corriere, fabbricazione, produzione e distribuzione di sostanze chimiche, produzione alimentare, fabbricazione industriale, fornitori di servizi digitali, ricerca. Questo ampliamento rispecchia la necessità di garantire una sicurezza informatica più estesa, coprendo oltre 80 tipologie di soggetti pubblici e privati. Quali sono i tempi da rispettare per essere conformi? A partire dal 1° dicembre 2024, tutti i soggetti coinvolti devono registrarsi sul portale dell’Agenzia per la cybersicurezza nazionale (ACN), che funge da autorità di riferimento per l’applicazione della normativa. Questa fase di registrazione è solo il primo passo di un percorso di rafforzamento della sicurezza che continuerà nei mesi successivi. Gli obblighi relativi alla notifica degli incidenti e all’adozione di misure di sicurezza saranno introdotti gradualmente e definiti attraverso le decisioni del Direttore Generale di ACN, sulla base delle consultazioni settoriali. Le disposizioni complete sono attese entro il primo quadrimestre del 2025. Sarà previsto inoltre un periodo di implementazione differenziato: le aziende avranno 9 mesi per adeguarsi agli obblighi di notifica e 18 mesi per adottare le misure di sicurezza, a partire dalla data in cui sarà consolidato l’elenco dei soggetti NIS, fissata per aprile 2025. Da quel momento, prenderà il via un percorso coordinato per rafforzare la sicurezza informatica a livello nazionale. Gestione del rischio e responsabilità aziendale La gestione del rischio è uno degli elementi centrali della nuova normativa, che punta all’adozione di un approccio proattivo: non solo protezione delle reti, ma anche capacità di reagire rapidamente in caso di crisi. Un altro aspetto fondamentale è la responsabilità aziendale, che diventa ancora più stringente. Le imprese devono rispettare obblighi di comunicazione chiari e adottare misure di sicurezza per l’intera catena di fornitura. Il mancato rispetto delle norme può comportare sanzioni significative, mentre la supervisione dell’ACN garantisce un monitoraggio costante per verificare la conformità. La tua azienda rientra tra i soggetti coinvolti? Contattaci per una consulenza gratuita e scopri come possiamo supportarti ad essere conforme alla normativa. Webeing