Alcance o Serviço Interno: Reconhecimento de Rede a Partir de um Shell

Assim que você tem um shell em um host dentro de uma rede, você herda o alcance desse host. Um serviço de monitoramento ou health check que fica bloqueado por firewall da internet pública continua totalmente aberto para qualquer coisa rodando em uma máquina que já está na sub-rede interna. Esse é o ponto central do exercício: o serviço nunca deveria ser exposto, então seus criadores confiaram na fronteira de rede como a única barreira contra atacantes. No momento em que você ganha um ponto de apoio, essa fronteira fica para trás.

Essa é exatamente a confiança que uma vulnerabilidade de Server-Side Request Forgery abusa de fora. O SSRF engana um servidor público para que ele faça requisições em seu nome, então as requisições chegam de dentro do perímetro e atingem serviços que presumem que qualquer chamador interno é confiável. Aqui você está simplesmente fazendo isso diretamente: você é o chamador interno. O serviço interno realmente pede um token, mas uma verificação de token só é tão forte quanto o sigilo desse token, e tokens têm o hábito de acabar em algum lugar onde podem ser lidos.

A segunda lição é sobre onde os segredos se escondem. Um arquivo de configuração pode dizer educadamente que não guarda o segredo, mas o agente que conversa com o serviço precisa saber o token para enviá-lo. Se esse token foi compilado no binário distribuído, ele fica ali em texto puro junto com a URL à qual é anexado. Um programa compilado não é um cofre opaco; é um arquivo cheio de strings legíveis.

• Assumir que um serviço interno é seguro porque a internet não o alcança, o firewall não faz nada quando você está chamando de dentro da sub-rede.
• Desistir depois de ler o arquivo de configuração, que diz claramente que o token não está armazenado ali, em vez de olhar o binário do agente logo ao lado.
• Esquecer de escanear a faixa interna e tentar adivinhar a porta do serviço em vez de deixar o nmap reportar a que está aberta.
• Acessar o endpoint sem o token e parar na resposta 401, em vez de recuperar a credencial e reenviar a requisição.

Tratar a fronteira de rede como sua única autenticação é o erro raiz. Um serviço interno ainda deveria verificar quem está chamando, não apenas de onde a chamada veio. A segmentação de rede é uma camada útil, mas precisa ficar sobre uma autenticação real por chamador, não substituí-la.

• Autentique cada chamador com credenciais de curta duração e por cliente, emitidas por um gerenciador de segredos, nunca um único token estático compartilhado.
• Mantenha segredos fora dos artefatos distribuídos: injete-os em tempo de execução via variáveis de ambiente ou um vault, para que um binário vazado não vaze nada. Rode strings nos seus próprios builds antes do lançamento para confirmar.
• Revogue qualquer token no momento em que um host for comprometido, e limite o escopo de cada token para que um vazamento libere o mínimo possível.
• Aplique princípios de zero-trust internamente: mTLS ou requisições assinadas entre serviços, para que um atacante em um host não consiga consultar livremente o próximo.