📸 E se qualcuno potesse ricostruire le trasmissioni in realtime della tua webcam senza neanche hackerarla? In un recente studio congiunto pubblicato da due università americane e un’università cinese, i ricercatori hanno scoperto EM Eye, una vulnerabilità legata allo spettro elettromagnetico che consentirebbe un attacco side-channel in grado di permettere la ricostruzione di flussi di immagini ad alta qualità da telecamere integrate avendo a disposizione solo un’antenna, un SDR e un notebook, senza dover accedere fisicamente al dispositivo! 💥 Gli esperimenti dimostrano che gli attacker possono tecnicamente catturare attraverso i muri il segnale digitale da oltre 2 metri di distanza, riuscendo ad esempio a spiare le fotografie degli smartphone, delle dashcam, finanche immagini trasmesse dalle telecamere di sicurezza IoT. 🔍 Lo studio rivela come dalle emissioni EM involontarie generate dalle proiezione di immagini digitali trapelino informazioni visive, consentendo potenzialmente un’intera nuova classe di attacchi in stile TEMPEST. La buona notizia? Il documento propone anche contromisure a basso costo per mitigare questa minaccia informatica. 📢 Una lettura obbligata per tutti i professionisti della sicurezza informatica, i progettisti di hardware ed i sostenitori della Privacy, poiché gli attacchi a livello fisico sono tra i più insidiosi da contrastare.
Testare il livello di sicurezza informatica di architetture e sistemi OT (Operational Technology, ossia l’informatica e l’elettronica che hanno a che farecon gli impianti industriali) risulta estremamente più complicato rispetto al testing dei tradizionali sistemi ICT, poiché non esistono molti simulatori OT flessibili e gratuiti.
Senza gli strumenti e gli ambienti di testing più appropriati, già solo nel settore ICT risulta oneroso: – analizzare le API più critichee monitorarne minuziosamente chiamate e risposte tramite SIEM – selezionare in maniera oculata gli eventi di sicurezza informatica, analizzarli, custodire e garantire l’integrità dei log di Microsoft Windows – analizzare in tempo reale gli eventi di switch Cisco – gestire scrupolosamente i Syslog di sistemi Linux/Unix – monitorare gli eventi di firewall, IDS/IPS, access point, proxy, sistemi Radius e quant’altro – ricreare le configurazioni dei sistemi in produzione
Per il settore OT 🪖, il discorso si complica giacché: – non è così scontato avere a disposizione un ambientedi test fisico comprensivo di tutti i componenti (presenti invece in produzione) che è necessario testare e monitorare – hai i pezzi di ricambio completi? – gli apparati e i sistemi usati nel mondo industriale sono costosi, spesso carenti di connettività tradizionale e complicati da installare localmente – anche avendo budget, una copia speculare dell’hardware in produzione non è sempre disponibile per i test (chi paga se i nostri penetration test o vulnerability assessment dovessero inavvertitamente causare danni fisici agli impianti o agli operai che li utilizzano?)
💡 Pochi giorni fa è stato lanciato Labshock, un laboratorio virtuale ICS gratuito. Molti utenti lo hanno installato, e dopo svariati test non hanno riscontrato (almeno per il momento) bug critici.
🟢 Cos’è Labshock? È un laboratorio virtuale per l’apprendimento di sistemi ICS e OT. Costituito da una piattaforma versatile sia per la configurazione che per il testing avanzato, emula sistemi ICS consentendo di: – mettere in pratica tecniche di rilevamento e risposta ad attacchi informatici industriali – configurare PLC – apprendere meglio le reti e i sistemi ICS – esplorare sistemi SCADA – emulare PLC multivendor – effettuare in sicurezza il pentesting e il monitoraggio di sistemi OT – creare e testare regole di correlazione per minacce informatiche industriali usando SIEM OT
🌟 Requisiti tecnici: [RAM] SCADA 150 MB, PLC 80 MB, router 1 MB [CPU] occorre limitare individualmente le risorse per ogni servizio [HDD] piccolo come un singolo file di un film o di una VM
Sei interessato a formazione o a simulare scenari di breach attraverso LabShock? Contattami!
LogonTracer è uno di quegli strumenti Open Source che non dovrebbe mai mancare nell’arsenale di chi s’occupa di Incident Response e/o di Digital Forensics (DFIR)
Questo software analizza gli eventi correlati agli accessi (logon andati a buon fine), associa gli hostname (e/o gli indirizzi IP) e gli account correlati visualizzandoli in un grafico schematico: in questo modo è possibile vedere in quale account si verifica il tentativo di accesso, e quale host viene utilizzato. È davvero utile per controllare rapidamente gli account compromessi in contesti MicrosoftAD (Active Directory) aziendali.
Nei grafici generati da LogonTracer ogni indirizzo IP, così come ogni hostname, viene rappresentato da un nodo avente delle connessioni (che rappresentano l’ID dell’evento) all’altro nodo (utente). LogonTracer consente quindi di filtrare, cercare ed esportare risultati, visualizzare la cronologia, e molte altre funzionalità.
Utilizza anche PageRank, il modello Hidden Markov e ChangeFinder per rilevare host ed account dannosi analizzando l’Event Viewer.
È anche possibile visualizzare i registri eventi in ordine cronologico:
Valido strumento da affiancare all’utilizzo di un SIEM (attenzione: da affiancare, non con cui sostituire!), puoi scaricarlo gratuitamente dalla pagina ufficiale del tool.
🔴 Attenzione: rammenta di abilitare l’audit su ogni workstation su cui desideri analizzare le attività di accesso (Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Logon, Audit Special Logon, Logoff)
Vero, ci sono già HackTheBox, i lab e le certificazioni del SANS Institute, così come le certificazioni e i lab di OffSec… indubbiamente ottimi lab per esercitarsi col penetration testing in ambito Microsoft, ma hanno un loro costo, e soprattutto una loro scadenza.
Se invece vuoi farti un po’ le ossa gratuitamente, puoi usare GOAD: un laboratorio virtualizzato (giunto alla versione 3 (v3) nel momento in cui sto scrivendo) comprensivo di svariati scenari Active Directory (domini e foreste, piccole, medie, grandi realtà ecc..) volutamente vulnerabili.
Scenario GOAD comprensivo di 5 VM, 2 foreste e 3 domini (full goad lab) volutamente vulnerabili ad attacchi informatici
Inizia oggi, 1 dicembre 2024, il periodo (che terminerà il 28 febbraio 2025) per iscrivere le organizzazioni soggette alla direttiva NIS2, pubbliche e private, sulla piattaforma messa a disposizione dall’Agenzia per la Cybersecurity Nazionale. La registrazione in questione è quella prevista dal primo comma dell’art. 7, D.Lgs. 138/2024. Nonostante in tale norma sia specificato che la registrazione può essere effettuata dal 01 gennaio al 28 febbraio di ogni anno successivo all’entrata in vigore della direttiva NIS2, in fase di prima applicazione è previsto che la registrazione possa avvenire a partire dalla data di pubblicazione della piattaforma (art. 42, comma 3, D.Lgs. 138/24) ergo dal 1 dicembre 2024.
Per associare il punto di contatto al soggetto è necessario indicare: – per le pubbliche amministrazioni, il codice IPA – per i soggetti pubblici e privati, il codice fiscale. Il punto di contatto dovrà caricare il titolo giuridico che lo abilita ad operare per conto del soggetto nel contesto NIS (a meno che non sia il rappresentante legale o un procuratore generale). Il processo di censimento del punto di contatto e l’associazione al soggetto NIS si conclude con l’invio di un link di richiesta di convalida al domicilio digitale del soggetto stesso. La dichiarazione che il punto di contatto dovrà compilare è suddivisa in 4 sezioni: – contesto – caratterizzazione – tipologie di soggetto – autovalutazione
Dopo aver compilato la dichiarazione, il punto di contatto dovrà prendere visione del riepilogo delle informazioni fornite, accettare le clausole di responsabilità e trasmettere la dichiarazione all’Agenzia. Una copia della dichiarazione verrà inviata al domicilio digitale del soggetto.
Requisiti tecnici e metodologici delle misure di gestione dei Rischi in ambito Cybersecurity.
Il documento è indirizzato ai fornitori di servizi DNS, ai registrar di primo livello, ai fornitori di servizi di Cloud Computing, ai fornitori di data center, ai fornitori di reti di distribuzione dei contenuti, ai fornitori di servizi di sicurezza informatica gestiti, ai fornitori di e-commerce, ai motori di ricerca on-line, ai fornitori di piattaforme di servizi di social network e, ultimi ma non da meno, ai prestatori di servizi fiduciari (eIDAS).
Se la tua organizzazione non rientra direttamente in queste categorie, risulta comunque interessante leggerlo poiché fornisce una panoramica dei requisiti e delle policy di sicurezza informatica che chi opera in quei settori deve rispettare. La prima policy?
Considerando n.3: a norma dell’articolo 21, paragrafo 5, terzo comma, della direttiva (UE) 2022/2555, i requisiti tecnici e metodologici delle misure di gestione dei rischi di Cybersecurity di cui all’allegato del presente regolamento si basano su norme europee e internazionali, quali ISO/IEC 27001, ISO/IEC 27002 ed ETSI EN 319/401, e su specifiche tecniche, quali CEN/TS 18026:2024, pertinenti per la sicurezza dei sistemi informativi e di rete.
Quindi? I requisiti tecnici e metodologici sono descritti nell’allegato (ho inserito il link alla fine di questo articolo), e tra questi è possibile trovare:
1 Policy di sicurezza informatica dei sistemi informativi e di rete [art.21.2a NIS2] 2 Policy di gestione dei rischi [art.21.2a NIS2] 3 Gestione degli incidenti informatici [art.21.2b NIS2] 4 Continuità operativa e gestione delle crisi [art.21.2c NIS2] 5 Sicurezza della catena di approvvigionamento (“Supply chain security“) [art.21.2d NIS2] 6 Sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete [art.21.2e NIS2] 7 Strategie e procedure per valutare l’efficacia delle misure di gestione dei rischi di cybersecurity [art.21.2f NIS2] 8 Pratiche di igiene informatica di base e Formazione in materia di sicurezza informatica [art.21.2g NIS2] 9 Crittografia [art.21.2h NIS2] 10 Sicurezza delle risorse umane [art.21.2i NIS2] 11 Controllo degli accessi [art.21.2i/j NIS2] 12 Gestione delle risorse [art.21.2i NIS2]
Per la prima volta il Regolamento fa riferimento a standard internazionali come ISO 27001:2022, ma attenzione: – la sola certificazione ISO non risolve i problemi che ruotano intorno alla direttiva NIS 2; – la certificazione ISO non è obbligatoria, ma garantisce un impegno; – un Sistema di gestione per la sicurezza delle informazioni (anche non certificato) aiuta il rispetto di misure tecniche e organizzative, che consentano di minimizzare i rischi di Cybersecurity, tramite l’adozione di controlli e l’individuazione di contromisure;
Ma soprattutto: DIFFIDA di CHIUNQUE ti PROMETTA il BOLLINO BLU per la direttiva NIS2 solo se ACQUISTI il suo CORSO! Per diventare compliance alla direttiva occorrono tempo e denaro, occorrono verifiche tecniche approfondite, spesso reingegnerizzazione dei sistemi informativi, e consulenze erogate da professionisti con reali e pluriennali esperienze in ambito Cybersecurity (non fidarti del primo sedicente consulente con cui entri in contatto: prova a chiedergli se ha mai gestito un incidente informatico, e come lo ha fatto… potresti scoprire che molti consulenti in ambito GDPR e NIS2 sono solo persone che hanno sostenuto un esame di certificazione ISO “qualcosa”, ma con scarsa o insesistente esperienza tecnica in ambito Cybersecurity).
Link al regolamento (disponibile in 27 lingue, tra cui anche l’italiano)
Un mio conoscente lavora in uno studio di ingegneria civile, dove si occupano di progettazione: mi ha contattato di recente poiché nel loro ufficio hanno ricevuto un’email dalla società Autodesk in cui sono stati avvisati (ma il mio conoscente così come i suoi colleghi ne erano già al corrente!) che la versione di Autocad che stavano utilizzando su tutti i pc dello studio era sprovvista di regolare licenza (nel gergo tecnico ci si riferisce a software crackato).
Attraverso l’email, Autodesk ha “gentilmente” avanzato ai legali dello studio la richiesta di 15000€ per il tempo di utilizzo del software Autocad già trascorso e quello futuro, pena la disattivazione perenne da remoto del software (leggi blocco e impossibilità di ulteriore utilizzo delle varie copie di Autocad operative nello studio).
Mi è stato chiesto: ma Autodesk può farlo? Tecnicamente, accettando le condizioni contrattuali durante l’installazione del software, di fatto si autorizza Autodesk a condurre verifiche da remoto (ed ho riferito al mio interlocutore che personalmente trovo il comportamento della software house più che lecito). Viceversa, se legalmente possano o non possano farlo, ossia bloccare da remoto un software privo di licenza comunicando quello che di fatto è stato un ultimatum, è una pastoia legale che lascio volentieri ai veri esperti in Diritto dell’Informatica (avvocati praticanti, o almeno si auspica) . Concludendo, al mio conoscente – ma soprattutto al suo responsabile che anni addietro decise di autorizzare le installazioni pirata – tecnicamente ho suggerito alcune dritte per evitare il blocco da remoto, ma non ho dato seguito alle modifiche sulle postazioni dello studio poiché personalmente sono assolutamente d’accordo con Autodesk: se il software che si decide di installare nasce come commerciale (da non confondere, quindi, con i gratuiti software muniti di regolare licenza FOSS), andrebbe regolarmente pagato, ergo acquistato, non crackato, così come andrebbero sempre remunerate le attività di manutenzione e/o le consulenze fatte da programmatori, sistemisti o esperti di sicurezza informatica di cui ci si avvale, a meno che questi signori non lavorino gratis per i propri committenti. Questa propensione (tremendamente italiana) ad avvalersi disoftware crackato è vergognosa e pericolosa, soprattutto perché molto spesso gli utilizzatori finali (architetti, ingegneri, progettisti meccanici o elettronici solo per citare il mondo Autocad) lavorano pressorinomati studi che possono eccome permettersi l’acquisto di qualche licenza software in più: quello che invece accade più o meno regolarmente, a mio avviso, è che in Italia molte aziende e tantissimi utenti decidono di non farlo, ossia scelgono anticipatamente di barare installando software pirata o (che dir si voglia) crackato con il beneplacito del tecnico informatico di turno, solo che questa gente dimentica chela malìzia non è una Virtù ma un vizio: come tutti i vizi, prima o poi qualcuno viene a chiedere il conto ai trasgressori.
Pessima idea quella di usare software crackato in azienda (sotto diversi punti di vista: etici, legali ma soprattutto dal punto di vista della (in)sicurezza informatica) ma se proprio non puoi farne a meno, come minimo assicurati di installarlo e utilizzarlo all’interno di una VM isolata dalle altre postazioni della tua rete LAN, altrimenti la prossima rete hackerata da un ransomware potrebbe essere proprio la tua.
In Italia, informaticamente parlando (ma anche sotto altri aspetti), tutto (il peggio) è possibile: anche che la Giurisprudenza debba ribadire l’ovvio, lo scontato, il lapalissiano, esattamente come il titolo di questo articolo. Dovrebbe essere una verità inequivocabilmente scontata e palese per tutti, ma evidentemente non lo è se una sentenza della Suprema Corte (sent. n. 50205) ha confermato la condanna penale di un dirigente che aveva utilizzato le credenziali di accesso di un suo “sottoposto” per accedere al sistema informatico aziendale.
🔑 i FATTI: – il dirigente si era fatto comunicare le credenziali di un collaboratore – aveva utilizzato queste credenziali per accedere a circa 90.000 schede individuali – riteneva (a torto) che la sua posizione gerarchica lo legittimasse a tale comportamento
⚠️ PRINCIPIO stabilito dalla Suprema Corte: – La posizione di superiore gerarchico NON autorizza l’accesso ai dati tramite credenziali altrui: questo comportamento integra il reato di ACCESSO ABUSIVO a SISTEMA INFORMATICO (art. 615-ter c.p.)
📋 CONSEGUENZE PRATICHE per AZIENDE e ORGANIZZAZIONI: – Ogni dipendente deve avere CREDENZIALI PERSONALI e non cedibili; – Le DELEGHE di ACCESSO devono essere espressamente AUTORIZZATE; – Va implementato un SISTEMA di PROFILAZIONE UTENTI con diversi LIVELLI di AUTORIZZAZIONE; – Occorre una POLICY AZIENDALE chiara sulla GESTIONE delle CREDENZIALI; – Rischio di responsabilità penale per i TRASGRESSORI.
💡 AZIONI da intraprendere: – Revisione tempestiva delle policy di accesso ai sistemi ICT; – Implementazione di protocolli di sicurezza informatica (AUTENTICAZIONE, PROFILAZIONE, AUTORIZZAZIONE e PROTEZIONE) adeguati; – Formazione specifica del personale; – Vulnerability Assessment e Audit dei sistemi; – Adeguamento dei modelli organizzativi al GDPR.
Come ripeto spesso ai miei studenti e contatti professionali, la sentenza (una delle tante) sottolinea come la Cybersecurity non sia solo una questione tecnica, ma anche legale, con rilevanti profili di responsabilità penale (a questo indirizzo, chi fosse interessato può reperire e leggere la sentenza con calma)
Durante una visita ospedaliera fuori regione, annoiato tra un’attesa e l’altra, attraverso alcune scansioni di rete ho riscontrato una preoccupante malagestione nella rete Wi-Fi del policlinico. La segmentazione delle reti, che generalmente dovrebbe garantire un isolamento dei dispositivi interni da quelli esterni, risultava inadeguata: ho riscontrato che dispositivi di norma riservati al personale ospedaliero, come stampanti con firmware non aggiornato nonché fileserver, erano accessibili dalla rete Guest (tipicamente la rete WLAN dedicata alle utenze dei visitatori e pazienti di una struttura ospedaliera) semplicemente variando la subnet mask sul mio scanner di rete. Questo scenario rappresenta un rischio per la sicurezza informatica della rete ospedaliera, poiché l’assenza o la carenza di una efficace segregazione tra le reti pubbliche e quelle interne può esporre l’infrastruttura ospedaliera ad attacchi informatici.
In un contesto come quello sanitario, dove le reti informatiche sono già di per sé un’infrastruttura critica, trascurare la Cybersecurity può avere conseguenze ragguardevoli. Dispositivi non aggiornati o direttamente vulnerabili possono diventare una facile preda per attacchi ransomware, che possono compromettere la continuità dei servizi essenziali, mettendo a rischio la sicurezza fisica dei pazienti nonché le capacità operative dell’ospedale.
Le immagini qui sopra fanno riferimento a delle stampanti in rete: ma cosa succederebbe se gli attacker prendessero di mira i PLC usati dall’ospedale, che pure erano raggiungibili attraverso la medesima sottorete delle stampanti? (e che per carità divina ho evitato di postare!)
dmzware.com 