Blog

hacking

Playing with TOR

Durante la preparazione di alcuni laboratori per un workshop sulle simulazioni di attacco ho approfondito alcuni aspetti del funzionamento della rete ToR, quei dettagli che capita di leggere ma più raramente di toccare con mano fino a quando non se ne ha l’occasione. Mi piaceva l’idea di riassumere in un post le sessioni di gioco con la rete Tor ed un paio di utilizzi che penso possano essere utili nello svolgimento di attività offensive, ovviamente in contesti autorizzati.

installazione ed avvio del servizio Tor

Nota ovvia: il contenuto del post ha finalità divulgative al fine di condividere alcuni aspetti del funzionamento della rete Tor così da acquisire una maggiore consapevolezza dello strumento che, come tutti gli strumenti, può essere utilizzato anche per fini illeciti e proprio a tal proposito è bene saper riconoscere eventuali attività sospette eseguite attraverso questa rete.

Non è un how-to, per chi ha bisogno di una infarinatura ci sono moltissimi articoli che potete prendere in considerazione:

Lab setup

Un minimo di infrastruttura per utilizzare il servizio. Per praticità utilizzo la mia kali box, ma potete ovviamente utilizzare quello che vi pare. L’installazione è semplicissima (vedi screenshot ad inizio post) ed una volta avviato il demone il servizio sarà immediatamente disponibile sulla local port 9050.

Per fare un po’ di esperimenti assicurarsi di disporre anche dei seguenti software:

  • apache2 + php
  • wget / curl
  • ssh-ping
  • tor-browser

Oltre alla kali locale ho utilizzato un web server remoto per eseguire alcune prove, nel mio caso si tratta di un semplicissimo LAMP basato su Ubuntu (LTS) con esposto il servizio http ed ssh su porte non standard.

Onion Site

Obiettivo del test era osservare log e traffico di un nodo Tor su cui è attivo un Onion Site, la prima cosa da fare è quindi configurare un il sito cipolla.

Premessa: i domain name .onion funzionano in modo diverso rispetto ai domain name che popolano la rete internet: un onion name corrisponde all’identità (univoca) di uno specifico nodo (vedi rfc 7686). In parole povere un onion name si riferisce specificatamente all’host su cui risiede il servizio in qualità di nodo della rete Tor.

Per configurare un “sito cipolla” è sufficiente accedere al file di configurazione di Tor in /etc/tor/torrc e definire la configurazione del servizio dichiarando il path per i file di configurazione. Viene inoltre dichiarata la porta del servizio da non interpretare come un sistema di pubblicazione: il servizio Tor si limiterà ad eseguire l’inoltro dei pacchetto in ingresso sulla porta 80 (visto che voglio intercettare il traffico http) vero il web server attivo sul sistema (apache2) precedentemente installato durante il setup del laboratorio.

configurazione base per un “sito cipolla”

Il mio apache non ha nessuna specifica configurazione, anzi è praticamente in configurazione di default ed il contenuto pubblicato è molto semplice, si tratta infatti di un PHP file che esegue la print dell’IP del client che accede al contenuto:

Nel mio caso la macchina è una guest con un IP dietro un primo NAT per accedere alla rete locale tramite l’host (la mia workstation) e dietro un secondo NAT per accedere alla rete internet tramite la mia connettività. Il server non esegue quindi nessun tipo di pubblicazione di servizi verso la rete internet mentre è raggiungibile dalla mia LAN tramite il NAT del software di virtualizzazione. Per chiarire riporto uno schema di sintesi:

labz

Accedendo quindi al contenuto direttamente dalla guest o dalla mia workstation il sistema potrà registrare nei log l’IP del client che ha eseguito l’accesso al web server nel solito file /var/log/apache2/access.log.

Avviando il servizio Tor sulla VM hidden-server verrà generato l’indirizzo del sito .onion ed il demone si occuperà di intercettare le richieste verso la porta 80 in arrivo dalla rete Tor verso la porta 80 del servizio di pubblicazione HTTP.

Per simulare il comportamento di un utente che, attraverso la rete Tor, invii una richiesta GET ai contenuti del sito cipolla è sufficiente predisporre un ToR browser sulla workstation (o su un altro sistema esterno) così da ottenere il comportamento di un qualsiasi Tor user che voglia accedere al contenuto appena pubblicato. L’indirizzo del sito cipolla è disponibile all’interno del file /var/lib/tor/hidden_service/hostname, nel mio caso:

Per capire meglio cose sta accadendo sul sistema che ospita l’onion site ho verificato come prima cosa lo status delle connessione della macchina. Con i servizi apache e Tor attivi lo status delle connessione presentava poche e ben definite sessioni.

Sulla porta 9050 della loopback è ovviamente in ascolto il demone Tor utilizzabile dal mio client come socks host. Già dalla seconda riga la cosa si fa interessante: il mio host contatta dal proprio IP in LAN il sistema 185.243.218.27 che, ricerche alla mano, è un ToR Node che fa riferimento a questo progetto: https://tuxli.ch/. Verificando il comportamento delle sessioni e la descrizione dei servizi offerti da questo nodo, devo dedurne che si tratti del DirNode selezionato dal server per scaricare la lista dei Relay, inoltre il nodo stesso offre servizi di Relay. Ultimo dato utile è nella terza linea con il binding del servizio apache2 sulla porta 80, questo è il servizio che viene contattato, in definitiva, da un client che vuole accede al contenuto che il sito sta pubblicando. In un contesto standard vedremmo quindi una sessione tra il server ed il client in un formato del tipo:

{LocalIP}:80 <---> {RemoteIP}:{ClientPort}

Avviando il Tor browser su un altro host ed accedendo al sito cipolla già configurato possiamo osservare meglio il comportamento del demone ToR nel consentire l’accesso ai contenuti:

Quello che accade è abbastanza chiaro: il Tor browser non compare tra i client in quanto la richiesta arriva al server all’interno della sessione già attiva con il Relay Node (182.243.218.27) e si presenta come una richiesta interna del sistema (127.0.0.1:46660) verso il servizio http apparentemente binded sulla stessa loopback (127.0.0.1:80). Questa sessione si riferisce in realtà al forward dei pacchetti eseguito dal demone Tor verso apache. Questo spiega anche come mai nell’access.log di apache compare l’IP 127.0.0.1 come client.

Secure ssh access

Qualcosa di simile a quanto fatto con la pubblicazione http è possibile farlo con ssh: in questo caso l’obiettivo molto operativo che volevo ottenere era una modalità di accesso via ssh ad un server all’interno della rete Tor.

Il vattoggio è relativamente chiaro: tenendo attivo il mio server all’intero della rete e configurando opportunamente il demone Tor potrò garantirmi un accesso in ssh alla mia macchina senza esporre il servizio ad internet nascondendo di fatto il sistema. Da questa posizione posso poi raggiungere altri sistemi anche all’esterno della rete Tor ma comunque attraversandola.

Lo scenario di base è identico al precedente con qualche aggiunta, in particolare sul server “nascosto” bisognerà necessariamente installare ed avviare il demone ssh ma, come per http, non sarà necessario eseguire un NAT sulla rete internet in quanto la raggiungibilità del servizio verrà affidata alla rete Tor. Il file di configurazione coinvolto è sempre /etc/tor/torrc in cui, poche righe sotto la configurazione del servizio http, vi sono le configurazioni per gli “altri servizi nascosti”:

Nel caso specifico, con la configurazione riportata nello screenshot, stiamo istruendo Tor ad inoltrare il traffico in arrivo sulla porta tcp\22 verso il servizio in ascolto sulla medesima porta del server. Nel file /var/lib/tor/other_hidden_service/hostname è riportato l’indirizzo .onion per raggiungere il servizio nascosto all’interno della rete. Una volta completata la configurazione potremo collegarci alla macchina in ssh puntando al sito cipolla corrispondente. Ovviamente il sistema da cui si vorrà eseguire la connessione dovrà essere a sua volta connesso alla rete Tor. Il comando è quindi semplicissimo:

torify ssh sheliak@{sitocipolla}.onion

Una volta avviata la connessione è molto probabile riscontrare una carta latenza nella risposta, si tratta di un effetto collaterale inevitabile in quanto i pacchetti che i due sistemi si scambiano stanno attraversando un minimo di tre Tor Node e ad ogni hop corrispondono operazioni di cifratura/decifratura. Tutto ciò introduce latenza nelle comunicazioni. Quanta?

ssh-ping verso il servizio ssh nascosto

Una volta ottenuto l’acceso al sistema, esattamente come visto per http, noteremo che i servizi di destinazione si vedono arrivare richieste di accesso dall’interfaccia di loopback. Quindi se eseguiamo delle verifiche su chi è connesso al sistema con il comando who

A sinistra la sessione ssh via Tor, a destra una console locale

… l’output mostrerà la sessione locale ed una sessione remota da 127.0.0.1 a testimoniare il nostro accesso “anonimo” quanto meno a livello di IP.

Conclusioni e riflessioni

Il mio interesse specifico in questo laboratorio ruotava attorno all’esigenza di comprende meglio il funzionamento della rete Tor per valutare come sfruttarla in simulazioni di attacco e qualche idea me la sono fatta. Non sono da meno gli spunti a livello di incremento della sicurezza sfruttando i servizi nascosti per amministrare i propri sistemi senza esporli in nessun modo, ne con un NAT ne con una VPN che come ultimamente abbiamo visto è un servizio come gli altri e può avere dei bug.

Capito meglio il funzionamento mi è ben chiaro come si è potuta sfruttare la rete anche per fini illeciti come la creazione di botnet utilizzate per attacchi ad enti ed aziende. Ci sono degli aspetti che mi segno di approfondire in un prossimo lab come la possibilità di eseguire ricerche automatizzate in rete internet attraverso la rete Tor e la possibilità di scambiarsi informazioni e messaggi peer-to-peer.

cyber security, hacking

Vulnerabilità, calcolo del rischio e gestione delle priorità

In più occasioni mi trovo a discutere della differenza nella sostanza tra lo score di una vulnerabilità, rappresentato dal parametro CVSS, ed il rischio ad essa correlata che deve tener conto di diversi elementi del contesto.

L’output standard dei tools di scansione delle vulnerabilità potrebbe facilmente portare a considerare lo score della vulnerabilità come il parametro che determina il rischio. Potrebbe sembrare logico: se la vulnerabilità ha uno score alto significa che è particolarmente grave quindi rischio di più. Come accennavo in questo post è necessario considerare anche l’impatto sul business dell’asset o del servizio su cui è individuata una vulnerabilità: a parità di score una vulnerabilità che affligge un sistema di posta elettronica, per fare un esempio, è ben più impattante di una vulnerabilità che affligge una SmartTV.

Fette le dovute premesse al post passiamo all’operatività partendo dagli strumenti che tipicamente vengono adoperati per eseguire la verifica delle vulneralità, ovvero i tools di scansione. Ne esistono molti, con più o meno funzioni e per tutte le tasche. La funzionalità base comune a tutti i software di scansione è relativa alla generazione di un report che riporti l’elenco degli asset interessati dalla scansione e le vulnerabilità rilevate. Il report porta all’attenzione diversi dati tra cui lo score delle vulnerabilità (CVSS) accompagnato da altri parametri a supporto della comprensione della stessa.

Ultimamente ho avuto modo di operare su due piattaforme molto diverse tra loro: Nessus e Qualys. Al fine di automatizzare parte del processo di rilevamento delle vulnerabilità e calcolo del rischio ho condotto qualche prova di estrazione dei dati per agevolare il processo di creazione del remediation plan secondo una logica “rischio centrica”.

Test API

Entrambi i software, come molti altri, consentono di utilizzare le API per accedere ai report delle scansioni permettendo così di creare semplici script di estrazione ed elaborazione dei dati. Dovendo potenzialmente calcolare il fattore di rischio per decine se non centinaia di vulnerabilità automatizzare almeno una parte del processo è cosa saggia.

La ricetta, come abbiamo visto, è relativamente semplice e si basa su un minimo di due dati oggettivi (CVSS dato dalla scansione e Business Impact dato dall’asset inventory) e un dato analitico che personalmente mi piace aggiungere per avvicinare l’analisi al mondo vero e che potremmo pragmaticamente chiamare appetibilità.

Alcuni tools, come Qualys, consentono di censire dati anche per l’asset oggetto di analisi. In questo caso parametri come il Business Impact possono far parte dei dati base del report e possono essere utilizzati per calcolare un fattore di rischio. Altri tools, come Nessus, riportano i dati relativi alle vulnerabilità che dovranno poi essere analizzati tenendo in considerazione i dati gestiti dal sistema di asset manager.

p-o-c

Ovviamente mettere in relazione i dati provenienti da una scansione con i dati di un tool di asset management non è banale in quanto entrambi i sistemi devono poter mettere a disposizione le informazioni tramite una API. Personalmente credo sia anche il metodo più strutturato per gestire un piano di rimedio in quanto transita per la creazione di un processo di gestione degli asset e relativi strumenti IT.

Dall’altro lato sfruttando opportunamente le funzionalità di tools più ricchi è possibile arrivare ad ottenere, già nel report, un parametro che aiuti a qualificare il rischio. In questo caso il parametro da utilizzare per comporre il remediation plan potrebbe essere presente già nel report ed una volta raccolti i dati si potrà ottenere un elenco per priorità semplicemente “riordinando la lista” partendo dalla coppia host/vulnerabilità che riporta il rischio più alto.

Un ultimo step potrebbe essere quello di generare una notifica per il team IT dove riportare solo le vulnerabilità che risultano avere un fattore di rischio meritevole di considerazione secondo la policy scelta dall’organizzazione per la gestione delle vulnerabilità.

Nella p-o-c ho riportato qualche esempio di accesso alle API di Qualys e Nessus relative ai dati dei report: https://github.com/roccosicilia/sToolz/tree/master/GetVulnReport

cyber security, OT/IoT

Sicurezza dei sistemi industriali e centralizzazione dei controlli (Rif. CVE-2021-33721)

Qualche giorno fa ho avuto modo di analizzare una CVE relativa ad un sistema di gestione delle reti appositamente creato per proteggere i sistemi che compongono una rete industriale, ovvero quel complesso aggregato di sistemi connessi da un lato alle reti IP e dall’altro alle reti OT.

La CVE in questione, datata 10 agosto, notifica la possibilità di eseguire “Command Injection” ai danni del prodotto Siemens Sinec NMS. La cosa interessante è che il prodotto è stato concepito per semplificare la gestione della sicurezza dei dispositivi OT di una rete industriale con specifiche funzionalità di firewalling, asset management, patch management, ecc…

In una rete complessa e ricca di dispositivi, nel mondo IT tanto quanto nel mondo OT, è indispensabile definire procedure e regole per l’aggiornamento e la protezione dei sistemi, se la rete è particolarmente grande o complessa è poco plausibile pensare di fare tutto a manina. Adottare strumenti di gestione centralizzati è quindi del tutto naturale oltre che auspicabile.

In un contesto operativo dove è del tutto normale strutturare sistemi di gestione centralizzati va ancor di più considerato il livello di allerta nella gestione degli asset che ci semplificano la governance in quanto un problema di sicurezza su una piattaforma centralizzata potrebbe generare fastidi e incident di una certa portata.

SINEC wiki Documentation

La CVE in oggetto è un esempio perfetto: stando alla documentazione ufficiale il software è in grado di eseguire la gestione dei sistemi OT attraverso la rete (rif. documentazione Siemens: https://assets.new.siemens.com/siemens/assets/api/uuid:4fc55df6-c6da-4fbc-8112-8a910b668e23/network-management-for-more-network-security.pdf). Vista la tipologia della vulnerabilità descritta anche in una nota del produttore (https://cert-portal.siemens.com/productcert/pdf/ssa-756744.pdf) sarebbe possibile compromettere il sistema di gestione e di conseguenza interferire sull’operatività dei dispositivi stessi.

E’ molto probabile che gli utilizzatori di queste tipologie di software siano in parte dipendenti dal buon funzionamento della piattaforma, ragion per cui il business impact potrebbe essere stato classificato come elevato. Il rilevamento di una vulnerabilità con score elevato come quella riportata in questa CVE deve quindi innescare una immediata reazione di mitigation e remediation in accordo con il piano di gestione delle vulnerabilità che tutti dovremmo avere.

Nel caso specifico la nota di Siemens segnala che non ci sono azioni di mitigation salvo valutare l’applicazione di rules per limitare l’accesso al sistema. E’ però già disponibile una versione che non presenta la falla: SINEC NMS V1.0 SP2 rilasciata il 18 maggio.

La nota di rilascio della v1.0 SP2 da un altro spunto di riflessione: l’update non era classificato come security update, si trattava infatti di un rilascio che riportava nuove funzionalità e miglioramenti al software. Spesso vengono implementati piani di patch management che tendono ad escludere o non dare nessuna priorità agli update e si tende a dar seguito al patching dei sistemi quando si presenta un fix legato alla sicurezza del sistema.

In questo caso questa condotta avrebbe portato ad una involontaria esposizione ad un rischio (anche se non noto) in quanto l’installazione della SP2 avrebbe di fatto prevenuto lo sfruttamento della vulnerabilità segnalata solo tre mesi dopo.

Patch Management e Vulnerability Management sono due procedure che possono convergere ma non sarebbe sano adottare solo una delle due.

cyber security

Fenomenologia del Dark Web: la vendita di dati falsi

In relazione ad un recente e noto attacco informatico ad un ente pubblico italiano ho avuto modo, come molti professionisti e ricercatori del settore, di svolgere qualche analisi per comprende le dinamiche, imparare qualcosa di nuovo e, se possibile, migliorarsi ed aiutare altri a migliorare.

Ieri sera (11/08) ho dedicato un po’ di tempo alla lettura di alcuni canali e siti non fruibili nel di superficie e ho trovato un paio di conversazioni interessanti che qui vorrei analizzare almeno in parte.

In entrambi i casi un utente apriva una richiesta di trading manifestando interesse per i dati potenzialmente sottratti durante il noto attacco. Le conversazioni che ho analizzato iniziano a partire dal 3 agosto e gli scambi sono ancora in corso. Il modello è abbastanza tipico: qualcuno chiede, qualcuno risponde e vengono scambiati dei dati parziali a dimostrazione dell’effettivo possesso delle informazioni.

Ho controllato qualche set di dati tutt’ora disponibili su piattaforme di libero accesso (se si ha il link ovviamente) come Pastebin al fine di verificare la potenziale autenticità delle informazioni. Mi sono limitato ad alcuni controlli semplici che qui espongo.

Profili social

Buona parte dei nominativi ha una o più corrispondenze con profili social sulle principali piattaforme. Ho concentrato alcuni check su LinkedIn per ipotizzare una verosimile età anagrafica e un’area geografica di riferimento.

Codice fiscale

Con il semplice calcolo “inverso” del codice fiscale esposto è possibile verificare banalmente il nome, data e luogo di nascita. I codici fiscali analizzati avevano effettivamente tutti delle corrispondenze da cui si deduce una possibile autenticità o l’utilizzo di un algoritmo per la generazione dei dati ben fatto (non è cosa difficile).

Mobile

L’estratto dei dati riportava anche un riferimento mobile sul quale è possibile eseguire una semplice ricerca a livello di presenza su piattaforme come WhatsApp e Telegram. Molti profili (non tutti) risultano presenti ed i numeri sono effettivamente reali, tutta da dimostrare la corrispondenza con il nominativo immediatamente verificabile sono in pochissimi casi.

Google è tuo “amico”

Ho incrociato i risultati con qualche ricerca a livello web con qualche query strutturata e ne emerge che moltissimi dei dati riportati sono di fatto pubblici, in particolare i numeri di telefono.

Una delle conversazioni su RaidF.

Sommando tutte le informazioni è lecito pensare che questi data set siano stato costruiti ad arte con azioni di scraping, fenomeno che trovo estremamente interessante e da approfondire. Da un lato potrebbe essere il banale tentativo di truffare il truffatore vendendo un falso DB, ma è anche un interessante segnale di “rumore” che può mettere in allarme la vittima in una situazione complicata come quella del ricatto.

Personalmente questo modello mi incuriosisce molto e sarebbe interessante misurare quanti di questi falsi dati vengono scambiati. Interessante anche la facilità con cui è possibile costruire un falso DB verosimile.

In ogni caso questo tipo di scambi è bene monitorarli e soprattutto verificarli (mi sono stati segnalati fior di servizi giornalistici non proprio accurati) anche per comprendere come si è evoluto l’attacco. E’ un’analisi che aiuta a definire nuove strategie di difesa con l’obiettivo di ridurre il rischio e, dovendo comunque fare i conti con l’eventualità dell’attacco, imparare a gestirlo al meglio.

podcast

Gestione delle vulnerabilità: primo episodio podcast

Visto che l’argomento è corposo ho pensato di dar seguito anche con una serie di puntate sul podcast dove, oltre a riprendere le argomentazioni del post, provo a dare una lettura semplificata del tema con qualche esempio in più.

Come per il post preparerò diverse puntate con ritmo settimanale nonostante il periodo sia non particolarmente favorevole (spero ci sia chi ha deciso di staccare un po’).

Il primo episodio, di cui riporto il link, è di fatto introduttivo al tema ed ha come obiettivo la necessità di portare il focus sulla metodologia prima che sugli strumenti.

Il podcast è disponibile qui: https://www.spreaker.com/user/11123272/individuazione-delle-vulnerabilita-attac

cyber security, hacking

Individuazione delle vulnerabilità: attacco e difesa (prima parte)

La gestione delle vulnerabilità è ovviamente un tema ricorrente nelle organizzazione che devono governare infrastrutture IT/OT/IoT dal punto di vista della sicurezza cibernetica. Tutte le componenti, tecnologiche e non, di una organizzazione sono di fatto potenziali target per attacchi atti a raccogliere informazioni o compromettere i sistemi, cosa che, nei contesti di produzione, metto a rischio il funzionamento dell’organizzazione ed in alcuni casi il prodotto stesso (gli smart device sono l’esempio più ovvio).

Negli ultimi giorni ho avuto modo di illustrare alcuni step di attacco ad un collega “temporaneo” (abbiamo “a bordo” un ragazzo in alternanza scuola lavoro con una sincera passione per la tecnologia e la cyber security) e nelle chiacchierate è emerso un elemento che ho visto spesso anche in molti menbri degli uffici IT, compreso il management: di fronte ad un nutrito set di bug e vulnerabilità individuate tramite una o più fonti – non sempre grazie ad una metodologia di gestione del rilevamento delle stesse – si tende al disordine: l’assenza di una procedura definita per la gestione delle vulnerabilità lascia spazio alla propria interpretazione / percezione del rischio e l’organizzazione, se reagisce, lo fa in modo disorganizzato.

Inevitabilmente si tende a correre ai ripari per quanto riguarda le vulnerabilità che sembrano essere quelle più critiche a prescindere dal contesto. E’ vero che le vulnerabilità che consentono lo sviluppo di un attacco diretto sono estremamente pericolose in quanto più semplici — di solito — da sfruttare, ma la contestualizzazione della vulnerabilità può cambiarne sensibilmente il rischio correlato: esporre un sistema con evidenti vulnerabilità che consentono l’esecuzione di codice da remoto (Remote Code Execution) è ovviamente un elemento che rende il target estremamente appetibile, ma se il contesto presenta uno strumento di filtering in grado di riconoscere e bloccare i tentativi di exploiting (come IDP/IPS a livello firewall o un sistema di anti-exploiting a bordo del server) le probabilità che la vulnerabilità sia sfruttabile si riducono enormemente.

Attenzione: si riducono, non svaniscono.

E’ necessario poter correlare una vulnerabilità ad un asset e di quell’asset dobbiamo conoscere il contesto operativo e l’impatto sul business dell’organizzazione.

Dobbiamo necessariamente fare i conti con la realtà ed accettare che non tutte le organizzazioni hanno modo di costruire in tempi rapidi una mappa dei business impact legati agli asset. Inoltre, come accennato, non tutti dispongono di procedure di gestione delle vulnerabilità. Il modello che vorrei quindi proporre in questa mini serie – ed è anche la tesi discussa con il giovanissimo collega – è di approcciare la cosa per gradi mettendoci nella situazione peggiore ma spesso reale di non disporre di un database degli asset e delle loro caratteristiche.

Nota: lo scenario non è in alcun modo da considerarsi sostitutivo alla predisposizione di un processo di asset management e relativi strumenti di gestione. L’obiettivo dell’articolo è ragionare assieme.

Come spesso scrivo nei post e racconto sia nei podcast che di persona, l’approccio dell’attacker è metodico e prevede la qualifica del target per comprendere se esiste una reale convenienza nello sferrare un attacco: costruire un’azione offensiva a scopo estorsione per colpire un piccolo studio professionale è molto diverso rispetto a ciò che comporta la progettazione dello stesso attacco con target una multi nazionale. Cambiano le economie dell’impresa (d’attacco), la possibile revenue, i tempi di realizzazione, ecc. Il modello prevede quindi l’analisi costo/benefici al fine di individuare un target appetibile.

Esistono diversi metodi per individuare target appetibili, uno di questi è legato alle tecnologie in uso dalle organizzazioni. Come avvenuto per recenti attacchi che hanno coinvolto migliaia di organizzazioni, l’attacker può utilizzare una falla nota presente in sistemi e piattaforme largamente utilizzate per costruire campagne di attacco anche massive ma con un vettore molto specifico.

In poche parole si tratta di analizzare le vulnerabilità note di tecnologie che il target utilizza a caccia della falla che potrebbe consentire un accesso ai sistemi in modo relativamente semplice. Ovviamente la quantità di vulnerabilità su cui eseguire questa analisi è enorme ed esistono database utilizzabili sia a fini offensivi che difensivi: di base dobbiamo acquisire un’informazione in relazione alla presenza di tecnologia, all’interno dell’organizzazione, che può essere sfruttata per un attacco informatico.

Esistono meravigliosi tools per verificare se parte del vostro asset presenta delle vulnerabilità critiche: se avete implementato una procedura di Patch Management e/o Vulnerability Management probabilmente subito dopo vi siete dotati di una soluzione software che vi aiuti a governare tale procedure; se avete acquisito la soluzione software ma non avete una procedura ufficiale per la gestione di questi processi, avete un problema di governance e vi suggerisco di affrontarlo rapidamente per non vanificare l’investimento fatto.

Visto che in questa sede parliamo di metodologia e non di tools (per i quali farete le vostre valutazioni) vediamo come possiamo entrare in possesso delle informazioni minime che ci servono per valutare se esiste un reale rischio per la sicurezza dell’organizzazione (se la vediamo dal punto di vista del team che deve difendere l’organizzazione) o una opportunità di business (se la vediamo dal punto di vista dell’attacker). Gli ingredienti sono:

  • elenco asset / tecnologie in uso presso il target
  • elenco vulnerabilità in riferimento alle tecnologie in uso
  • contesto di utilizzo della tecnologia vulnerabile

Partiamo leggeri, non censiamo subito gli asset ma preoccupiamoci almeno delle tecnologie in suo. Esiste una convenzione che ci aiuta a definire, in modo univoco, la tecnologia che stiamo utilizzando: si chiama CPE (Common Platform Enumeration). Senza dilungarmi troppo (di seguito qualche link per documentarvi) si tratta di un metodo standard per identificare uno specifico vendor/prodotto/versione/ecc…

Pagina dedicata di wikipedia: https://en.wikipedia.org/wiki/Common_Platform_Enumeration
Mitre specification: https://cpe.mitre.org/specification/

Un primo step potrebbe essere quindi quello di censire i CPE di riferimento per le tecnologie in uso nella nostra organizzazione: se utilizziamo una specifica versione di Microsoft Windows Vista, ma non ricordiamo esattamente l’update o altri parametri di dettaglio, potremmo annotare nella lista il CPE più generico:

cpe:2.3:o:microsoft:windows_vista:6.0:*:*:*:*:*:*:*

Ovviamente questo elenco dovrà essere mantenuto aggiornato, quindi la versione alpha della procedura di inventory delle CPE dovrà prevedere che ogni nuova tecnologia introdotta/individuata nell’organizzazione dovrà essere censita in questa repository.

Una volta gestito questo patrimonio di informazioni (utile per fare una montagna di altre attività virtuose) nel modo più automatizzato ed efficiente possibile, possiamo andare ad analizzare un altro dataset interessante ben più noto dei CPE, ovvero i CVE: Common Vulnerability Enumeration. Esistono diversi siti ed organizzazioni che mettono a disposizione un database con l’aggregato delle CVE rilasciate per i vendor, c’è l’imbarazzo della scelta. Per questo piccolo esperimento utilizziamo una API di https://cve.circl.lu/ che consente di richiedere le ultime 30 CVE pubblicate in formato json.

Esempio di lettura delle CVE tramite API

All’interno di una CVE trovate le informazioni sulla vulnerabilità compreso lo score e le CPE vulnerabili, ovvero l’elenco delle versioni software (talvolta in combinazione con specifici hardware) che presentano la vulnerabilità.

Siamo arrivati all’epilogo di questa prima parte di “avvio” dell’argomento che sintetizzo così: chiunque sia a conoscenza di una specifica applicazione in uso all’interno dell’organizzazione può identificare un potenziale set di vulnerabilità associate. Scopo di questa mini serie è discutere assieme le metodologie per rilevare e correggere le vulnerabilità prima che siano sfruttate. Nel prossimo post discutiamo una bozza di procedura e prendiamo in considerazione alcune tecniche di rilevamento (offensive e difensive) delle vulnerabilità.

cyber security, hacking

La filiera del crimine cibernetico

Alcuni modelli di attacco risultano estremamente efficaci grazie ad una sorta di filiera nell’industria del crimine cibernetico. Esiste, ad esempio, un mercato molto attivo per quanto riguarda database ricchi di anagrafiche con relativi dati personali come indirizzi email, credenziali, profili social, ecc… dati che per essere acquisiti richiedono di per se un attacco finalizzato al furto degli stessi e spesso “monetizzato” ricattando il target di divulgare le informazioni sottratte tramite il data breach a meno che non venga corrisposta una somma in crypto valuta.

Ma l’attacker non si limita alla richiesta di riscatto che, come le statistiche riportano, potrebbe anche non andare a segno. I dati sono infatti spesso messi in vendita su diversi portali nel Dark Web e non (ormai ci sono molti siti che, con meccanismi curiosi basati su “crediti”, consento di entrare in possesso di queste informazioni) o altri metodi più immediati come famosi gruppi e canali su Telegram e simili.

Acquisire un database con credenziali di milioni di utenti è, per ovvie ragioni, un ottimo punto di partenza per l’attacker che cerca nuove vittime: in base al proprio modello di attacco potrà selezionare organizzazioni per le quali possiede informazioni utili ad eseguire azioni offensive: avere a disposizione anagrafiche spesso accompagnate da credenziali personali e/o aziendali (anche se non aggiornate) di membri di un ente o di una azienda consente infatti la progettazione di attacchi molto efficaci. Le credenziali obsolete possono comunque essere utilizzate per campagne di phishing mirate tramite cui acquisire nuove informazioni o altri dati sensibili.

In questi casi, pur avendo provveduto all’introduzione di policies atte a ridurre enormemente il rischio di accessi non autorizzati alla rete tramite credenziali trafugate, si deve far fronte a tecniche di social engineering e phishing particolarmente insidiose: non stiamo parlando della solita email truffaldina che, si spera, gli utenti hanno imparato a riconoscere ed i sistemi di Email Filtering/Security sanno segnalare come “anomala”, il phishing mirato è decisamente più subdolo in quanto le comunicazioni, che possono avvenire via email o altri mezzi, sono costruite per essere verosimili. Non è raro l’utilizzo di informazioni reperite tramite tecniche di analisi come OSInt (tema in parte raccontato in questo podcast) o ricavate da quel tesoretto di dati trafugati tramite altri data breach ed acquistati spesso a prezzi anche molto bassi.

Nota: il “valore economico” dei dati provenienti da un data breach varia in virtù di molti parametri, non ultimo l’epoca a cui risale.

La strategia di difesa deve quindi tenere in considerazione il fatto che l’attacker potrebbe agire sulla base di informazioni anche molto dettagliate sul vostro conto, sia personali che del contesto lavorativo. Per capirci riporto un banale esempio di azione offensiva che mi è capitato di realizzare in occasione di un security test (ovviamente commissionato da una organizzazione che aveva l’esigenza di misurare il proprio grado di consapevolezza) dove è stata progettata una campagna di phishing verso uno specifico gruppo di utenti in riferimento ad una verifica di sicurezza del proprio account aziendale per una applicazione terza (in cloud) il cui utilizzo era emerso grazie alle analisi OSInt (nel caso specifico i record DNS davano evidenza specifica dell’utilizzo del servizio). L’azione, nella sua senplicità, riprendeva qualcosa di estremamente noto alle vittime ed i risultati hanno consentito di misurare il livello di esposizione ad una minaccia estremamente diffusa.

Esistono infinite sfumature che possono essere utilizzate in un attacco di phishing mirato ed è relativamente semplice aggirare o eludere meccanismi di protezione. Ad esempio l’utilizzo di email regolarmente registrare con provider di tutto rispetto: è raro che un indirizzo email opportunamente formattato sia considerato una minaccia (asdfgh88@da.ru è ben diverso da franca.rossi@protonmail.com). Inoltre l’email non è certo l’unico canale per innescare un dialogo. E’ sensibilmente aumentato l’utilizzo di tecniche di impersonation finalizzate alla raccolta di informazioni… e visto l’attuale contesto, in cui è praticamente impossibile incontrare persone o enti che non fanno uso di social network, è ovvio che le tecniche di social engineering siano sempre più utilizzate e risultino particolarmente efficaci.

Ed arriviamo al problema del percepito: si tende ad osservare la singola azione, la singola minaccia quando il tema va approcciato facendo dieci passi indietro per osservare il contesto nella sua interezza e complessità. Le singole azioni “chirurgiche” di mitigation e remediation, se non le contestualizziamo in un processo più ampio, rischiano di essere inefficaci. Non ha senso combattere le singole minacce una ad una — oggi il phishing, domani le vulnerabilità dei sistemi di perimetro, settimana prossima la gestione dei dati sensibili — ovvio che è sempre meglio di niente, ma questo è “agire a sentimento” (per non dire a caso) per combattere un avversario che ha strategie e tattiche ben definite e collaudate. Chi la spunterà?

Va costruita una strategia che prenda in esame come siamo fatti (come persone e come organizzazioni) che sia la base per definire azioni e tempi, con ordine e KPI misurabili. Va gestita questa cosa delle “sicurezza cibernetica”, con metodo.

Per quanto mi riguarda per capire il contesto dovete circondarvi di persone — consulenti, dipendenti… come vi pare — che lo hanno vissuto, che fanno parte del complesso e vasto mondo delle sicurezza cibernetica (sul versante etico e legale ovviamente ma bel consci di come sia fatto alche l’altro versante). Orientarsi in questo universo è indispensabile per prendere decisioni efficaci ed efficienti.

Da non dimenticare che le aziende operano in un contesto di mercato dove, solitamente, esiste una certa competizione: non ci si può permettere di non considerare il vantaggio competitivo nell’ottenere una postura di sicurezza migliore rispetto agli altri attori di mercato, è evidente la restituzione di valore in termini di qualità, affidabilità, resilienza. E’ un processo già avviato, probabilmente accelerato dall’attenzione (spesso maldestra a dir la verità) dei media, ma è ovvio che il cliente (prima di tutte le aziende ma lo stesso discorso vale per l’end user) comincerà a prediligere il fornitore più affidabile anche dal punto di vista della sicurezza cibernetica. Ne va del suo business.

hacking

La curiosità che genera competenza e comprensione

L’essere curiosi, ovviamente in modo sano, è alla base della crescita (e non mi azzardo ad andare oltre per quanto riguarda i temi socio-psico-umano-robe).

It’s the law!

Molto più pragmaticamente posso dire che la curiosità è ciò che ha spinto il sottoscritto e molte altre persone che hanno vissuto la scena acara (a prescindere dall’epoca) a studiare come dei matti argomenti distanti da qualsiasi corso o università. Moltissime persone che lavorano nel campo della sicurezza informatica hanno acquisito competenza ed esperienza grazie alla capacità di non smettere mai di studiare, sperimentare, applicare, migliorare… in un loop infinito.

Sono certo che moltissimi professionisti del settore si trovano a dover rispondere a domande che fanno un po’ tenerezza, tipo: ma che scuola devo fare per diventare un hacker etico / pen tester / bug hunter?
Indubbiamente ci sono favolosi percorsi di studio e corsi che consento di avvicinarsi a questo mondo e di acquisire le nozioni tecniche per svolgere attività sia in ambito offensivo che difensivo, ma la materia è così vasta e richiede un background così forte che non c’è corso che tenga… non esiste una scorciatoia, bisogna studiare come dei dannati (anche grazie ai corsi) e passare ore, giorni e notti su documenti, libri, codice, laboratori, esperimenti…

Perché il punto non è sapere come funziona una cosa, il punto è capire perché funziona (cit. Capitano James T. Kirk) e se non siete mossi dalla curiosità di scavare a fondo il “perché” non sarà mai così chiaro.

Se questo approccio può aiutare le nuove leve a costruire una reale competenza, in questo come in altri campi, è anche vero che aiuta i professionisti a mantenere un adeguato livello di preparazione sia sul piano tecnico che sul piano manageriale. Gestire la sicurezza informatica (me lo vedrete scrivere fino a quando non vi sanguineranno gli occhi) non è una questione tecnologica, è un approccio, un modo di pensare ed agire che deve costantemente adattarsi a nuovi scenari.

Chi pretende oggi di gestire il fenomeno degli attacchi informatici con le stesse metodologie e procedure che utilizzava 3 anni fa (senza mettere in dubbio i successi del passato) rischia di passare dei brutti momenti. In pochi anni non solo sono cambiati i vettori d’attacco ma sono cambiate anche le strategie, i metodi di qualifica dei target, le “leve”. Dobbiamo uscire dalla trappola della “spesa” per difendersi e ragionare sugli “investimenti” per competere sul mercato. Essere cyber-sicuri è un vantaggio di business: significa essere affidabili, tutelare meglio i dati dei nostri clienti, offrire beni e servizi di qualità anche in relazione alla sicurezza.

Non è un percorso che ha una fine, è una costante ricerca del miglioramento e va alimentata con la curiosità.

podcast

Prima di un attacco (mini serie)

E’ un tema che porto spesso all’attenzione dei miei interlocutori e recentemente ho appreso che è di interesse anche per figure di management che non “bazzicano” il mondo cibernetico.

Quel primo episodio mi ha permesso di comprendere quanto il fenomeno del crimine informatico sia assolutamente non chiaro… talvolta non solo ai non addetti ai lavori.

Per risolvere un problema devi conoscerlo, devi sapere cosa c’è di “rotto” per decidere come sistemare le cose, eppure ognuno di voi — ne sono certo — può raccontare decine di situazioni in cui si sono messe “pezze” senza considerare quali fossero le minacce da cui era necessario difendersi, o basandosi sulla propria percezione del rischio.

Recentemente (grazie ad un evento a cui ho partecipato) ho avuto modo di riorganizzare le idee e con l’occasione ho pensato di portare qualche riflessione in tre puntate del podcast che curo. Le prime due sono online qui: https://www.spreaker.com/show/sintesi-cibernetica

Fatemi sapere se li avete trovati interessanti.

cyber security, update

Il fenomeno del crimine informatico

E’ un tema su cui continuerò a scrivere e che probabilmente porterà a dovermi ripetere spesso, ma è necessario che il fenomeno venga compreso a livello di funzionamento e strategia prima di affrontare i temi tattici e tecnici. Inoltre è molto più facile per le figure dirigenziali comprendere i concetti strategici rispetto alle tematiche che coinvolgono l’ambito tecnologico… validissimo motivo per approfondire.

Per prima cosa dobbiamo comprendere lo scenario in cui stiamo operando e vivendo. Il luogo comune, del quale ancora fatichiamo a liberarci, vuole che “l’hacker cattivo” (espressione di per se impropria) sia un ragazzotto in felpa e cappuccio che dal suo scantinato riesce a tenere in scatto aziende, enti e persino governi.

Questo pensiero è il refuso di una visione distorta ed estremamente obsoleta del mondo digitale sul quale media e cinema hanno giocato per anni disinformando il pubblico e spesso anche gli addetti ai lavori. Se è vero che c’è stato un periodo in cui diversi appassionati di settore giocavano in rete facendo talvolta qualche danno è altrettanto vero che oggi il mondo del crimine informatico è composto da figure estremamente diverse ed è governato dal logiche di puro business.

Abbiamo quindi a che fare con figure mosse dal lucro ingaggiate o facenti parte di organizzazioni criminali, l’obiettivo degli attacchi informatici è principalmente quello di ricavarne un profitto diretto (con meccaniche di estorsione) o indiretto grazie all’utilizzo di informazioni trafugate che possano danneggiare il target.

E’ inoltre interessante analizzare le revenues di questo modello di business per comprendere su quali fronti il crimine informatico è più attivo. Una stima proposta tra il 2019 ed il 2020 da più studi tra cui Atlas parlava di un 1.500 miliardi di USD l’anno… quasi il PIL di un paese industrializzato.

Ancor più interessante è la ripartizione di questo business. Una considerevole fetta riguarda la compravendita illegale di beni online, ambito di analisi interessante ma che difficilmente va a danneggiare direttamente il business delle aziende. Il resto della torta è sostanzialmente diviso per tre parti: compravendita di dati, compravendita di informazioni riservate e caas/ransomware.

Questa fetta del “mercato” del crimine informatico si riferisce quindi a tutte quelle tipologie di attacco che hanno come obiettivo la compromissione ed il furto di dati o il danneggiamento di sistemi (quelli informatici quanto quelli industriali: in entrambi i casi è possibile chiedere un riscatto). E’ inoltre interessante constatare come gli attacchi che utilizzano la tecnica forse più nota e più discussa — i ransomware — rappresentino una relativamente piccola fetta del totale: “solo” 1 miliardo di USD l’anno. Eppure è un dato di fatto che una delle prime preoccupazioni degli interlocutori con cui abbiamo a che fare sono i ransomware. Evidentemente il fenomeno del crimine informatico è solo in minima parte percepito da chi è chiamato a gestire il tema, cosa che porta inevitabilmente ad esporsi a rischi di cui non si conosce la natura.

Viviamo in un contesto in cui chi attacca è spesso “ingaggiato” da gruppi criminali e lavora dietro compenso al fine di colpire target da cui poi trarre un facile profitto e i dati ci dicono che “loro” di cui i criminali informatici vanno a caccia sono le informazioni.

E chiudo con una riflessione sul modello opportunista (nel senso proprio del termine) che si osserva: è evidente che da un punto di vista economico l’attacco deve costare meno di quanto si ritiene di poter ricavare, altrimenti il modello non sta in piedi. Il target non è quindi selezionato a caso ma viene accuratamente scelto sulla base di parametri anche abbastanza ovvi come la capacità di sostenere un riscatto e la possibilità reale di poter compromettere l’operatività del target con l’attacco così da indurlo al compromesso del pagamento.

La diretta conseguenza di questo ragionamento è che le aziende che espongono superfici attaccabili particolarmente “morbide” — identificabili con specifiche tecniche di analisi — vengono selezionate come appetibili per il mercato del crimine informatico.

Uno dei nostri obiettivi, tra gli altri, è quello di non essere catalogabili come appetibili.