CISOs e times de resposta a incidentes em nuvem precisam revisar urgentemente seus playbooks para lidar com janelas de consistência eventual no AWS IAM, que podem ser exploradas para manter a persistência mesmo após a “revogação” de chaves.
Uma técnica de persistência no AWS IAM
O AWS IAM adota um modelo de consistência eventual: alterações em chaves de acesso, políticas, funções e perfis de login levam em média 3–4 segundos para se propagar entre regiões e réplicas, como us-east-1 e eu-central-1. Nos testes da OFENSAI, durante esse intervalo, as chaves marcadas como excluídas ainda são aceitas para chamadas de API, permitindo que um invasor execute ações adicionais antes que o bloqueio se torne eficaz.
Em um cenário simulado, o defensor executa aws iam delete-access-key para o usuário comprometido, enquanto o atacante, usando a mesma chave, chama rapidamente aws iam create-access-key para o mesmo usuário, conseguindo criar novas credenciais dentro da janela de atraso. O mesmo raciocínio se aplica aos anexos de política, exclusão de funções e perfis de login, ampliando o risco para todo o fluxo de resposta a incidentes baseados apenas em “revogar e deletar”.
Por que os playbooks tradicionais falham
Playbooks que recomendam fixação de uma política de deny-all (como AWSDenyAll ou AWSCompromisedKeyQuarantine) sofrem do mesmo problema: a política leva alguns segundos para surtir efeito, tempo em que o atacante pode detectar a mudança via chamadas como ListAccessKeys e removê-la. O próprio “Credential Cleanup Procedure” da AWS, publicado no re:Post, orienta esperar a implementação completa antes da obrigação, mas isso é ineficaz contra oponentes que atuam proativamente nesse intervalo.
Após a divulgação, a AWS aplicou correções parciais: hoje uma chave excluída bloqueia imediatamente a criação de uma nova chave para o mesmo usuário, mitigando um vetor específico. No entanto, retestes demonstraram que os aventureiros ainda conseguem, a partir do contexto existente, detectar as mudanças e criar/usar funções assumíveis com AdministratorAccess a partir de contas externas, mantendo o acesso mesmo depois da “limpeza” inicial.
Recomendações da OFFENSAI e da AWS
- Usar SCPs em nível de conta para contenção: aplicar Políticas de Controle de Serviço via Organizações AWS negando todas as ações para o principal comprometido (usuário/função), já que o atacante não controla SCPs. Depois da propagação do SCP, execute a limpeza de chaves, funções e políticas com risco muito menor de corrida.
- Favorecer funções e credenciais temporárias (STS): reduza o uso de chaves de longo prazo para que qualquer comprometimento seja limitado no tempo e menos sensível a nuances de consistência eventuais.
- Ajustar monitoramento e IR: incorporar atrasos de propagação nas regras de detecção (observando atividade suspeita logo após ações administrativas de bloqueio) e reescrever runbooks para que a contenção comece por mecanismos que o atacante não pode alterar, como SCPs em nível de organização.
A AWS descobriu as descobertas em abril de 2025, aplicando mudanças de melhorias e documentação, mas sem classificar o comportamento como vulnerabilidade, reforçando que se trata de uma característica de sistemas distribuídos que precisa ser considerada explicitamente no design de segurança e nos processos de resposta.
