Como encontrar o ID da conta AWS de qualquer bucket S3

Artigo original ↗ Discussão no Hacker News ↗

Uma nova técnica mostra como inferir o ID da conta AWS que possui qualquer bucket S3 ao abusar da correspondência de condições do IAM, levantando questões sobre quais metadados antes implícitos agora podem ser mapeados e correlacionados. Os comentaristas concordam amplamente que os IDs de conta AWS não foram feitos para ser segredos — a AWS diz isso explicitamente —, mas divergem sobre se tratá-los como “sensíveis” por segurança operacional ou riscos de correlação ainda tem valor. Muitos veem isso como um lembrete de que a segurança não deve depender de identificadores ocultos ou obscuridade, e de que as verdadeiras ameaças a tratar são políticas entre contas mal configuradas e vazamento de metadados.

Escopo da Descoberta

  • A técnica usa políticas de bucket S3 e condições s3:ResourceAccount com curingas para inferir qual conta AWS é proprietária de um determinado bucket.
  • Muitos veem isso como um side channel interessante, e não como uma quebra direta: ainda são necessárias más configurações ou informações adicionais para obter acesso.

Os IDs de Conta AWS são Secretos ou Sensíveis?

  • A documentação da AWS diz explicitamente que IDs de conta não são secretos, sensíveis nem confidenciais.
  • Um lado: IDs de conta devem ser tratados como públicos; projetar sistemas que dependem de seu sigilo é má segurança e uma “suposição falsa”.
  • Outro lado: não são “secretos”, mas ainda são “sensíveis”; vazá-los adiciona valor para atacantes e deve ser minimizado quando viável.

Segurança Operacional e Vazamento de Metadados

  • A principal preocupação não são os IDs em si, mas as relações:
    • Correlacionar vários buckets ao mesmo proprietário (por exemplo, marcas diferentes, clientes, projetos internos).
    • Ligar buckets “ocultos” ou de staging a uma conta de produção conhecida.
    • Casos de uso de inteligência de negócios / espionagem (por exemplo, aprender sobre projetos a partir de nomes de buckets).
  • Alguns dizem que isso é opsec, não segurança; outros argumentam que opsec ainda é legitimamente importante.

Debate sobre Segurança por Obscuridade

  • Vários afirmam que a obscuridade é, no melhor caso, uma camada fraca e não rotacionável, e nunca deve ser tratada como controle.
  • Outros respondem que informações “não públicas, mas não secretas” são uma preocupação válida de opsec e não implicam que você as esteja usando como mecanismo de controle de acesso.
  • Ponto de consenso: não projete IAM ou modelos de ameaça que assumam que o ID da conta permanecerá oculto.

Wildcards no IAM e Design de Políticas

  • Muitos se surpreendem que o IAM permita correspondência com curinga (StringLike) em IDs de conta; vários não veem caso de uso legítimo para controle de acesso.
  • Explicações apresentadas:
    • Linguagem de políticas genérica e pouco tipada, que aplica operadores de string em tudo por simplicidade.
    • Usos possíveis, mas duvidosos (agrupar muitas contas por prefixo, sharding, redução do tamanho da política).

Vetor de Enumeração Relacionado e Ferramentas

  • IDs de chaves de acesso da AWS embutem o ID da conta e aparecem em URLs pré-assinadas, então muitos IDs provavelmente já estavam vazando.
  • Outros espaços de nomes globais (por exemplo, fornecedores de AMI, outros recursos públicos) expõem IDs de conta naturalmente.
  • AWS Config com agregação em toda a organização e Athena é destacado como a forma “certa” de localizar internamente qual conta possui qual recurso, embora não seja gratuito.