Aprovado por outra pessoa: descubra o ator por trás de uma claim sub
O desafio
Um reembolso de 240.000 euros foi aprovado às 03h11 de um domingo. A trilha de auditoria de pagamentos aponta Dele Okonkwo, diretor financeiro, que dormia em outro fuso horário e cujo notebook estava no cofre de um hotel. A conta dele não foi comprometida: não há login às 03h11, nenhum dispositivo novo, nenhum desafio de multifator falhado, nada. A trilha de auditoria está dizendo a verdade sobre o token que recebeu. Este é o token, exatamente como chegou à API de pagamentos. Outra pessoa está dentro dele. Diga quem.
O que você vai aprender
- Ler todas as claims em um payload JWT, incluindo objetos aninhados
- Distinguir o sujeito de um token do ator que o está usando
- Reconhecer valores de amr como evidência de como uma sessão foi criada
- Explicar por que uma trilha de auditoria que registra apenas sub atribui incorretamente ações delegadas
- Descrever os controles que uma identidade mal atribuída burla silenciosamente
Habilidades testadas
Pré-requisitos
- O que é um JWT e que seu payload é codificado, não criptografado
Como funciona
Um token normalmente responde a uma pergunta: quem é esse. A delegação acrescenta uma segunda, e as duas respostas não são iguais. sub é o sujeito, a identidade com cujas permissões a requisição vai rodar. act é o ator, a identidade que de fato está conduzindo a ação. Consoles de suporte, ferramentas de break-glass de plantão e agentes automatizados produzem tokens com os dois, e o formato é padronizado exatamente por esse motivo.
Nada disso é um ataque por si só. O token está assinado corretamente, a API de pagamentos o valida corretamente, e o reembolso passa com a autoridade do diretor porque é para isso que a delegação existe. A falha está mais adiante: uma trilha de auditoria que registra apenas sub transforma a ação de um agente de suporte na ação do diretor, de forma permanente e convincente.
O que essa atribuição incorreta custa é todo controle baseado em identidade. Regras de segundo aprovador, revisão fora do horário, detecção de anomalias em contas privilegiadas e a própria investigação, todos olham para um nome. Dê a eles o nome errado e todos concordam que nada de incomum aconteceu, que foi exatamente o que o time da Harbourline encontrou quando foi investigar.
Erros comuns
- Responder d.okonkwo. Essa é a
sub, a autoridade que está sendo emprestada. A trilha de auditoria já dizia isso, e foi o que tornou o incidente confuso. - Procurar uma assinatura forjada. O token é válido. Supor que todo desafio de token é uma falsificação é o hábito que este desafio foi feito para quebrar.
- Parar nas claims que você reconhece.
iss,aud,sub,expsão todas comuns. A resposta está na claim que é um objeto. - Responder console.harbourline.example. É de onde veio a delegação, não quem a executou.
Como se proteger
Registre as duas identidades e trate a autoridade delegada como um nível de privilégio próprio.
- Registre
act.subjunto comsubem todo evento de auditoria, e exiba isso na interface que as pessoas realmente leem. Se o campo estiver ausente no esquema de log, ele vai estar ausente na investigação. - Não deixe a delegação herdar o conjunto completo de permissões. Um agente de suporte agindo como um diretor deveria conseguir ler e reproduzir, não aprovar um pagamento.
- Limite valor e escopo em sessões delegadas, exija o consentimento do sujeito a cada sessão, e as expire em minutos.
- Alerte sobre sessões delegadas que executam ações privilegiadas fora do horário. Este reembolso teria disparado em ambas as condições.