O bucketsquatting de S3 (finalmente) acabou

• A AWS introduziu um novo recurso de proteção de namespace baseado em conta para resolver o problema de S3 bucketsquatting
• O novo namespace segue o formato <prefix>-<accountid>-<region>-an, e somente a mesma conta pode criar um bucket com esse nome
• Se outra conta tentar usar o mesmo nome, ocorrerá o erro InvalidBucketNamespace; o mesmo erro também é retornado quando a região é especificada incorretamente
• O uso desse namespace é recomendado por padrão, e pode ser imposto por políticas da organização (SCP) com a chave de condição s3:x-amz-bucket-namespace
• Embora não seja aplicado retroativamente a buckets existentes, ele oferece proteção robusta para novos buckets e representa uma melhoria fundamental na arquitetura de segurança do S3

---

Visão geral do problema de bucketsquatting

• Bucketsquatting (ou Bucketsniping) é uma forma de ataque que explora o fato de que os nomes de bucket no AWS S3 são globalmente únicos
  • Quando um bucket é excluído, o nome volta a ficar disponível, permitindo que um invasor registre um novo bucket com o mesmo nome
  • Isso pode gerar risco de acesso a dados sensíveis ou interrupção de serviço
• As organizações costumavam usar regras de nomenclatura previsíveis, como myapp-us-east-1, o que aumentava a exposição ao ataque
• Equipes internas da própria AWS também foram afetadas por esse problema e, ao longo de cerca de 10 anos, buscaram uma solução em colaboração com a equipe de segurança da AWS

Introdução do novo namespace do S3

• Para resolver o problema, a AWS introduziu o conceito de namespace por conta (account namespace)
  • Formato: <prefix>-<accountid>-<region>-an
  • Exemplo: myapp-123456789012-us-west-2-an
• Esse namespace restringe a criação do bucket com esse nome apenas à conta correspondente
  • Se outra conta tentar criar o mesmo nome, ocorrerá o erro InvalidBucketNamespace
  • O mesmo erro também é retornado se a região no nome do bucket não corresponder à região real
• A AWS recomenda usar esse namespace por padrão em todos os novos buckets
  • Diferentemente de namespaces existentes como .mrap, --x-s3 e -s3alias, desta vez ele foi introduzido como um namespace de segurança para usuários em geral

Aplicação e gerenciamento de políticas

• Administradores de segurança podem usar a chave de condição s3:x-amz-bucket-namespace para impor o uso do namespace por meio de políticas organizacionais (SCP)
• Isso não é aplicado automaticamente a buckets existentes nem a templates sem namespace
  • Para proteger buckets existentes, é necessário criar buckets no novo formato de namespace e migrar os dados
• Com essa medida, o bucketsquatting está efetivamente “desaparecendo”, e os novos buckets passam a ter proteção completa

Abordagem de outros provedores de nuvem

• O Google Cloud Storage (GCS) já usa um namespace baseado na validação de nome de domínio
  • Buckets em formato de domínio, como myapp.com, só podem ser criados pelo proprietário do domínio
  • Em buckets que não seguem formato de domínio, ainda existe possibilidade de bucketsquatting
• O Azure Blob Storage usa a estrutura nome da conta de armazenamento + nome do contêiner
  • Como há um limite máximo de 24 caracteres, o namespace é mais restrito e pode ser mais vulnerável ao mesmo problema

Conclusão (tl;dr)

• O AWS S3 passou a ter um novo namespace de conta e região
• Esse namespace impede ataques de bucketsquatting e é fortemente recomendado ao criar novos buckets
• Buckets existentes não são protegidos automaticamente; portanto, se necessário, é preciso reforçar a proteção por meio de migração de dados

[GN⁺]

Opiniões no Hacker News

• Recentemente descobri que não é possível reutilizar o endereço de e-mail do usuário root mesmo depois de excluir uma conta AWS
  Alguém da nossa organização criou o usuário root de uma conta encerrada usando o e-mail principal da empresa, depois criou uma nova conta com outro e-mail, e agora até o período de recuperação da exclusão já passou
  Como resultado, aquele e-mail ficou permanentemente preso à conta root excluída, o que tornou impossível fazer login por SSO via um IdP externo
  Entrei em contato com o suporte da AWS, mas quase não obtive ajuda

  • Enquanto ajudava o suporte ao cliente recentemente, passei por um caso em que, após a saída de um engenheiro principal, o MFA da conta root continuou vinculado ao celular dele
    A senha estava documentada, mas não havia como desativar o MFA, então tentamos AWS Support, gerente de conta e outros contatos, sem sucesso
    No fim, o acesso à conta root ficou bloqueado, e talvez seja preciso migrar um ambiente complexo inteiro para uma nova conta
  • Se o provedor de e-mail oferecer suporte, dá para usar plus addressing
    A AWS trata e-mails com + como endereços distintos
  • A conta root não deve ser usada por pessoas; ela deve ser uma conta especial de emergência, com as credenciais guardadas em segurança
    O ideal é usá-la apenas quando surgir um problema realmente grave
  • Isso faz perceber de novo como segurança pode ser frágil
    No fim das contas, basta algum golpista enganar o suporte ao cliente e conseguir uma avaliação 10/10 para tudo ruir
  • Se o sistema mapeia o e-mail do IdP para uma role, fico curioso sobre o que significa exatamente “ficou permanentemente preso à conta root excluída”
    Gostaria de entender qual mecanismo realmente impede o uso

• Parece que o autor entendeu errado o conceito de account name no Azure Blob Storage
  Na prática, ele está no mesmo nível do nome de bucket do S3, precisa ser globalmente único e continua sendo uma grande inconveniência
  É ainda mais frustrante por causa do limite de 24 caracteres
  Seria bom se a Microsoft também adotasse um namespace por cliente, como a AWS

  • Cerca de 10 anos atrás, o time do S3 já sabia desse problema
    Mas, por restrições do design inicial, não conseguiu mudar
    Pessoalmente, não entendo por que ainda não criaram uma API S3 v2
    Poderiam ter induzido uma migração gradual para a nova API, mas no fim tanto clientes quanto engenheiros vêm sofrendo desnecessariamente
  • Quando usei Azure pela primeira vez, achei um design realmente estranho ver que os recursos não eram namespaced por conta
  • O próprio autor apareceu para dizer que atualizou o texto incorporando o feedback
  • A limitação não é só de 24 caracteres; hífens, underscores e pontos também não são permitidos,
    então só se pode usar números e letras minúsculas, o que é muito incômodo
    Seria bom se permitisse ao menos traços, como no S3 ou no GCS
  • Acho realmente um design péssimo não poder usar nem hífen em nomes de storage account
    O mesmo vale para outros recursos, como container registries

• Fico pensando se nomes de pacote, nomes de bucket e nomes de conta do GitHub não poderiam seguir um formato como o do Discord, tipo @nome-4dígitosaleatórios
  Isso democratizaria o espaço de nomes e impediria squatting e ataques por reutilização
  Quando uma conta fosse excluída, bastaria descartar o nome inteiro, o que seria bem limpo

  • Mas o Discord aboliu esse formato há 2 anos e migrou para nomes globalmente únicos
    O motivo é explicado no anúncio oficial:
    era inconveniente ter de lembrar 4 dígitos e ainda distinguir maiúsculas de minúsculas
  • Pessoalmente, acho que um sistema de UUID + petname seria melhor
    Especialmente em apps de chat, faz mais sentido usar um ID interno e deixar o usuário lidar só com apelidos
    No caso de buckets, como o nome legível por humanos é essencial, eu preferiria usar seu próprio domínio
  • Para buckets isso até vai, mas para evitar package hijacking um código de 4 dígitos não ajuda muito
    Na verdade, só aumenta o risco de erro de digitação
  • Seria ótimo se desse para usar em qualquer lugar um nome baseado em validação de domínio (@example.com)
  • Quando criei ferramentas internas, atribuí aos usuários IDs internos opacos e deixei o nome livre para mudar
    Em comunidades online, nomes repetidos são algo natural,
    então fico me perguntando por que insistem tanto em impor nomes globalmente únicos

• Agradecimentos ao Ian Mckay
  É uma boa mudança a AWS ter adotado oficialmente um namespace por conta e região
  Seria ainda melhor se ferramentas de IaC como o Terraform passassem a usar essa regra como padrão
  O Terraform já evita colisões acrescentando um sufixo de hash aleatório ao fim do nome do bucket
  O blog oficial da AWS também fala sobre isso

• É interessante o ataque de bucket squatting que acontece quando provedores de nuvem usam nomes de bucket previsíveis para espaços internos temporários
  Na AWS, por causa do hash, o ataque real era difícil, mas o GCP passou por esse tipo de problema até recentemente
  Apresentação relacionada: palestra sobre bucket squatting na AWS da DC32,
  vulnerabilidade no GCP: CVE-2026-1727

  • Essa apresentação foi realmente marcante
    No instante em que vi que os nomes dos buckets eram previsíveis, percebi o risco
    A combinação de bucket squatting + bucket público + problema de TOCTOU no CloudFormation
    poderia perfeitamente levar à implantação de recursos em outra conta
    Surpreende que o time de segurança da AWS não tenha percebido isso antes

• Nomes DNS também têm um problema parecido
  Se um domínio não for renovado, ele pode ser registrado de novo,
  e alguém pode configurar um registro MX para interceptar e-mails de redefinição de senha, por exemplo

  • Há casos em que ativos como blocos IPv4 legados são recuperados dessa forma

• Buckets da AWS ainda oferecem funcionalidades especiais apenas quando o nome coincide com o hostname
  Documentação relacionada: Virtual Hosting in S3

• Um nome não deve ser igual à coisa que ele designa
  Se o nome for reutilizado, ele passa a apontar para algo completamente diferente,
  e seu significado muda conforme o contexto
  Só pode ser considerado o mesmo quando você mesmo reatribui o nome

• Já me perguntei se expor o ID da conta representava risco de segurança

  • A AWS afirma oficialmente que o ID da conta não é uma informação secreta
    Segundo a documentação oficial,
    ele deve ser tratado com cuidado, mas não é considerado dado sensível
  • Na minha opinião, é como um endereço de e-mail: é um identificador, não um meio de autenticação
    Desde que não seja exposto em excesso, tudo bem
  • Em termos de higiene não é ideal, mas não dá para atacar só com o ID da conta
    Como um invasor pode usar * em regras IAM, no fim o que importa é como o lado defensor configura as políticas
  • Ao compartilhar uma URL assinada do S3, o Access Key ID fica incluído nela
    Se você decodificá-lo em base32, consegue extrair o Account ID
    Referência: texto com a análise

• O fato de o S3 usar apenas o nome do bucket como chave de acesso foi uma das decisões de design mais irritantes