cyber security, podcast

Cyber Saturday 20230121

Sono nel mezzo di attività di Adversarial Simulation che per loro natura tendono a toccare molti aspetti anche non prettamente tecnici: è abbastanza frequente passare da tecniche di social engineering che richiedono una certa abilità comunicativa ad azioni sui sistemi target che richiedono una elevata conoscenza dell’ambiente su cui si è ottenuto l’accesso.

Discutendo con i colleghi e con gli addetti ai lavori ci troviamo spesso a commentare le differenze operative tra un’attività di Penetration Testing ed una Adversarial Simulation, differenze che non riguardano le skills in se ma le finalità dell’attività e di conseguenza, in molti casi, anche degli aspetti tattici.

Questa sera dedico lo spazio di discussione nella live su Twitch a questo argomento: vi riporto qualche mia esperienza e se tra i presenti c’è qualcuno che conosce gli argomento sentiamo cosa ne pensa. Ovviamente lasciamo spazio alle domande.

Dopo le chiacchiere passiamo un po’ all’azione: sto preparando la seconda parte del video sulla macchina Breakout in cui ci eravamo ripromessi di fare un po’ di azioni di post-exploitation. Ci ragioniamo assieme e definiamo una scaletta di prova da fare in lab.

Live su Twitch a partire dalle 21:30 di questa sera (21 gennaio), qui il link al canale: https://www.twitch.tv/roccosicilia.

cyber security, hacking

Threat-Led Penetration Testing

Oggi snoccioliamo qualche bella sigla e partiamo con TLPT. La prendo larga: come si fa a capire se le scelte fatte da una organizzazione, in termini di difesa dalle minacce informatiche, funzionano e in che grado funzionano?

Prima di darci una risposta ripassiamo il concetto di DIFESA, termine con il quale ci vogliamo riferire alla capacità di una organizzazione di reagire ad una minaccia. Non stiamo quindi parlando dei soli sistemi di protezione che ne fanno ovviamente parte (es: sistemi anti-malware, servizi MDR, ecc), ma dall’intera strategia di identificazione e gestione degli incidenti di sicurezza. Per essere chiari e lapidati: avere un ottimo sistema di detection, per quanto magico e ben configurato, non è una strategia di difesa, è uno strumento utile che deve far parte di una strategia più ampia.

Ora possiamo tornare alla domanda iniziale. La mia risposta (e non solo la mia) è: mettendo alla prova l’organizzazione. Ora, che ci crediate o no, l’unico modo per mettere alla prova un’organizzazione in tal senso è vedere come reagisce quando sottoposta ad un attacco informatico, tutto il resto sono chiacchiere.
Ci sono molte attività indispensabili che servono ad identificare falle specifiche con l’obiettivo di costruire un piano di miglioramento costante della propria postura. Possiamo eseguire molte tipologie di assessment, definire piani di formazione, adeguare costantemente i sistemi e le procedure, ma per vedere se l’impalcatura regge bisogna dargli qualche scossone.

Nulla di nuovo sotto al sole, chi lavora nel campo dell’offensive security propone questo approccio da anni. La citata sigla sta per Threat-Led Penetration Testing, per gli amici Red Teaming: sottoporre un target ad una serie di azioni controllate e concordate che facciano uso di metodologie e strumenti tipicamente in uso ad un attacker.

E’ un tema che recentemente si sta discutendo più frequentemente rispetto a qualche mese fa, probabilmente in conseguenza a quanto riportato nella Guida nazionale TIBER-IT, in riferimento al framework TIBER-EU. Le direttive in questione sono state pensate per il settore finanziario, storicamente un po’ più attento ai rischi legati alle moderne minacce cyber. A mio parere è un tema su cui tutti i settori dovrebbero cominciare a ragionare seriamente.

Ovviamente il tema va opportunamente declinato nei singoli contesti: stiamo parlando di applicare una metodologia che, sulla base del tipo di target, può prevedere strumenti, competenze e costi diversi. Il costo per un’azienda interessata va quindi valutato sulla base del contesto di riferimento che per ovvie ragioni avrà molte peculiarità da tenere in considerazione.

A cosa serve simulare un’azione di attacco? Personalmente non vorrei scoprire che qualcosa nella mia strategia non va a seguito di un attacco vero. Le aziende strutturate sono spesso molto complesse, è poco realistico fare previsioni a tavolino su come reagirà il “sistema”, nel complesso, a certe sollecitazioni. Per chi lavora in questo ambito sto dicendo delle ovvietà enormi, fattore in contrato con la realtà odierna in cui un numero al momento troppo basso di aziende si sta realmente muovendo in questa direzione.

Visto che si tratta dell’ennesimo argomento complesso gli dedico uno spazio nella prossima live del 21 gennaio sul mio canale Twitch.

hacking

GIT-SHELL: p-o-c v0.1

Tempo fa mi ero imbattuto in un post su medium in cui si discuteva dell’utilizzo di git per gestire una reverse shell. Non è un tema nuovo, ho visto diverse presentazioni in vari eventi in cui sono state mostrate le potenzialità della tecnica che trovo interessante per diversi fattori tra cui:

  • la possibilità di utilizzare come “base” una piattaforma considerata affidabile come un servizio di versioning in cloud
  • la possibilità di utilizzare comodamente SSH o HTTPS come protocollo di comunicazione
  • la versatilità dello strumento in se (git)

Ho rispolverato l’argomento in questi giorni (attività in corso con il red team) ed ho approfittato per costruire un piccolo prototipo che sfrutti le funzionalità di git con qualche accorgimento in più. Di seguito il funzionamento del mio proof of concept ed il codice utilizzato in questa primissima versione dimostrativa.

Come funziona

Il processo è molto semplice, partiamo dal contesto. Si tratta a tutti gli effetti di una reverse shell, siamo quindi in una fase di post-exploitation in cui abbiamo ottenuto un accesso ad un sistema o abbiamo modo di interagire. E’ inoltre necessario, almeno in questa versione del tool, che git sia presente sul sistema target salvo poterlo installare senza destare sospetti.

Sfruttando una qualsiasi funzionalità che consenta ti eseguire ad intervalli uno script facciamo in modo di eseguire il seguente processo:

  • creiamo/aggiorniamo la repo locale del progetto
  • verifichiamo il contenuto dell’ultimo commit message
  • se contiene una stringa che corrisponde ad un comando bash, eseguiamo il comando sul sistema
  • ridirigiamo l’output del comando in un file di testo che fa parte della repo (es: output.txt)
  • eseguiamo il commit delle modifiche ed aggiorniamo la repo remota

L’unica differenza di sostanza con altre git-shell sta nel fatto che i comandi vengono solitamente posizionati encoded in un file che fa parte dalla repo. In questa versione ho utilizzato il campo dedicato ai messaggi delle commit per inviate i comandi alla shell mentre per ricevere gli output ho mantenuto il metodo classico.

Come risultato finale per dialogare con il sistema basta eseguire una commit sulla repo ed aspettare l’aggiornamento del file “output.txt” con la risposta.

Demo

Una piccola dimostrazione pratica per vedere gli step e le modalità di lavoro della versione 0.1 che rilascio solo a fini dimostrativi per ambienti unix-like. Seguiranno probabilmente integrazione per altri ambienti.

Per prima cosa è ovviamente necessario clonare la repo sulla macchina target:

$ git clone https://github.com/roccosicilia/sToolz

Il progetto è una collezione di piccoli tools, in questa occasione ci interessa solo il contenuto della directory RedTeam/C2demo/ dove troverete diversi file tra cui:

  • il file git-demo.sh con lo script da tenere in esecuzione sulla macchina target
  • il file git-output.txt dove verranno scritti gli output dei comandi alla shell

Nota sugli altri file: fanno parte di altre versioni della p-o-c ancora in sviluppo, la metodologia è la stessa ma i canali utilizzati sono differenti.

Usando una tecnica a vostro piacimento è necessario far girare periodicamente lo script git-demo.sh:

Lo script si occupa semplicemente di aggiornare la repo locale e verificare l’ultimo messaggio di commit: se il messaggio è NOP lo script non esegue azioni e procede con la prossima iterazione, in caso contrario legge il contenuto dell’ultimo commit e lo utilizza come comando da inviare al sistema locale. L’output del comando viene così inviato al file git-output.txt su cui si esegue la commit e la push verso la repo remota.

A questo punto è sufficiente eseguire una qualsiasi modifica ad uno dei file della repo (es: README) mettendo nel messaggio il comando da eseguire.

l’esempio più idiota che mi è venuto in mente

L’output del comando verrà quindi salvato all’interno del file git-output.txt e sincronizzato con la repository del progetto su GitHub o su altri repo Git di vostro gradimento.

Utilizzo in un contesto reale

Ripercorriamo assieme gli step usando solo la cli sia lato “attacker” (a sinistra) che lato target (a destra), tenendo in considerazione che questa versione dimostrativa non è dotata di una interfaccia utente che possa agevolare qualche comando.

In arancione sono evidenziali i due file che compongono la versione 0.1 della git-shell, mentre nel riquadro azzurro il comando che avvia il loop sulla macchina target. Non essendoci stati change sulla repo remota lo script in loop restituisce il messaggio che indica che non ci sono azioni da eseguire (NOP).

Mentre sul sistema target è in esecuzione lo script, sul sistema locale modifichiamo uno dei file della repo (in questo caso il README.md. Come previsto con un git status possiamo visualizzare la modifica in accesa di commit.

commit

Una volta modificato il file possiamo eseguirne l’add e poi il commit (nell’esempio stiamo ancora usando la mia repository di test). Nell’esecuzione del commit, sottolineato in verde, vi è un comando specifico: per evitare problemi nell’utilizzo della stringa da utilizzare come comando sul sistema target si è adottata una forma che consenta di evitare gli spazi come carattere separatore.

Ora è sufficiente eseguire la push delle modifiche sulla repo ed attendere che il sistema remoto aggiorni la propria repository. In caso l’aggiornamento vada a buon fine dovremmo poter osservare la sincronizzazione delle repo:

A questo punto lo script avrà eseguito il comando passato tramite messaggio (df -kh) e scritto l’output sul file git-output.txt. Per accedere al contenuto sarà sufficiente aggiornare la repo sulla macchina locale leggere il contenuto del file:

l’output del comando “df -kh”

Qualche riflessione

Come sicuramente in molti avranno avuto modo di sperimentare l’utilizzo dei blasonati tools di Penetration Testing viene spesso limitato dal fatto che i sistemi di sicurezza ne conoscono bene il comportamento e sono spesso in grado di bloccare specifiche azioni. L’esigenza di creare componenti “originali” per le suite più note o piccoli strumenti from scratch credo si manifesterà sempre più frequentemente.

Le reverse shell sono strumenti potenti e se ben pensate sono difficili da individuare. L’esempio presentato in questo breve post difficilmente potrebbe essere rilevato se non grazie a sistemi di controllo in grado di correlare l’azione in se (dei comandi git e del traffico https) ad un comportamento anomalo come l’intervallo regolare degli update o il fatto che la rete target non ha familiarità con gli host di atterraggio delle sessioni. Tecnica ancor più insidiosa se la si veicola tramite un dispositivo “guest”, non controllato dall’IT.

In questo proof of concept abbiamo giocato ma è mia intenzione valutarne gli effetti in contesti di analisi ed attività – ovviamente concordate – di adversarial simulation.

cyber security, hacking

Una riflessione sul concetto di “detection”

Come ho avuto modo di raccontare in qualche post su LinkedIn, negli ultimi mesi ho potuto dialogare con molti attori, italiani e non, del mondo MDR. Per i non addetti ai lavori: MDR è l’acronimo di Managed Detection and Response e si riferisce ai servizi di presidio degli eventi di una rete con capacità di intercettare minacce informatiche e reagire per mitigare e/o bloccare l’eventuale compromissione. Potremmo dire che si tratta dall’evoluzione dei più tradizionali servizi di Security Operation Center che hanno sempre avuto il compito di intercettare e segnalare eventuali situazioni di compromissione.

Nel discutere i diversi scenari di applicazione del concetto di detection ho notato due approcci che definirei complementari. Va detto che alcuni interlocutori utilizzano entrambi gli approcci mentre altri ne prediligono uno all’altro. Il primo approccio è network-oriented: i dati su cui viene eseguita l’analisi vengono da sonde a livello rete che, potendo osservare il traffico sia a confine che all’interno della struttura, analizzano le conversazioni e, se possibile, i contenuti per scovare eventuali minacce. Il secondo approccio è event-oriented: i dati su cui viene eseguita l’analisi provengono dai logs e dagli eventi registrati dai sistemi della rete che possono inviare informazioni “grezze” o già qualificate (es: allarmi da parte di hosts o altri sistemi).

[Nota tecnica] Nella discussione nata su LinkedIn emerge l’esigenza di estendere il dominio dell’approccio event-oriented a ciò che è possibile analizzare a livello kernel dei sistemi operativi grazie a specifici agent. Nel post considero questa fonte assimilabile ad un evento anche se non viene segnalata attraverso i classici servizi di gestione degli eventi ma, solitamente, attraverso un agent.

Non voglio arrivare a conclusioni di preferenza, lo scopo del post è illustrare i due approcci in modo semplice così da farsi un’idea. Le valutazioni di merito vanno fatte caso per caso. Come da titolo il post si limita al concetto di detection, mentre per il concetto di response valuterò un post dedicato più avanti.

Detection network-oriented

Alla base di questo modello vi è l’assunto di poter osservare tutto il traffico di rete, sia nord/sud che est/ovest. Di per se questo requisito non è impossibile da rispettare ma in contesti complessi potrebbe non essere così immediato. Per ragionare sul modello a prescindere dalla complessità della rete (tema comunque da non trascurare in fase di analisi) mettiamoci comodi e lavoriamo su uno scenario semplice:

Nota di laboratorio: il lab mette a disposizione uno Standard Virtual Switch (su ESXi 7.x) su cui sono configurati tre Port Group in corrispondenza di tre VLAN (LAN, DMZ, WAN) a simulare una semplice rete.

In questo semplice esempio, facilmente applicabile in contesti con più reti e più apparati, vi è l’esigenza di portare tutto il traffico in visibilità di un oggetto “sonda” che si occuperà di analizzarlo a caccia di eventuali anomalie da segnalare direttamente all’amministratore di rete o, in contesti più complessi e completi, da portare a conoscenza di un sistema centralizzato e presidiato come un SIEM gestito da un security operation center (o altro team dedicato).

Virtualmente, se tutto il traffico fosse presidiato ed accessibile a livello di contenuto, dovremmo aver completa visibilità. E’ opportuno considerare che nel mondo vero non è così semplice raccogliere tutto il traffico di una rete. In un contesto multi sede sarebbe necessario predisporre almeno una sonda per sede. Inoltre le reti delle singole sedi possono essere molto complesse e potrebbero quindi richiedere più sonde. Ciò che spesso accade è che alcune porzioni di traffico non vengono raccolte.

C’è un altro tema da considerare se approcciamo lo scenario dal punto di vista di un threat actor. Cosa succede se volessimo attaccare una workstation (ws1 nello schema) con un’azione locale e che non transiti necessariamente dalla rete? Ovviamente la detection sarebbe impossibile se non grazie a sistemi che lavorano a livello host. Altro esempio: cosa succede se l’attacker utilizzasse l’host ws1 per inviare dati all’esterno della rete generando traffico verso un servizio in uso dall’organizzazione come OneDrive o Google Drive?

Il modello di per se ha il vantaggio di avete un punto di osservazione molto comodo per quantità di informazioni a cui può accedere e per capillarità. Va necessariamente considerato che non tutti gli attacchi hanno bisogno di transitare dall’infrastruttura di rete del target o potrebbero essere utilizzate tecniche particolarmente stealth per rendere l’azione difficile da rilevare.

Detection event-oriented

Ciò che accade sugli hosts è da diversi anni un tema di interesse: i logs delle security appliance come i Firewall sono sempre stati interessanti ma a questi si sono aggiunti gli eventi dei vari sistemi che popolano le reti. A livello cronologico si è prima svilippato in interesse verso i sistemi server per poi estendere il concetto a tutto ciò che può produrre un log: workstation, sistemi operativi, applicazioni, telefoni e caffettiere connesse alla rete LAN per contare quanti caffè vengono fatti ogni giorno (l’IoT ha avuto i suoi impatti).

Va inoltre aggiunto ciò che è possibile osservare a basso livello, in un mio recente post su LinkedIn si è discusso di quanto sia possibile andare in profondità con l’analisi a livello kernel utilizzando sistemi di controllo (es. EDR) in grado di sfruttare specifici moduli. Metto tutto, un po’ impropriamente, nel calderone della detection event-oriented in considerazione del fatto che si tratta di comportamenti che possiamo osservare a bordo di un sistema e di cui possiamo centralizzare il collecting e l’analisi.

L’approccio consente di avere un elevato livello di controllo sui singoli sistemi che popolano la rete (oltre a rendere possibile l’utilizzo di agent in grado di agire attivamente sui sistemi) ed ha l’ovvio limite di non dare evidenza in relazione a ciò che succede laddove non è stato installato/configurato un agent, spesso integrato a livello di sistema operativo, per inviare le informazioni a un sistema centralizzato in grado di analizzarle, SIEM o simili.

Le due aree non presidiate sono infatti determinate da quei sistemi che non hanno la possibilità di inviare eventi o dai sistemi che hanno la possibilità di connettersi alla rete target ma non sono gestiti centralmente (guest). In questi casi, non potendo riceve eventi direttamente dal sistema, possiamo contare solo su ciò che gli altri “agent” sono in grado di osservare a seguito di movimenti laterali. Azioni complesse ma assolutamente fattibili come un attacco MITM possono essere difficili da individuare in questo contesto. Anche attività di scansione passiva della rete diventano difficili da rilevare e, come per il precedente scenario, l’utilizzo di canali “leciti” e cifrati per comunicare con l’esterno rappresenta un problema dal punto di vista della detection in quanto il SIEM deve avere degli elementi per distinguere traffico lecito da traffico illecito in assenza di informazioni sul contenuto e a parità (o quasi) di destinazione e comportamento.

Abbiamo anche in questo casa un modello che consente grande capillarità ma che da solo lascerebbe un po’ di spazio di manovra se il contesto consentisse l’accesso a porte di rete ad eventuale personale ospite (autorizzato e non).

Qualche esempio per giocare

Giusto per capire di cosa stiamo parlando riporto due esempi, semplicissimi, relativi ai due scenari in cui vediamo come vengono interpretate azioni offensive utilizzando una detection network-oriented (tramite un IDS) ed una detection event-oriented (tramite un SIEM). Per semplificare il lab e permettervi di riprodurlo in modo abbastanza semplice utilizzo una appliance Security Onion.

Partiamo dall’azione più banale che, come spesso discutiamo durante le live, non è esattamente una cosa che accade mondo vero (fuori dai laboratori e dai corsi di formazione)… una bella scansione con nmap 🙂

nmap -sS verso il sistema Security Onion

Il traffico di una scansione è molto rumoroso, è quindi probabile che una sonda in rete possa interpretarlo per quello che è, verrebbe quindi generato un allarme sul sistema che controlla il traffico il traffico in transito nella rete:

L’allarme generato da suricata per la scansione

Anche utilizzando l’opzione -sT, un pelo meno aggressiva rispetto al primo tentativo, la quantità di rumore resta alta e comunque sufficiente a generare nuovi alert. Azioni più delicate tendono a passare invece inosservate o ad essere associate a severity più basse: un esempio è uno scan via nmap finalizzato alla sola discovery di host nella rete; di recente abbiamo utilizzato queste opzioni assieme al mio Red Team:

nmap -sn -PR -T5 -oA alive $target

Ovviamente in questo caso ci si accontenta di un obiettivo intermedio: la verifica degli host up. Anche abusando un po’ di questo tool in questa modalità il traffico in questo caso è relativamente basso e “agita poco le acque”, si riesci quindi ad ottenere una scansione degli host attivi senza destare sospetti:

Un banale ciclo for per passare alla scansione più target

Volendo essere estremamente chirurgici, una volta estratti silenziosamente gli host attivi potremmo passare a scansioni mirate su specifiche porte a caccia di servizi, questa volta usando uno semplice script in Python per verificare se le porte rispondono o no.

Il livello di sensibilità la sonda può ovviamente essere configurata così da individuare anche comportamenti come quelli utilizzati negli esempi in cui suricata, in qualità di IDS attivo nella rete, non ha segnalato allarmi. Il rovescio della medaglia, in caso si renda troppo sensibile la sonda, è ovviamente ricevere potenzialmente troppi falsi positivi.

Sul fronte di ciò che è possibile osservare a livello host il principio è simile. Come precedentemente discusso solitamente si utilizzano delle componenti, native o facendo uso di agent, che raccolgono ed analizzano ciò che accade a bordo di un sistema.

Facciamo un esempio molto semplice:

Tentativo di accesso in SSH si un sistema con agent attivo

Le regole di base per Security Onion identificano un accesso SSH fallito come un allarme con severity low:

In questo caso è il modulo ossec ad intercettare l’evento

Cambiamo punto di osservazione e posizioniamoci a bordo di un sistema, esattamente come se fossimo l’attacker che ha guadagnato un primo accesso con un utente qualsiasi di sistema e deve mettersi comodo. Ci sono un migliaio di cose che potremmo fare in questa situazione (sto preparando un post al riguardo). Tipicamente ci si muove sul sistema compromesso, si raccolgono info sulle configurazioni e sui tools presenti per poi arrivare, solitamente, a portare qualcosa dentro e/o fuori dall’ambiente.

Queste azioni, ancora una volta in base alla sensibilità dei sistemi di detection, possono far scattare degli allarmi o meno. Ad esempio se porto uno zip file sul sistema, tenendo sempre in considerazione che siamo in una configurazione base, il sistema SIEM non segnala nessun evento, ma se porto un binary file via HTTP …

wget di ncat da un host all’interno della stessa rete

… l’azione diventa chiaramente molto sospetta e potrebbe far scattare qualche regola di detection.

Nell’attuale configurazione del lab possiamo invece modificare i permessi del file scaricato ed eseguirlo senza generare allarmi a livello host, azione effettivamente pericolosa che in un sistema di produzione dovrebbe generare degli allarmi.

Ancora una volta dobbiamo ricordare che queste regole sono modificabili e che stiamo lavorando solo a livello di detection senza fare analisi dei contenuti di un file, cosa che un EDR farebbe sicuramente e molto probabilmente piallerebbe il file ncat alla velocità della luce. Qualche settimana fa in una live abbiamo visto come si è comportato l’EDR del mio laptop quando abbiamo provato ad eseguire un nc.exe. Quello che sicuramente metterebbe in difficoltà il sistema di detection è l’utilizzo di ciò che è già a bordo della macchina in modo tale da generare log del tutto simili a quelli che il sistema genera abitualmente.

Arriviamo al dunque

Nel mio lavoro e nel mio ambito di ricerca passo molto tempo a cercare i punti deboli dei sistemi e sono giunto alla conclusione che non ci si può affidare ad un singolo modello o ad un singolo approccio. Come spesso scrivo qui e nei miei post su LinkedIn, è necessario partire da un’analisi dei punti deboli per poi individuare gli strumenti idonei – in questo caso alla detection delle minacce – per il vostro specifico contesto. Troppo spesso ho trovato sistemi che potenzialmente avrebbero potuto rilevare qualsiasi cosa ma, a causa di una errata analisi, erano stati configurati con mille eccezioni fino a renderli inefficaci.

L’altro elemento da cui far partire i ragionamenti è una valutazione sui modelli di attacco che potrebbero interessare il target: dobbiamo smetterla di ragionare sulla presenza della singola vulnerabilità, gli attacchi sono singole azioni di exploiting. Dobbiamo lavorare sulla base di scenari offensivi realistici in grado di sfruttare le falle evidenziate in analisi.

cyber security

La qualità del software e l’impatto sulla vita

Mi è stato segnalato ed ho letto questa sera (sono le 22:15 del 06 gennaio mentre inizio a scrivere questo pezzo) un articolo molto interessante di Andrea Monti, persona che credo non abbia bisogno di presentazioni: autorità sia nel mondo High-Tech che nel mondo Legal, co-autore di Spaghetti Hacker, “e ho detto tutto” (cit.).

L’articolo è disponibili qui, l’ho letto attentamente, ne condivido lo spirito, ne condivido il messaggio, l’unico nota di approfondimento la vorrei dedicare (con estrema umiltà) sul punto di inizio del processo di miglioramento. Provo ad argomentare al meglio il mio punto di vista sperando di arricchire il dibattito su un tema così delicato.

L’Avvocato Monti si esprime sulla necessità di responsabilizzare il produttore del software sui danni che questo può causare, come già previsto per i prodotti. Se un difetto di progettazione e/o fabbricazione di un elettrodomestico o di un aeromobile genera un danno il produttore ne risponde (perdonate la brutale sintesi, l’articolo dell’Avvocato è molto più articolato, leggetelo).
Il principio non fa una piega. E’ una distinzione, quella tra prodotto hardware e prodotto software, che oggi non regge più. Concordo anche sugli strumenti legali a tutela di chi acquista il software ma, ne sono fermamente convinto, non partirei dal regolamentare la responsabilità per avviare un processo di cambiamento… o meglio, non sono sicuro che il processo di cambiamento sia così efficacie se si parte da una regolamentazione sulla responsabilità.

Da dove partire quindi? E’ vero che certe strade le imbocchiamo, come umanità, solo se ci costringono. E’ anche vero che, come ho letto in alcuni commenti al post dell’Avvocato Monti, poche aziende di sviluppo software hanno oggi la giusta cultura per affrontare il tema. Prima di responsabilizzarle proverei ad indicargli la via: se produci software DEVI garantirne la qualità utilizzando dei framework pensati per rendere il software sicuro, affidabile, bello e splendente. Agirei anche sul contesto: più il settore in cui il tuo software viene impiegato è delicato e comporta dei rischi (per la salute ad esempio), più gli standard si elevano. Avviato questo percorso che ben vanga una regolamentazione sulla responsabilità.

Perché prenderla larga? Semplicemente perché ho ben presente da dove partiamo… e non è un buon punto di partenza.

Alcuni “standard” di mercato, in ambiti specifici, già chiedono che si lavori in un certo modo. Ho visto i questionari e gli audit a cui le aziende serie sottopongono i propri fornitori di software altrettanto seri. Purtroppo l’ho visto solo in contesti di nicchia.

In sintesi:

  • leggetevi l’articolo dell’Avvocato Monti che come sempre è illuminante
  • personalmente concordo con l’esigenza di una regolamentazione
  • personalmente proporrei un percorso di avvicinamento un po’ più morbido passando prima da regolamentazioni sugli standard di sviluppo per arrivare dopo ad una regolamentazione sulle responsabilità
  • valuterei anche l’introduzione di qualifiche specifiche per le aziende che desiderano lavorare in specifici settori particolarmente delicati (sanità, difesa, ecc.)

Opinioni in merito? Anche questo tema lo metto tra quelli da discutere in una prossima live.

cyber security

I report (in cyber sec.)

Qualche nota molto semplice sui report che tutti noi realizziamo a seguito di un assessment o di un’attività di penetration testing.

Focus (cit.)

Restiamo sull’obiettivo del progetto, la relazione deve riportare informazioni inerenti l’attività svolta. In questo non è utile divagare o aggiungere elementi fuori contesto in quanto rischiano di diluire il messaggio principale e potrebbero ridurne l’efficacia.

Chi leggerà il report?

Considera il fatto che il report dovrà essere letto da persone diverse, con differenti skills e capacità di comprensione tecnica. Un report iper-tecnico metterebbe in difficoltà uno stakeholder non tecnico così come un report scevro di dettagli tecnici risulterebbe poco interessante per una figura competente in materia.

Struttura il repor in modo da avere delle sezioni più ad alto livello e delle sezioni di approfondimento tecnico. Potrebbe essere utile anche allegare della documentazione aggiuntiva in modo da mantenere il report fruibile da chiunque pur mettendo a disposizione degli allegati tecnici per chi ha esigenza di approfondire gli argomenti trattati.

Seleziona le informazioni

Nessuno vuole leggere un report di mille pagine. Valuta cosa includere nel documento e cosa potrebbe aver senso allegare in altro formato. Non ha sicuramente senso includere pagine e pagine di output provenienti dai tools terze parti utilizzati durante l’attività. Anche gli screenshots e gli schemi sono elementi utili ma da utilizzare con saggezza: documentare un’attività o un’evidenza con decine di screenshots potrebbe essere poco efficace a livello comunicativo.

La forma

Qualsiasi sia la lingua in cui scriviamo, dobbiamo scrivere in modo comprensibile e ovviamente corretto. Scegliamo formati leggibili e strutturiamo il report in modo che abbia un filo logico. E’ una relazione, non il nostro blocco degli appunti.


Perché questo post? Ho recentemente rimesso mano al percorso di studio per la certificazione OSCP e, rileggendo le linee guida sulla stesura dei report, mi sono tornate alla mente le espressioni disperate di CIO e CISO intenti a leggere report di centinaia di pagina forniti da big player della consulenza… La professionalità e la competenza devono essere accompagnate dalla saggezza, IMHO.

cyber security, hacking

OSCP: D1

Era uno degli obiettivi 2022 che, per vari motivi, non ho potuto mantenere in roadmap (a malapena ho iniziato a studiare il materiale per la preparazione). Quest’anno ci sono un bel po’ di cambiamenti in corso ed ho quindi pensato di rimettere in programma questo mio traguardo personale.

Ho abbozzato un programma leggero per i prossimi sei mesi in cui vorrei seguire il materiale presentato nel super PDF che fa parte del materiale di studio (che avevo già ottenuto ad inizio 2022) “Penetration Testing with Kali Linux” e su questa base valutare qualche approfondimento. Vorrei inoltre che questo percorso sia utile anche a chi mi legge o mi segue sui vari social, troverete quindi diversi articoli su questo blog con la sintesi dei progressi, qualche live su Twitch ed una repository sul mio GitHub: https://github.com/roccosicilia/OSCP_sj.

Leggendo il primo capito del PDF dove viene presentato il percorso ci viene subito ricordato a chi è rivolta questa certificazione. Si fa riferimento a figure come System Administrator e Network Administrator, a ricordarci che l’ambito del Penetration Testing non è un punto di inizio ma parte di un percorso che inizia prima e che richiede di aver maturato una certa esperienza nella gestione dei sistemi e delle reti. Questo non significa che se non si ha esperienza nei ruoli citati sia impossibile seguire il programma ma sicuramente sarà necessario apprendere delle nozioni senza comprenderle appieno.

Tra le prime note tecniche viene presentato il modello base di un Penetration Test con le sue fasi:

  • Raccolta delle informazioni: più informazioni si ottengono più è probabile che l’attacco vada a buon fine;
  • Enumerazione dei servizi;
  • Primo accesso (es: Exploiting): una volta ottenuto il primo accesso viene solitamente condotta una nuova esplorazione dall’interno del sistema in modo di avere informazioni più dettagliate sul contesto e valutare quindi le successive mosse in modo appropriato;
  • Mantenere l’accesso: il metodo utilizzato nel primo accesso potrebbe non essere comodo da riutilizzare, viene quindi utilizzato un metodo alternativo per mantenere la comunicazione con i sistemi compromessi;
  • Attività post-attacco;

E’ evidente che il programma è ben strutturato e tocca molti aspetti dalle sicurezza dei sistemi. Oltre atte attività operative vi sono cenni su come strutturare il report e su come comunicare i risultati. Pur esistendo un modello base generalmente valido per attività volgarmente chiamate PT, va comunque ricordato che esistono molti ambiti di applicazione per i quali è opportuno sviluppare metodologie specifiche. Un tipico esempio è OWASP in relazione al test di applicazioni web o OSSTMM3.

OWASPOpen Web Application Security ProjectFondazione no-profit che lavora per migliorare la sicurezza del software con particolare riferimento alle applicazioni del mondo WEB (https://owasp.org/)
OSSTMMOpen Source Security Testing Methodology ManualManuale che riporta una metodologia di test di sicurezza basata sull’accertamento di fatti su cui basare le proprie valutazioni in tema di sicurezza di un sistema (https://www.isecom.org/OSSTMM.3.pdf)

Labs

Il corso offerto da Offensive Security comprende un serie di laboratori a cui lo studente può accedere per fare pratica. Nel mio caso mi doterò dell’acceso ai laboratori durante l’anno in corso mentre per le prime fasi (ed i primi capitoli) costruirò autonomamente i labs e pubblicherò i dettagli dei miei esercizi.

Ovviamente è necessaria la macchina Kali che nel mio caso sarà utilizzata in due modalità: come WLS sul mio host Windows (fino a quando avrò Windows…) e su un host dedicato (un mini-pc) disponibile separatamente con la possibilità di tenere accesso il sistema per fargli eseguire operazioni molto lunghe e che vincolerebbero la mia attività lavorativa quotidiana.

Pronti?

A prescindere dalla certificazione il percorso è tecnicamente interessante e consente di approfondire molti ambiti dell’informatica. Ho scritto questo post la notte tra l’1 e il 2 gennaio (2023) dopo aver letto il primo capitolo della documentazione e ho già aperto diversi temi di approfondimento come le diverse metodologie di Security Test. Se avrei voglia di seguirmi in questo percorso e vuoi contribuire con qualche tua nota o riflessione puoi contattarmi direttamente su LinkedIn o su uno dei miei canali social: https://roccosicilia.com/about/.

cyber security, update

Rischio cyber e assicurazioni

Una notizia di oggi, segnalatami dal sempre attentissimo Nicola Del Ben, mi porta a riflettere ancora una volta sul ruolo delle assicurazioni come strumento per la gestione del rischio cyber. Negli ultimi anni ho visto un’evoluzione di approccio e di proposta passando da sterili questionari a veri e propri assessment in grado di dare una buona stima dei fattori di rischio in ambito sicurezza delle informazioni.

Non è questa la sede per parlare dell’efficacia del modello, anche perché servirebbe un dibattito con qualche decina di esperti in più settori. Il tema che porto all’attenzione è relativo alle parole di Mario Greco, AD di Zurich, che ritiene si stia andando verso uno scenario dove il rischio cyber non sarà assicurabile.

Pone inoltre l’attenzione su un’altra questione, ovvero sulla difficoltà di fare previsioni sulle conseguenze di un attacco, soprattutto in situazioni complesse che toccano servizi infrastrutturali o dati privati dei cittadini. Come discusso in molte occasioni anche con Andrea Dainese, il livello di pervasività tecnologica è così elevato da rendere effettivamente difficile fare previsioni su ciò che potrebbe accadere se venisse compromesso un sistema fondamentale per un’azienda, un’organizzazione o uno Stato.

Abbiamo delegato molto alla tecnologia e il concetto di security by design non è ancora permeato nella cultura di molte aziende produttrici, tanto meno nelle aziende utilizzatrici. Troppo spesso acquisiamo tecnologia che non abbiamo compreso, in alcuni casi anche il partner che ci sta proponendo una certa tecnologia non ne ha una completa padronanza. In altre parole stiamo costruendo sovrastruttura tecnologica che non governiamo ed è ovvio non riuscire a prevedere le conseguenze di un eventuale incident.

Gestire questa complessità richiede consapevolezza, la consapevolezza la otterremo a seguito di un percorso culturale fatto di studio, acquisizione di competenze, acquisizione di esperienze. Dobbiamo entrare nell’ordine di idee che la sicurezza informatica non si “compra” in senso stretto. E’ possibile comprare dei supporti (la tecnologia) e dei facilitatori (consulenti e partner esperti di sicurezza informatica).

Mia riflessione: lo strumento assicurativo, per quanto utile, non è la risposta alla prevenzione. Ha aiutato e può aiutare ad assorbile parte del rischio, ma il grosso del lavoro non è avere una buona polizza assicurativa (anche in virtù della previsione di Greco).

La gestione del rischio deve diventare un tema di strategia per aziende ed organizzazioni, non può restare una task list da dispacciare a diversi dipartimenti. Serve un filo conduttore a livello aziendale, una visione comune che tenga conto di cosa sia la cyber security e che utilizzi i mezzi a disposizione (tecnologia, competenze, assicurazioni, ecc.) come strumenti utili allo scopo e non come obiettivi.

Vi condivido il link all’articolo del FT: https://www.ft.com/content/63ea94fa-c6fc-449f-b2b8-ea29cc83637d

hacking

L’allenamento cyber sec.

A chi è del mestiere ed è attivo da qualche annetto nel mondo cyber security (e/o ambienti acari di un tempo non così lontano) potrebbe capitare di essere poco avvezzo all’utilizzo di strumenti di apprendimento come gli ambienti simulati ed appositamente preparati per essere “attaccabili”.

Personalmente ne faccio poco uso pur trovandoli molto divertenti ed interessanti: il mio approccio mi porta a trovare più stimolante costruire un ambiente realistico, spesso riproducendo scenari reali che ho incontrato, per allenare una tattica o preparare qualcosa di nuovo. Ovviamente questo ha senso per chi ha esigenza di immergersi in scenari reali, mentre chi è in una fase di studio o di miglioramento di specifiche skills probabilmente trova più vantaggioso utilizzare un ambiente simulato e preparato appositamente per quell’esigenza.

Ho avuto modo di usare diverse piattaforme compreso il progetto italiano pwnx.io che, lo dico senza problemi, a me piace molto. Si tratta chiaramente di ottime risorsa per imparare, per prendere confidenza con gli ambienti, per crescere. Va anche tenuto in considerazione il fatto che il mondo vero di solito è un po’ diverso, non intendo più facile o più difficile ma semplicemente diverso. Usiamo quindi queste piattaforme con la consapevolezza di affrontare qualcosa che è stato creato ad hoc.

Banale? Come al solito sì, ma non credo di essere l’unico che si è trovato d’avanti ad un “Cyber Security Expert” con punteggi favolosi sulle piattaforme di simulazione e con gravi lacune tecniche sul funzionamento base di un sistema o di una rete. Diciamocelo, se approcciamo così queste piattaforme – che, ripeto, sono utilissime per imparare – stiamo commettendo un errore non da poco.

Come sempre per me la cosa migliore è fare un po’ di mix, esplorare più scenari, più piattaforme, più argomenti e farsi un’idea generale per poi approfondire l’ambito che più ci interessa o dove preformiamo meglio… ma approfondire sul serio, non solo a livello di tools e scripts da usare in batteria… non basta capire come funzionano le cose ma anche perché funzionano. La famosa differenza tra “apprendere” e “comprendere” (rif. alle lezioni di Umberto Galimberti).

Con questo spirito condivido gli articoli ed i post sui miei lab di studio che simulano situazioni reali e con questo spirito questa sera partecipo ad una CTF con un team letteralmente improvvisato al puro scopo di condividere un’esperienza assieme ed imparare dal confronto (https://ctf.nahamcon.com/).

Per chi vuole fare due chiacchiere ci vediamo questa sera sul mio server Discord o sul canale Twitch.

cyber security, OT/IoT

Il device IoT e la procedura di aggiornamento automatico.

Vi condivido una breve riflessione a seguito di diversi casi reali che ho avuto modo di osservare nelle ultime settimane, ovviamente senza dare riferimenti di nessun tipo sui protagonisti. E’ per me importante condividere questo tipo di esperienza per un motivo banale: è qualcosa che può accadere a chiunque e non è detto che si abbiano gli strumenti per intercettare rapidamente alcuni indicatori di compromissione, è quindi opportuno condividere esperienze in merito al fine di essere tutti più consapevoli.

Lo scenario è oggi un grande classico ma solo un paio di anni fa, quando ne parlavo con i diretti interessati, sembrava fantascienza: un dispositivo IoT interconnesso alla rete dell’azienda con esigenza di accesso alla rete internet per conversare, anche solo dall’interno verso l’esterno, con i sistemi in cloud del fornitore e/o gestore del servizio. Nel corso dell’ultimo anno ho seguito diverse attività in ambito cyber sec. in contesti di “rete di fabbrica” ed ho avuto la fortuna di vedere in dettaglio alcune implementazioni. La banalizzo un po’ per rendere il concetto fruibile a più persone possibili, gli esperti mi perdoneranno ed eventualmente integreranno con la loro saggezza (sempre apprezzata).

Di solito abbiamo diversi dispositivi che dialogano con i sistemi di produzione per raccogliere informazioni e/o impartire istruzioni. I sistemi su cui queste informazioni vengono depositate possono essere all’interno dell’infrastruttura di rete come all’esterno. Molti player del mondo Public Cloud mettono a disposizione fantastiche piattaforme per la gestione di questi dati, non è quindi raro trovare sistemi IoT che dialogano con l’esterno della rete per atterrare sui sistemi che ospitano i servizi incaricati di elaborare i dati raccolti.

Quella che nel disegno è definita come “magic network(s)” sappiamo essere un tema complesso ma non è il focus di questo post; l’argomento segregazione delle reti in ambito IT ed OT in risposta alle esigenze di prevenzione delle minacce informatiche che hanno come target i sistemi industriali merita un capitolone dedicato. In questa occasione mi concentro sulle implicazioni di un sistema che dall’interno della rete è titolato a dialogare con un sistema all’esterno della rete di cui non abbiamo una completa gestione (visto che non è nostro) e di cui non siamo in grado di definire direttamente le politiche di sicurezza dovendo accettare, si spera dopo averle validate, quelle del fornitore.

In relazione ai dati scambiati il tema è relativamente semplice: proporzionalmente all’impatto che avrebbe la perdita, la manomissione o la sottrazione di questi dati dovremmo definire delle politiche di protezione, dalla sicurezza della comunicazione alle politiche di backup dei dati storici. Questo è un elemento che di solito trovo presidiato: si cerca di utilizzare protocolli che facciano uso della cifratura e si prediligono servizi consoni al trasferimento di informazioni. Per farla breve, c’è ancora chi spara archivi .zip via FTP ma, almeno nei contesti in cui opero io, sono decisamente pochi.

Avendo la possibilità di dialogare sempre con la propria infrastruttura cloud il dispositivo IoT viene spesso dotato di procedure di self provisioning si per le configurazioni che per le componenti software, fino a poter anche aggiornare il firmware del dispositivo stesso. E’ una scelta tecnicamente validissima in quanto da modo al fornitore di aggiornare il dispositivo senza intervenire on-site, sarà quindi il dispositivo a chiedere ai sistemi centralizzati se ci sono nuovi elementi software da installare o configurazioni da modificare. Per chi fa il mio lavoro ricorda molto il funzionamento dei C2.

Se chi gestisce la rete in cui il dispositivo viene inserito ha l’onere di assicurarsi che le policies di comunicazione siano idonee (ne parliamo in un post a parte come già detto), chi gestisce la cloud deve garantire la sicurezza delle informazioni e dei sistemi a cui i devices accedono. Un threat actor in grado di accedere ai sistemi cloud potrebbe compromettere in profondità il sistema in cloud oppure potrebbe limitarsi a manomettere il sistema al fine di far atterrare sul device IoT una componente malevola. In questo caso l’attacker avrebbe potenziale accesso a tutti i sistemi IoT che afferiscono alla cloud compromessa.

La scelta dipende ovviamente dalle funzionalità che il sistema mette a disposizione: se è possibile impartire comandi al dispositivo IoT (ci sono sistemi che lo prevedono per garantire un certo livello di amministrazione) diventa possibile eseguire azioni anche molto invasive dall’interno della rete target in un contesto tipicamente delicato come la rete di fabbrica, diventa quindi semplice eseguire attività di ricognizione a caccia di altri sistemi o informazioni utili a mettere radici.

Come intercettare il problema

Premesso che dovremmo iniziare a lavorare di prevenzione qualificando opportunamente i fornitori, è bene avere una strategia di intercettazione e gestione di questa tipologia di incident. Non avendo pertinenza sulla componente cloud ed essendo le comunicazioni necessariamente autorizzate oltre che cifrate, la detection difficilmente può avvenire a monte (non impossibile, ma difficile). Quello che possiamo sicuramente fare è lavorare sulla pertinenza locale: eventuali attività da parte dell’attacker genereranno sicuramente del traffico in rete verso destinazioni differenti dalle solite. In molti casi questi dispositivi dialogano con un numero limitato di sistemi interni, potremmo quindi insospettirci di qualsiasi comunicazione verso hosts insoliti (funzionalità disponibile in molte soluzioni di detection).

Anche il tipo di traffico è un elemento importante, questi sistemi solitamente utilizzano un set specifico di protocolli del mondo OT oltre ad HTTPS per la comunicazione con le API ed a qualche protocollo base come NTP e DNS. Proprio su questi ultimi due va fatto un focus ulteriore: esistono diverte tattiche di tunnelling basate proprio su questi protocolli, pur essendo traffico spesso legittimo è bene fare degli approfondimenti per verificare che non siano in corso azioni di exfiltration. Personalmente suggerisco di utilizzare, se disponibili, servizi interni per NTP e DNS in modo da negare il traffico verso l’esterno da questi dispositivi, ma non è sempre possibile.

Gli attacchi informatici, ce lo diciamo spesso, non sono composti da singola azioni chirurgiche. Esiste un path, un set di azioni che vengono svolte in sequenza e che inevitabilmente lasciano qualche traccia. In un contesto come quello descritto, in cui l’attacker di fatto trova un punto di accesso a causa di un problema introdotto da un terzo attore, è indispensabile essere preparati per intercettare gli effetti delle azioni di attacco più che le azioni in se in quanto potenzialmente non visibili.

Conclusioni e riflessioni

Nel prossimo periodo parlerò in più occasioni di detection e delle soluzioni e servizi che possiamo mettere in campo a tal fine. In questa occasione la riflessione che vorrei portare si riferisce ad un tema di strategia e predisposizione. E’ ovvio che le aziende debbano dotarsi di strumenti che avranno l’esigenza di dialogare con l’esterno della rete. E’ anche ovvio che le aziende non possono gestire la sicurezza informatica dei propri fornitori. Quello che è possibile fare è qualificare il fornitore definendo dei requisiti minimo di sicurezza che il fornitore deve rispettare.

Le aziende e le organizzazioni sono troppo interconnesse tra loro per non considerare questo aspetto della sicurezza informatica. E’ un tema di strategia che possiamo gestire in modo strutturato.