Como a Cloud de uma startup foi comprometida por um formulário simples de envio de e-mails

Prevenindo a tomada total da Cloud via ataques SSRF

Esta é a história de um atacante que obteve acesso aos buckets Amazon S3 de uma startup, variáveis de ambiente e vários Secrets de API internos, tudo através de um formulário simples que envia um e-mail. Embora esta seja uma história real, estou mantendo o nome da startup em segredo.

Como eles entraram

Tudo começa com um aplicativo PHP enviando um e-mail. Para carregar algumas das imagens sofisticadas no e-mail como anexos, o aplicativo precisa baixá-las. Em PHP, isso é fácil. Você usa a função file_get_contents e é aí que a diversão começa.

Claro, parte da entrada do usuário para este e-mail não foi totalmente verificada ou codificada em HTML, e assim um usuário poderia incluir uma imagem como <img src=’evil.com’/>.  Agora, em teoria, isso não é tão ruim, mas infelizmente esta função PHP é muito poderosa e pode fazer muito mais do que carregar imagens pela internet. Ela também pode ler arquivos locais e, mais importante: arquivos pela rede local em vez da Internet.

Em vez de evil.com, o atacante inseriu uma URL local especial.  Você pode usar esta URL para obter as credenciais IAM vinculadas à função do servidor AWS EC2 que você está executando com uma simples requisição GET.

<img src=’http://169.254.169.254/latest/meta-data/'>

O resultado foi que o atacante recebeu um e-mail que incluía as credenciais IAM para o servidor EC2 em um anexo na caixa de entrada. Essas chaves dão ao atacante a capacidade de se passar por esse servidor ao se comunicar com vários serviços AWS. A partir daí, tudo desanda...

Por que isso é possível, em primeiro lugar?

O sistema que carrega essas chaves IAM é chamado IMDSv1 e a Amazon lançou uma nova versão em 2019 chamada IMDSv2. Com o IMDSv2, você precisa enviar uma requisição PUT com um cabeçalho especial para obter suas credenciais IAM. Isso significa que uma função simples de carregamento de URL baseada em GET, como file_get_contents, não pode mais causar tanto dano.

Não está claro qual é a adoção do IMDSv2 em 2023, mas é evidente que a Amazon ainda está tomando medidas para aumentar sua adoção e estamos vendo o IMDSv1 ainda sendo usado em campo.

O comprometimento das chaves IAM leva a outros comprometimentos: os buckets S3 puderam ser listados e seus conteúdos lidos. Para piorar, um dos buckets S3 continha um template de CloudFormation, que continha variáveis de ambiente sensíveis (ex: chaves de API do Sendgrid).

Como defendo minha infraestrutura Cloud contra isso?

Agora, o que poderia ser feito para evitar essa perda total de dados? Seus desenvolvedores poderiam ser extremamente cuidadosos e se certificar de usar uma allowlist para as URLs que passam para file_get_contents. Eles poderiam até verificar se o conteúdo recebido é uma imagem, caso estejam esperando uma. A realidade, no entanto, é que esse tipo de erro é difícil de evitar para um desenvolvedor.

Seria muito melhor garantir que sua infraestrutura tenha defesas extras contra esses ataques. Nossa nova integração com a AWS dentro do Aikido Security irá alertá-lo se sua Cloud não tomar ativamente nenhuma das seguintes medidas. Cada uma dessas medidas, por si só, teria impedido este ataque específico, mas recomendamos implementar todas elas. Use nossa conta de teste gratuita para ver se sua Cloud já está defendida contra essas ameaças. Veja como o Aikido protege seu aplicativo contra vulnerabilidades aqui.

Passos a seguir:

1. Migre seus nós EC2 IMDSv1 existentes para usar IMDSv2
2. Não armazene Secrets de forma alguma no ambiente de seus servidores web ou em templates de CloudFormation. Use uma ferramenta como o AWS Secrets Manager para carregar os Secrets em tempo de execução.
3. Ao atribuir roles IAM aos seus servidores EC2, certifique-se de que eles tenham condições adicionais, como restringir seu uso apenas de dentro da sua rede AWS local (sua VPC). O exemplo abaixo permite que seu servidor leia do S3, mas somente se o servidor EC2 estiver se comunicando por meio de um endpoint VPC específico. Isso só é possível de dentro da sua rede, então o invasor não conseguiria acessar os buckets S3 de sua máquina local.

{
"Version": "2012-10-17",
"Statement": [
       {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
               }
           }
       }
   ]
}

Sobre “The Kill Chain”

The Kill Chain é uma série de histórias reais de invasores que alcançaram os "crown jewels" de empresas de software ao encadear múltiplas vulnerabilidades. Escrito por Willem Delbare, aproveitando seus dez anos de experiência na construção e suporte de startups SaaS como CTO. As histórias vêm diretamente da rede de Willem e todas realmente aconteceram.