reverse shell – Rocco Sicilia

Tempo fa mi ero imbattuto in un post su medium in cui si discuteva dell’utilizzo di git per gestire una reverse shell. Non è un tema nuovo, ho visto diverse presentazioni in vari eventi in cui sono state mostrate le potenzialità della tecnica che trovo interessante per diversi fattori tra cui:

la possibilità di utilizzare come “base” una piattaforma considerata affidabile come un servizio di versioning in cloud
la possibilità di utilizzare comodamente SSH o HTTPS come protocollo di comunicazione
la versatilità dello strumento in se (git)

Ho rispolverato l’argomento in questi giorni (attività in corso con il red team) ed ho approfittato per costruire un piccolo prototipo che sfrutti le funzionalità di git con qualche accorgimento in più. Di seguito il funzionamento del mio proof of concept ed il codice utilizzato in questa primissima versione dimostrativa.

Come funziona

Il processo è molto semplice, partiamo dal contesto. Si tratta a tutti gli effetti di una reverse shell, siamo quindi in una fase di post-exploitation in cui abbiamo ottenuto un accesso ad un sistema o abbiamo modo di interagire. E’ inoltre necessario, almeno in questa versione del tool, che git sia presente sul sistema target salvo poterlo installare senza destare sospetti.

Sfruttando una qualsiasi funzionalità che consenta ti eseguire ad intervalli uno script facciamo in modo di eseguire il seguente processo:

creiamo/aggiorniamo la repo locale del progetto
verifichiamo il contenuto dell’ultimo commit message
se contiene una stringa che corrisponde ad un comando bash, eseguiamo il comando sul sistema
ridirigiamo l’output del comando in un file di testo che fa parte della repo (es: output.txt)
eseguiamo il commit delle modifiche ed aggiorniamo la repo remota

L’unica differenza di sostanza con altre git-shell sta nel fatto che i comandi vengono solitamente posizionati encoded in un file che fa parte dalla repo. In questa versione ho utilizzato il campo dedicato ai messaggi delle commit per inviate i comandi alla shell mentre per ricevere gli output ho mantenuto il metodo classico.

Come risultato finale per dialogare con il sistema basta eseguire una commit sulla repo ed aspettare l’aggiornamento del file “output.txt” con la risposta.

Demo

Una piccola dimostrazione pratica per vedere gli step e le modalità di lavoro della versione 0.1 che rilascio solo a fini dimostrativi per ambienti unix-like. Seguiranno probabilmente integrazione per altri ambienti.

Per prima cosa è ovviamente necessario clonare la repo sulla macchina target:

$ git clone https://github.com/roccosicilia/sToolz

Il progetto è una collezione di piccoli tools, in questa occasione ci interessa solo il contenuto della directory RedTeam/C2demo/ dove troverete diversi file tra cui:

il file git-demo.sh con lo script da tenere in esecuzione sulla macchina target
il file git-output.txt dove verranno scritti gli output dei comandi alla shell

Nota sugli altri file: fanno parte di altre versioni della p-o-c ancora in sviluppo, la metodologia è la stessa ma i canali utilizzati sono differenti.

Usando una tecnica a vostro piacimento è necessario far girare periodicamente lo script git-demo.sh:

Lo script si occupa semplicemente di aggiornare la repo locale e verificare l’ultimo messaggio di commit: se il messaggio è NOP lo script non esegue azioni e procede con la prossima iterazione, in caso contrario legge il contenuto dell’ultimo commit e lo utilizza come comando da inviare al sistema locale. L’output del comando viene così inviato al file git-output.txt su cui si esegue la commit e la push verso la repo remota.

A questo punto è sufficiente eseguire una qualsiasi modifica ad uno dei file della repo (es: README) mettendo nel messaggio il comando da eseguire.

l’esempio più idiota che mi è venuto in mente

L’output del comando verrà quindi salvato all’interno del file git-output.txt e sincronizzato con la repository del progetto su GitHub o su altri repo Git di vostro gradimento.

Utilizzo in un contesto reale

Ripercorriamo assieme gli step usando solo la cli sia lato “attacker” (a sinistra) che lato target (a destra), tenendo in considerazione che questa versione dimostrativa non è dotata di una interfaccia utente che possa agevolare qualche comando.

In arancione sono evidenziali i due file che compongono la versione 0.1 della git-shell, mentre nel riquadro azzurro il comando che avvia il loop sulla macchina target. Non essendoci stati change sulla repo remota lo script in loop restituisce il messaggio che indica che non ci sono azioni da eseguire (NOP).

Mentre sul sistema target è in esecuzione lo script, sul sistema locale modifichiamo uno dei file della repo (in questo caso il README.md. Come previsto con un git status possiamo visualizzare la modifica in accesa di commit.

Una volta modificato il file possiamo eseguirne l’add e poi il commit (nell’esempio stiamo ancora usando la mia repository di test). Nell’esecuzione del commit, sottolineato in verde, vi è un comando specifico: per evitare problemi nell’utilizzo della stringa da utilizzare come comando sul sistema target si è adottata una forma che consenta di evitare gli spazi come carattere separatore.

Ora è sufficiente eseguire la push delle modifiche sulla repo ed attendere che il sistema remoto aggiorni la propria repository. In caso l’aggiornamento vada a buon fine dovremmo poter osservare la sincronizzazione delle repo:

A questo punto lo script avrà eseguito il comando passato tramite messaggio (df -kh) e scritto l’output sul file git-output.txt. Per accedere al contenuto sarà sufficiente aggiornare la repo sulla macchina locale leggere il contenuto del file:

Qualche riflessione

Come sicuramente in molti avranno avuto modo di sperimentare l’utilizzo dei blasonati tools di Penetration Testing viene spesso limitato dal fatto che i sistemi di sicurezza ne conoscono bene il comportamento e sono spesso in grado di bloccare specifiche azioni. L’esigenza di creare componenti “originali” per le suite più note o piccoli strumenti from scratch credo si manifesterà sempre più frequentemente.

Le reverse shell sono strumenti potenti e se ben pensate sono difficili da individuare. L’esempio presentato in questo breve post difficilmente potrebbe essere rilevato se non grazie a sistemi di controllo in grado di correlare l’azione in se (dei comandi git e del traffico https) ad un comportamento anomalo come l’intervallo regolare degli update o il fatto che la rete target non ha familiarità con gli host di atterraggio delle sessioni. Tecnica ancor più insidiosa se la si veicola tramite un dispositivo “guest”, non controllato dall’IT.

In questo proof of concept abbiamo giocato ma è mia intenzione valutarne gli effetti in contesti di analisi ed attività – ovviamente concordate – di adversarial simulation.

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.

Tag: reverse shell

GIT-SHELL: p-o-c v0.1