O cabeçalho que diz onde você está: spoofing de um endereço de origem confiável
O desafio
A Thornbury cuida do controle de acesso de algumas dezenas de prédios, e as agendas de portas são somente leitura para quem está fora da rede de gestão. Essa restrição é real: a API recusa você a partir da internet e diz isso. Ela também é aplicada perguntando ao chamador onde o chamador está. Obtenha a agenda do site de Leeds, leia as exceções no final dela, e diga qual porta um chamado da manutenção deixa aberta para qualquer um que chegar nela pelos próximos dois meses.
O que você vai aprender
- Explicar para que serve o X-Forwarded-For e por que seu valor é controlado pelo atacante
- Usar a própria divulgação no corpo do erro para construir o bypass
- Entender que proxies discordam sobre qual entrada da lista é o cliente
- Reconhecer a localização de rede como autenticação e por que isso falha na camada 7
- Rastrear uma falha de autorização de API até uma consequência de segurança física
Habilidades testadas
Pré-requisitos
- A estrutura de uma requisição HTTP
- O que é uma faixa de IP privado
Como funciona
Quando uma requisição passa por um load balancer ou um CDN, a aplicação por trás dele vê o endereço do proxy em vez do endereço do usuário. O X-Forwarded-For existe para corrigir isso: o proxy anota o endereço que viu e acrescenta à lista conforme a requisição viaja. É uma pista, registrada por intermediários, em um campo de cabeçalho.
Tratá-lo como prova de localização inverte a confiança. Qualquer coisa que alcance a aplicação diretamente, ou por meio de um proxy que acrescenta em vez de substituir, pode definir o valor como quiser, e a verificação que deveria significar está na rede corporativa passa a significar diz que está na rede corporativa. O único valor em que você pode confiar é o que o seu proxy mais externo escreveu, e somente se esse proxy sobrescrever em vez de acrescentar.
O detalhe do parsing é uma classe inteira de bugs por si só. Algumas implementações leem a primeira entrada, outras a última, outras a última não confiável. Dois componentes no mesmo parque lendo pontas opostas é como uma requisição é permitida por um e registrada como outra coisa pelo outro, e é por isso que o corpo do erro aqui menciona qual ponta ele usa.
Erros comuns
- Acrescentar o endereço interno.
203.0.113.45, 10.12.0.9é recusado, porque essa API lê a primeira entrada. A resposta diz isso. - Tentar 127.0.0.1. O loopback é uma zona de confiança diferente e essa allowlist quer um endereço de gestão específico.
- Responder goods-in. A OVR-2288 estende uma janela de entrega por um dia e ainda exige cartão.
- Responder plant-room. A OVR-2294 é de um único dia e mantém cartão mais PIN.
- Responder lobby. Sua agenda normal é a mais movimentada, mas uma porta aberta programada com cartão e PIN durante o horário comercial não é o achado.
- Editar o token ou o path. O bearer token é válido e o endpoint está correto. Só a verificação de localização está quebrada.
Como se proteger
Decida a localização de rede a partir da conexão, não de um cabeçalho.
- Faça o proxy mais externo remover qualquer
X-Forwarded-Forrecebido e escrever o seu próprio. Se a aplicação for alcançável sem passar por esse proxy, o cabeçalho não tem sentido e o controle também não. - Não use o endereço de origem como autorização de forma alguma. Esse endpoint já carrega um bearer token; limite o token ao que o chamador pode ler e a verificação de localização se torna desnecessária.
- Pare de imprimir o endereço que a allowlist espera. O corpo do 403 transforma um problema de adivinhação em um copiar e colar.
- Corrija também a exceção. Uma porta configurada como unlocked por oito semanas deveria exigir um aprovador nomeado, uma expiração medida em dias, e um alerta enquanto estiver ativa.