Molte figure con un background tecnico-informatico si dedicano alla scrittura di software per moltissimi motivi: dal puro piacere personale di costruirsi qualcosa di utile, anche solo per esigenze personali, fino ad arrivare ad esigenze operative o aziendali gestibili con un software custom. Personalmente ho scritto “molto” codice per automatizzare o velocizzare alcuni processi operativi ed analitici, anche in ambito Red Team è molto utile avere il proprio “arsenale” di tools custom. E’ qualcosa di abbastanza diffuso nel mondo IT: ci sono aziende che si sono scritte il proprio gestionale, che automatizzano processi tramite script fatti dagli addetti ai lavori, team che creano software per consentire a clienti e fornitori di interfacciarsi con processi aziendali. Tutto questo in molti casi (non tutti ma molti) viene fatto senza un metodo di sviluppo adeguato e senza una particolare attenzione alla sicurezza del codice. Il problema parte dalle fondamenta: chi scrive molto di questo codice non ha nozioni di sviluppo di codice sicuro.
un mio blocco di codice a caso
Non ho le competenze specifiche per parlarvi di codice sicuro, faccio un altro mestiere, posso però raccontarvi cosa succede quando introducete codice “home made” in un contesto aziendale. I software sono asset della vostra infrastruttura a prescindere da chi li ha prodotti, che si tratti del nuovo CRM o dello script che vi notifica l’esito dei backup giornalieri il contesto è quello di un software attivo all’interno della rete, accessibile almeno ad una parte dell’utenza, che genera interazioni con altri sistemi.
Esattamente come tutti gli altri asset anche il software prodotto internamente va gestito nel tempo, nel suo ciclo di vita. Potrebbe essere necessario correggere dei bug funzionali, aggiornare delle componenti di terze parti (vedi il concetto di Software Bill of Materials che Paolo Perego accennava qui), aggiornare le componenti core del software stesso. Quando adottiamo un prodotto software solitamente non ci preoccupiamo della qualità del software in modo diretto, ci si affida alla qualità del brand/partner che abbiamo selezionato. Uno dei parametri che probabilmente valuteremo è la frequenza con cui vengono rilasciate delle patch e la reattività del team di sviluppo in caso sia necessario correggere una vulnerabilità.
Abbiamo tutti imparato a limitare/eliminare l’utilizzo di software che presenta delle vulnerabilità, sappiamo che esistono vulnerabilità che consentono di manomettere il funzionamento dell’applicazione, possono consentire l’accesso a dati riservati e, in casi estremi, possono consentire l’accesso al sistema su cui è attivo il software vulnerabile. Questi rischi esistono nel software “enterprise” tanto quanto esistono nel software “home made”, con la differenza che di solito il software disponibile sul mercato (o prodotto dalla community) transita da processi di controllo, è sottoposto a più tipologie di test sulla sicurezza ed esiste un team che ne corregge, in modo strutturato, i bug.
Ora il concetto è abbastanza semplice: nonostante i team di sviluppo composti da professionisti, i controlli integrati nel processo di sviluppo ed i test di sicurezza capita di rilasciare software che presenti delle vulnerabilità. Cosa ci fa pensare che noi, all’interno del nostro team IT/DEV, non commetteremo errori?
Il punto di vista dell’attacker
In una sessione di attacco simulato, trovare qualcosa di “home made” potrebbe essere un ottimo punto di partenza per ottenere il controllo di un host sfruttando vulnerabilità abbastanza classiche. Ovviamente non è possibile generalizzare ma ci sono degli elementi facili da indagare che potrebbero restituire all’attacker l’appiglio per compromettere la macchina che ospita l’applicazione vulnerabile.
Considerando solo la mia esperienza diretta (e chissà quante ne potreste raccontare voi) mi potrei aspettare di trovare qualche vulnerabilità a livello di gestione dell’upload di contenuti (https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload) con la conseguenza di poter portare sul sistema target un file malevolo sa eseguire successivamente tramite una chiamata http/https.
Altro grande classico, soprattutto in contesti dove sono presenti piccole integrazioni a livello di sistema, la possibilità di eseguire comandi sulla macchina remota tramite injection (https://owasp.org/www-community/attacks/Command_Injection). Spesso alcuni script di integrazione utilizzano chiamate al sistema operativo locale a cui passano delle stringe di comandi da eseguire direttamente in “shell”. Altra grande opportunità per prendere possesso della macchina che ospita applicazioni di questo tipo.
In questi casi diventa relativamente semplice per un attacker sfruttare vulnerabilità anche molto gravi ma spesso non sottoposte a nessuna verifica di merito: essendo il software autoprodotto difficilmente ci sarà un processo di update della piattaforma o una verifica periodica delle nuove vulnerabilità. Eppure sarebbe abbastanza ovvio: come siamo abituati a chiedere il vulnerability assessment dei sistemi potremmo farso anche per il software prodotto internamente.
Qualche risorsa
In relazione allo sviluppo di codice sicuro forse una delle risorse più note è la documentazione OWASP (https://owasp.org/), utilissima soprattutto per comprendere anche le varie tipologie di vulnerabilità di cui il nostro codice potrebbe essere afflitto.
Ci sono poi una tonnellata di libri specifici per i differenti linguaggi, non li ho letti quindi non mi permetto di dare consigli. Per segnalare qualche risorsa a noi geograficamente vicina, oltre a già citato canale e blog di Paolo, a settembre, in occasione dell’edizione 2023 di RomHack, ci saranno dei corsi tematici tra cui una sessione interamente dedicata alla sicurezza del codice: https://romhack.io/training/code-review/.
Premetto che sto sistemando un po’ di appunti e materiale in relazione alle attività immediatamente successive all’acquisizione di un primo accesso ad un sistema target (a prescindere dal modo in cui è stato ottenuto) in un contesto di simulazione di attacco.
Sto lavorando su due fronti: il primo prettamente ludico relativo alle mie “play session” in live dove sto giocando su una vecchia macchina (breakout di vulnhub), il secondo operativo in relazione ad azioni su infrastrutture presidiate. C’è un elemento che ricorre in entrambi i contesti anche se per motivi differenti: per vincoli del sistema o per la presenza di specifici controlli non sempre è possibile dotare la macchina target di “strumenti” aggiuntivi, bisogna necessariamente arrangiarsi con ciò che si ha sul sistema vittima. In molti corsi e laboratori a tema cyber sec. si fa pesante uso di strumenti che, se utilizzati in contesti reali, vedremmo il team IT di qualsiasi organizzazione mediamente strutturata farsi una grassa risata.
Gli attacker utilizzano spesso tecniche appositamente studiate per non essere identificati facilmente ed una di queste è proprio utilizzare ciò che il sistema colpito mette a disposizione: se la macchina dove è stato guadagnato il primo accesso è un webserver con php o python è molto probabile che l’attacker utilizzi questi strumenti per portare a bordo del sistema scripts specifici o eseguire comandi diretti.
Considerazioni lato Red Team
Provo a semplificare il mondo. Diciamo che ci sono quattro principali tipologie di oggetti su cui si potrebbe approdare:
un ambiente con O.S. Microsoft Windows
un ambiente con O.S. *nix
una network appliance
un device con O.S. {booo} che eroga servizi aspecifici (una stampante, una Smart TV, ecc)
Ovviamente non sono gli unici elementi ma questo elenco copre una vasta percentuale di sistemi in una rete IT. Va anche detto che una buona azione di ricognizione potrebbe migliorare molto la precisione di questa lista ed in alcuni casi si riescono ad ottenere informazioni di dettaglio su sistemi e software in uso, ma per lo scopo del post ci basta questo.
Continuando con le considerazioni puramente speculative possiamo dire che gli ambienti con O.S. Windows e Unix/Linux mettono a disposizione un set di software e utility molto più ampio rispetto alle appliance, fanno eccezione solo quei device interamente basati su una qualche distribuzione Linux e quindi ricche di utility (come alcune tipologie di NAS o network device SOHO). Qualsiasi sia lo scenario le azioni che cronologicamente un attacker – e quindi anche il Red Team – vorrebbe compiere sono:
garantirsi un’accesso permanente al sistema sul quale è stata “guadagnata la posizione”
raccogliere informazioni sul sistema e sull’ambiente circostante
iniziare ad esplorare l’ambiente circostante a caccia di informazioni o per raggiungere altri sistemi interessanti (lateral movement per gli amici)
Per mia esperienza (e come sempre sarei felice di ricevere anche altri pareri) il buon proseguimento dell’azione offensiva dipende molto dal livello di dettaglio che si riesce ad ottenere dell’infrastruttura attaccata. Se in Red Team acquisisce molte informazioni sostanziali potrà valutare meglio come muoversi all’interno della rete. Ad esempio prima di attivare un C2 sarà opportuno valutare che tipologia di canali potrebbero passare inosservati.
E’ un tema già affrontato su queste pagine quando ho parlato di OSInt: meglio conosco il mio target e più efficace sarà l’azione offensiva. La differenza, non da poco, sta nel fatto di essere già all’interno di uno dei sistemi, contesto che permette di ottenere molte informazioni ed una posizione privilegiata per sfruttarle.
Ovviamente più il sistema target è ricco di dati e utility e più l’attacker avrà vita facile. Questa consapevolezza è quella che dovrebbe far riflettere sul livello di hardening dei sistemi: situazioni troppo “permissive” come l’utilizzo troppo esteso di utenti con privilegi elevati o la configurazione di servizi ed applicazioni in esecuzione con privilegi amministrativi, possono dare al Red Team la possibilità di agire sul sistema colpito in modo molto invasivo.
I macro elementi da cui personalmente mi piace iniziare le “indagini” sono la possibilità di comunicare all’esterno della rete tramite canali leciti e la possibilità di eseguire manovre sul sistema target e verso altri sistemi utilizzando utenti/profili con un basso livello di privilegi. Una situazione più che comoda potrebbe essere quella di atterrare su una macchina che ha modo di navigare senza particolare limiti, anche se attraverso firewall o proxy, e con una CLI di qualche tipo. Una bash o una powershell sono strumenti con cui si possono fare molte cose.
Qualche esempio per comprendere meglio: come mostrato in una recente demo (e nella live del 4 febbraio ci ritorniamo) alcune azioni possono essere più rumorose di altre: in una rete presidiata può fare molta differenza eseguire una scansione “massiva” rispetto ad una scansione molto mirata, come è diverso eseguire dei comandi su una CLI rispetto a lanciare uno script in PowerShell. E’ abbastanza frequente poter disporre di un accesso verso internet con destinazione servizi di largo utilizzo come Microsoft 365, Google Drive o Dropbox. Si tratta di servizi assolutamente leciti che l’attacker può utilizzare come “punto di appoggio” nello scambio di informazioni o per impartire comandi attraverso un C2 in grado di comunicare all’interno di un canale “nascosto”.
Considerazioni lato Blue Team e IT
Come noto non è il mio ambito di specializzazione, quindi a maggior ragione spero di ricevere feedback e pareri su quanto scrivo e condivido. Faccio una riflessione generale, figlia dell’esperienza su campo e del confronto con SOC Analyst, Security Manager e CISO.
Esiste, prima di tutto, un problema di “scope”: abbiamo la capacità di osservare moltissimo ma spesso tale capacità non viene scaricata a terra. Esiste un problema di “mindset”: deleghiamo molto ad una tecnologia troppo spesso configurata in modo non idoneo, perdendo di vista o non considerando che chi attacca ha una elevata capacità di adattamento al contesto e, per quanto segua un modello, non ha regole statiche a cui obbedire.
Concettualmente mi piace il modello Zero Trust, al netto dell’applicabilità il concetto è assolutamente sano: non è possibile, in una strategia di difesa, dare per buono qualcosa. Tutto è vulnerabile e tutto potrebbe essere attaccato. Tutto. Se non si parte da questo punto fermo l’effetto è quello che osservo quotidianamente: piccole falle logiche e/o tecniche che si sommano, si aggregano fino a formare la classica valanga ingestibile.
Osservare tutto l’osservabile è un buon punto di partenza (ne ho parlato nel post sulla detection), ma contemporaneamente vanno irrobustiti i sistemi ed i processi. Il SIEM non risolve il problema delle vulnerabilità critiche, il SOC non risolve il problema della bassa consapevolezza. Sono strumenti utili all’interno di una strategia più ampia e che deve tener conto di come si comporta l’avversario e non solo di ciò che presumiamo di sapere.
Mia conclusione alla riflessione
A mio parere da questa situazione se ne esce solo collaborando, costruendo un confronto (che molti già fanno, fortunatamente) tra Red Team e Blue Team.
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.
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.
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:
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.
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.
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.
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.
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.
OWASP
Open Web Application Security Project
Fondazione no-profit che lavora per migliorare la sicurezza del software con particolare riferimento alle applicazioni del mondo WEB (https://owasp.org/)
OSSTMM
Open Source Security Testing Methodology Manual
Manuale 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/.
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.
Rocco Sicilia 