Escalada de privilégios em Linux raramente é sobre um exploit de kernel espetacular. Na esmagadora maioria dos casos é falha de configuração: uma permissão larga demais, uma tarefa agendada mal escrita, um binário com poder que não deveria ter.
Isso é bom para quem defende, porque tudo abaixo se corrige sem comprar nada, e é bom para quem testa, porque a enumeração metódica encontra o caminho mais rápido que a tentativa de exploit.
A regra: enumerar antes de tentar
O erro do iniciante é sair disparando exploit de kernel. O profissional enumera primeiro, porque a escalada por configuração é mais confiável, mais silenciosa e não derruba a máquina, ao contrário de um exploit de kernel que falha.
A ordem abaixo é por probabilidade de sucesso na minha experiência.
1. Quem sou eu e o que já posso
id
sudo -l
groupsO sudo -l é a primeira parada por um motivo: ele lista o que o usuário pode executar como outro usuário, muitas vezes sem senha. Um único binário mal permitido no sudo costuma ser o caminho inteiro.
Se aparecer algo como (ALL) NOPASSWD: /usr/bin/find, a escalada acabou antes de começar, porque muitos utilitários comuns conseguem executar comando arbitrário quando rodados com privilégio.
2. Binários com SUID
Um binário SUID roda com o privilégio do dono, não de quem o executa. Se o dono é root e o binário permite executar comando, é escalada direta.
find / -perm -4000 -type f 2>/dev/nullCompare a saída com o que é esperado em uma instalação limpa. Binário SUID fora do comum, ou binário conhecido por permitir fuga, é o alvo. A checagem seguinte é sempre: este binário permite executar outra coisa?
3. Tarefas agendadas
Tarefa do cron que roda como root e chama um script gravável por você é escalada clássica: você edita o script e espera a próxima execução.
cat /etc/crontab
ls -la /etc/cron.*
# procure script chamado pelo cron que voce consiga escrever
find / -writable -type f 2>/dev/null | grep -vE '^/proc|^/sys'Preste atenção especial a script que usa caminho relativo ou curinga. Ambos abrem brechas que não dependem de você poder editar o script em si.
4. Serviços e sockets rodando como root
ps aux | grep '^root'
ss -tulpnServiço local escutando só na máquina, rodando como root, é alvo frequente. Ele não aparece de fora, e por isso costuma estar desatualizado. Foi por não estar exposto que ninguém o corrigiu.
5. Credenciais deixadas para trás
Antes de qualquer técnica sofisticada, procure o óbvio: senha em arquivo.
grep -RiE 'password|senha|api_key|secret' /etc /opt /var/www 2>/dev/null | head
cat ~/.bash_history
find / -name "*.conf" -o -name ".env" 2>/dev/null | xargs grep -l -i pass 2>/dev/nullArquivo de configuração de aplicação e histórico de shell são minas de credencial. Senha reaproveitada entre serviço e usuário é o que transforma um achado pequeno em acesso total.
6. O kernel, por último
uname -a
cat /etc/os-releaseSó depois de esgotar configuração é que vale olhar a versão do kernel em busca de falha conhecida. E mesmo aqui, em ambiente de produção, exploit de kernel é a última opção: ele pode travar a máquina, e derrubar produção durante um teste é o tipo de estrago que anula o valor do trabalho.
Automatizar sem terceirizar o julgamento
Existem scripts que rodam toda essa enumeração de uma vez. São úteis para não esquecer etapa, mas não substituem a leitura. A ferramenta lista candidatos; decidir qual caminho é seguro e vale a pena continua sendo trabalho humano.
Use o automático para levantar, e o manual para escolher. Confiar cegamente na pontuação da ferramenta é como tratei em Metodologia de teste de invasão em aplicações web: achado sem entendimento é ruído.
O lado da defesa
Cada item acima é também um item de endurecimento. Revisar o sudo, auditar binários SUID, corrigir scripts de cron graváveis e caçar credencial em arquivo é o mesmo trabalho, com sinal trocado.
Vale integrar isso à rotina descrita em Hardening de servidores Linux para pequenas empresas. Quem endurece pensando em como escalaria privilégio fecha justamente as portas que o atacante procura.