Além dos scripts de elevação de privilégios

Você acabou de conseguir uma shell de baixo privilégio em um servidor Linux. A primeira reação costuma ser rodar um script automatizado e torcer para ver uma linha vermelha brilhando na tela. Mas e quando o script não entrega nada óbvio, ou o ambiente é restrito e você precisa enumerar na mão?

A maior parte das falhas de configuração em ambientes reais e CTFs não está em exploits de kernel complexos, mas em serviços internos rodando como root em portas locais (localhost).

Neste artigo básico, vamos dissecar a metodologia para identificar e explorar serviços locais ocultos no Linux, usando um caso clássico: uma porta de debug do Node.js esquecida pelo administrador. (e pra eu voltar aqui quando esquecer algum comando)

1. A Ilusão do Nmap Externo

Quando você faz o scan de portas de fora da máquina (nmap -sV -p- <IP>), você só enxerga o que está exposto publicamente para a rede, geralmente as portas 22 (SSH), 80 (HTTP) e 443 (HTTPS).

No entanto, desenvolvedores e administradores frequentemente amarram ferramentas de monitoramento, bancos de dados administrativos ou interfaces de depuração diretamente na interface de loopback (127.0.0.1 ou localhost), assumindo erroneamente que:

"Se não está aberto para a internet, está seguro."

O problema? No momento em que um atacante obtém qualquer shell local (como www-data ou engineer), o perímetro interno desaparece.

2. O Primeiro Comando: Caçando Portas Locais

Assim que pisar na máquina, verifique quais portas estão escutando internamente:

ss -tulnp

ss -tulnp

(Ou netstat -tulnp em sistemas mais antigos).

O que procurar na saída:

Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0       511     127.0.0.1:9229       0.0.0.0:*          -
tcp    LISTEN  0       128     0.0.0.0:22           0.0.0.0:*          -b

Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0       511     127.0.0.1:9229       0.0.0.0:*          -
tcp    LISTEN  0       128     0.0.0.0:22           0.0.0.0:*          -b

A porta 9229 amarrada em 127.0.0.1 é um sinal de alerta imediato. Ela é a porta padrão do V8 / Node.js Inspector.

3. Quem é o Dono do Processo?

Identificou uma porta local suspeita? O próximo passo é cruzar essa informação com a tabela de processos para descobrir:

1. Quem está rodando o processo (root ou usuário comum?).
2. Qual comando exato foi executado para iniciá-lo.

Execute:

ps aux | grep -i '^root' | grep -v '\[.*\]'

ps aux | grep -i '^root' | grep -v '\[.*\]'

Dica: O filtro -v '\[.*\]' remove as threads internas do kernel, limpando o ruído da tela.

Exemplo de resultado encontrado:

root  1414  0.0  1.1  1066664  47048 ?  Ssl  12:18  0:03 /usr/bin/node --inspect=127.0.0.1:9229 /opt/uptime-monitor/worker.js

root  1414  0.0  1.1  1066664  47048 ?  Ssl  12:18  0:03 /usr/bin/node --inspect=127.0.0.1:9229 /opt/uptime-monitor/worker.js

Aqui está o vetor de ataque completo: um processo rodando como root, com uma flag de depuração ativa (--inspect), executando um script customizado em /opt/uptime-monitor/.

4. Validando o Alvo via Linha de Comando

O Node Inspector expõe uma API HTTP/WebSocket local. Para validar se ele responde a comandos, faça uma requisição rápida:

curl -s http://127.0.0.1:9229/json

curl -s http://127.0.0.1:9229/json