SSRF Através de uma Proteção que Confia no Loopback para Acessar um KV Store Interno

Este é um server-side request forgery (SSRF) em camadas. O buscador até tem uma proteção, mas ela é uma lista de bloqueio: rejeita hosts externos e deixa passar tudo que está no loopback, supondo que só serviços internos confiáveis vivem ali. Essa suposição é a vulnerabilidade. Uma lista de bloqueio de hosts externos não diz nada sobre o que está co-localizado na máquina, e hosts modernos rodam bastante coisa: um agente de service mesh, um endpoint de metadados, uma API de admin, um key-value store. Qualquer um desses fica acessível assim que o loopback é permitido.

O ataque, portanto, não é uma única virada de chave, mas uma pequena cadeia de descoberta. Sondar um caminho de admin no loopback retorna um 403, mas o corpo do erro fala demais: ele nomeia um agente Consul na porta 8500 e descreve o formato de URL /v1/kv/<key> usado pelos segredos. A API HTTP do KV do Consul não exige autenticação por padrão em muitas implantações, então listar o keyspace e depois ler /v1/kv/flag entrega o segredo armazenado. Cada etapa é orientada apenas pela resposta da etapa anterior - isso é o que torna esse exercício uma descoberta interna realista, e não uma simples virada de um único parâmetro.

A causa raiz é tratar para onde uma requisição vai como um substituto para se ela é permitida. Loopback não é uma fronteira de confiança, e serviços internos que supõem que a rede os protege caem no instante em que um SSRF os alcança.

• Tentar URLs externas e concluir que o endpoint é seguro quando a proteção as bloqueia - o ponto principal é que o loopback ainda é permitido.
• Passar rápido pelo 403 em /admin em vez de ler seu corpo, que nomeia o agente Consul, sua porta e o formato de URL do KV.
• Supor que uma API de infraestrutura interna como o Consul KV exige autenticação, quando sua API HTTP é frequentemente exposta sem ela no loopback.
• Ler a listagem do KV e parar por aí, em vez de seguir até a chave específica /v1/kv/flag que guarda o segredo.

Substitua a lista de bloqueio por uma lista de permissão positiva de alvos exatos e pretendidos, e nunca trate o loopback como inerentemente seguro. Combine isso com autenticação em todo serviço interno, para que o alcance de rede sozinho não seja suficiente.

• Permita apenas os hostnames e caminhos específicos de que o buscador legitimamente precisa; rejeite todo o resto, incluindo loopback e link-local, a menos que seja explicitamente necessário.
• Resolva e reverifique o destino após a resolução de DNS para vencer o rebinding, e proíba redirecionamentos para alvos não permitidos.
• Exija autenticação e ACLs nas APIs internas: habilite as ACLs do Consul, vincule o agente a uma interface restrita e nunca exponha a API do KV sem um token.
• Torne as respostas de erro genéricas: nunca vaze nomes de serviços internos, portas ou esquemas de URL no corpo de erro voltado ao cliente.