Pivô para o Banco de Dados: Movimento Lateral via SSH a partir de um Servidor Web
O desafio
Você tem um shell no web01, o servidor web público. O banco de dados fica em outra máquina, alcançável só de dentro. Ache o caminho, pivote para ela e leia o segredo que o banco esconde.
O que você vai aprender
- Reconhecer que um ponto de apoio em um servidor web público raramente é o objetivo final - os dados reais ficam em hosts internos segmentados para os quais você precisa pivotar.
- Ler um arquivo de configuração do cliente SSH (~/.ssh/config) para descobrir o próximo host, o usuário de login e a chave privada exata que autentica o acesso.
- Usar uma chave privada descoberta para autenticar em um host interno sem senha, já que a própria chave substitui a senha.
- Entender por que backups de banco de dados (saída do mysqldump) são um butim de alto valor, muitas vezes contendo segredos em texto puro que o banco em produção protege.
- Mapear uma rede interna a partir de artefatos já presentes na máquina: entradas em /etc/hosts, arquivos de configuração da aplicação e registros do known_hosts.
Habilidades testadas
Pré-requisitos
- Familiaridade para navegar em um shell Unix (cd, ls, cat) e ler dotfiles em um diretório home.
- Noção básica de como funciona a autenticação SSH baseada em chave (chave privada no cliente, chave pública no servidor).
Como funciona
Movimento lateral é o passo seguinte à invasão inicial. Raramente você cai exatamente onde estão os dados valiosos. Aqui você começa como www-data em web01, um servidor web voltado para a internet. O banco de dados é deliberadamente colocado em uma máquina separada que só aceita conexões de dentro da rede, então ele é invisível a partir de fora. Todo o desafio consiste em encontrar a ponte que os próprios operadores da aplicação já construíram entre as duas máquinas.
Erros comuns
- Tratar o servidor web como o destino final. A flag nunca está em
web01- ficar por ali fazendo grep na raiz web em busca de um segredo desperdiça todo o tempo disponível. - Ignorar o diretório
~/.ssh. O client config, a chave privada e a entrada no known_hosts juntos entregam o host, o usuário e o meio de fazer login - pular isso deixa você tentando adivinhar IPs e nomes de usuário. - Tentar forçar uma senha por brute force ou fornecer uma ao
ssh. Com uma chave de deploy em uso, não existe senha - a chave é a credencial. - Esquecer que o próprio banco de dados pode continuar trancado enquanto o backup vaza tudo. Depois do pivô, o butim está em um arquivo de dump em texto puro, não atrás de um login ativo no banco.
Como se proteger
A causa raiz é uma chave privada parada em um host alcançável e exposto à internet. Uma chave em web01 é um pivô esperando para acontecer: qualquer um que chegue ali herda uma rota sem senha direto para a máquina do banco de dados. Chaves usadas para deploy nunca deveriam ficar nos servidores que os atacantes alcançam primeiro - emita-as a partir de um pipeline de deploy controlado, dê a cada uma o escopo mais restrito possível (um comando forçado, um único host, sem shell interativo) e rotacione-as periodicamente.
A segunda falha é tratar um backup de banco de dados como menos sensível do que o próprio banco. O dump continha segredos em texto claro que o banco em execução teria protegido. Backups merecem os mesmos controles que os dados de produção.
- Segmente o banco de dados para que apenas uma conta de serviço da aplicação, não um usuário administrador interativo, consiga alcançá-lo, e aplique essa fronteira na camada de rede, não apenas por convenção.
- Restrinja o escopo das chaves SSH com as restrições
command=efrom=no authorized_keys; prefira certificados de curta duração a chaves privadas de longa duração. - Criptografe os backups em repouso, armazene-os fora do host do banco de dados e restrinja quem pode lê-los.
- Nunca faça commit nem deploy de chaves privadas junto com o código da aplicação ou a raiz web.