Como encontrar o ID da conta AWS de qualquer bucket S3

Encontrando o ID da conta AWS de um bucket S3

• Em 2021, Ben Bridts apresentou um método engenhoso para descobrir o ID da conta AWS de um bucket S3 público.
• Este artigo explica técnicas para encontrar o ID da conta tanto de buckets S3 privados quanto públicos.

De um bucket S3 para um ID de conta AWS

• Mostra uma técnica, por meio da saída do shell, para descobrir o ID da conta AWS antes desconhecido de um bucket chamado bucket-alpha.

Como essa técnica funciona exatamente?

• Analisa por que a técnica de Ben funciona, combinando três elementos principais:
  • a capacidade de aplicar políticas IAM a uma solicitação
  • a capacidade de inferir se a política IAM permitiu a solicitação ou não
  • a capacidade de aplicar correspondência com wildcard à chave de condição s3:ResourceAccount

A solução

• Foi encontrada uma solução que usa um endpoint VPC para S3 e explora a diferença de comportamento quando solicitações são negadas no CloudTrail.

Passo a passo

• Procedimento passo a passo ao tentar encontrar o ID da conta do bucket bucket-alpha:
  • determinar a região do bucket
  • implantar uma VPC e um endpoint VPC na mesma região
  • iniciar uma instância EC2 dentro da VPC e confirmar o uso do endpoint VPC para S3
  • modificar a política do endpoint VPC para determinar se o ID da conta do bucket de destino começa com "0"
  • fazer uma solicitação ao bucket de destino
  • verificar se a solicitação aparece no CloudTrail
  • com base no resultado, modificar a política do endpoint VPC para descobrir mais informações sobre o ID da conta

Resultados

• Foi criado um script para automatizar esse processo, permitindo encontrar com confiabilidade o ID da conta do bucket.
• É feita uma busca binária para cada dígito, reduzindo o número de testes necessários.

Acelerando o processo

• A política do endpoint VPC foi modificada para reduzir o tempo necessário para ela surtir efeito e para esperar individualmente pelos resultados no CloudTrail.
• Isso reduziu o tempo necessário para encontrar o ID da conta para menos de 10 minutos.

Opinião

• Esta postagem no blog foi publicada após consulta à equipe de segurança da AWS.
• Houve uma discussão interessante sobre se o ID da conta AWS deve ser considerado informação sensível.
• Essa técnica pode ser aplicada a outros serviços além do S3.
• Essas técnicas são possíveis porque é permitido usar a condição StringLike em s3:ResourceAccount.
• Pode ser útil que eventos negados por políticas de endpoint VPC sejam registrados no CloudTrail.

Agradecimentos

• A técnica original de Ben Bridt inspirou este trabalho.
• Agradecimentos a Chris Farris por sua ajuda e conselhos.

Opinião do GN⁺

• Essa técnica pode ser muito útil para realizar auditorias de segurança em ambientes de nuvem, especialmente para verificar a propriedade de buckets AWS S3.
• A discussão sobre a sensibilidade das informações fornecidas por essa técnica reflete o diálogo contínuo entre provedores de serviços em nuvem e usuários sobre segurança de dados e privacidade.
• Outra ferramenta com funcionalidade semelhante é o próprio serviço CloudTrail da AWS, usado para registrar e monitorar toda a atividade no ambiente AWS do usuário.
• Antes de adotar essa técnica, o usuário deve verificar se ela está alinhada com as políticas da AWS e com as melhores práticas de segurança.
• Os benefícios obtidos com o uso dessa técnica incluem auditoria de segurança eficiente e verificação rápida de propriedade de dados, mas também devem ser considerados riscos como possível exposição de informações pessoais.

[GN⁺]

Comentários do Hacker News

• A capacidade de aplicar correspondência com curingas à chave de condição s3:ResourceAccount da AWS

  • O surpreendente nessa funcionalidade é que não há um motivo legítimo para conceder ou negar permissões com base em correspondência parcial de ID de conta. IDs de conta da AWS podem ser sensíveis, como endereços IP, mas alguém precisa conhecê-los para que o trabalho aconteça.

• ID da conta AWS == seu endereço IP. Pode ser sensível, mas alguém precisa conhecê-lo para fazer as coisas acontecerem.

  • Exemplo: por causa de procedimentos antilavagem de dinheiro, o autor queria uma configuração de PrivateLink, geralmente mais segura do que uma porta SFTP aberta, em uma transação com um terceiro com o qual precisava se integrar. Mas a empresa recusou por razões de segurança, para ocultar o ID da conta. Como resultado, a equipe do autor colocou a faixa de IPs públicos usada por eles na whitelist da porta 22.
  • Moral da história: esconder o ID pode parecer inteligente, mas se não houver um endereço pelo qual as pessoas possam entrar em contato com você, você não consegue realmente operar um negócio.

• Em geral, eu não distribuiria um ID de conta publicamente, mas em algum momento é preciso esperar que parte dele se torne pública.

  • À medida que fornecedores terceirizados e plataformas SaaS migram para integrações que preferem role assumption em vez de usuários IAM e chaves de acesso, o ID da conta usada como ponto de integração será conhecido pela outra parte, e ela tem suas próprias dependências e vulnerabilidades.

• Outros recursos públicos da AWS com namespace global também expõem o ID da conta AWS.

  • Para quem tiver interesse, publiquei esse código online aqui: find-s3-account

• Relacionado: o ID da chave da AWS (não a parte da chave secreta) contém o ID da conta, deslocado em um bit.

  • Esse ID de chave está incluído na URL de links pré-assinados para S3, então é bem possível que você já esteja expondo o ID da conta.

• Descoberta interessante, mas ao ver o título eu esperava que houvesse uma forma mais simples.

  • Seria bom se houvesse uma maneira simples de perguntar à AWS, a partir de uma conta administrativa, "onde está o recurso X". Em especial, seria útil uma função que dissesse rapidamente em qual conta está um determinado bucket S3. Isso é principalmente um problema com buckets legados que existiam antes de serem definidos em código. Quando se tem muitas contas AWS, procurar recursos em contas desconhecidas e possíveis regiões pode ser trabalhoso.

• É sempre legal quando um hack de verdade traz aquele clichê antigo ou mal-entendido de "hackear" uma senha "um caractere por vez".

• Um vetor de ataque mais preocupante agora é tentar usar o número da conta para adicionar entidades de outra conta à allowlist na política da sua própria conta.

  • Se essa entidade não existir na outra conta, ocorre um erro de função/usuário não encontrado. Isso pode ser usado para descobrir entidades reais de outra conta.

• Por que isso importa? Uma razão óbvia: dado um bucket de produção, isso pode permitir encontrar buckets de desenvolvimento da mesma organização, o que é um comportamento inesperado.