Como a nuvem de uma startup foi dominada por um simples formulário que envia e-mails

Prevenir a tomada total da nuvem através de 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 segredos internos de API, tudo através de um simples formulário que envia um e-mail. Apesar de ser uma história verídica, estou a manter o nome da startup em segredo.

Como entraram

Tudo começa com uma aplicação PHP a enviar uma mensagem de correio eletrónico. Para carregar algumas das imagens de fantasia para o e-mail como anexos, a aplicação precisa de as descarregar. Em PHP, isto é fácil. Utiliza-se a função file_get_contents e é aí que começa a diversão.

É claro que algumas das entradas do utilizador para esta mensagem de correio eletrónico não foram totalmente verificadas ou codificadas em HTML, pelo que um utilizador poderia incluir uma imagem como <img src=’evil.com’/>. Agora, em teoria, isto não é assim tão mau, mas infelizmente esta função do PHP é muito poderosa e pode fazer muito mais do que carregar imagens através da Internet. Também pode ler ficheiros locais e, mais importante ainda: ficheiros através da rede local em vez da Internet.

Em vez de evil.com, o atacante inseriu um URL local especial. Pode utilizar este URL para obter as credenciais IAM associadas à função do servidor AWS EC2 que está a executar com um simples pedido 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 do servidor EC2 num anexo da caixa de correio. Essas chaves dão ao atacante a capacidade de se fazer passar por esse servidor ao falar com vários serviços AWS. A partir daí, tudo vai por água abaixo...

Porque é que isto é possível?

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 solicitação PUT com um cabeçalho especial para obter suas credenciais de IAM. Isso significa que uma simples função de carregamento de URL baseada em GET, como file_get_contents, não pode mais causar tantos danos.

Não é claro qual será a adoção do IMDSv2 a partir de 2023, mas é evidente que a Amazon ainda está a tomar medidas para aumentar a sua adoção e estamos a ver que o IMDSv1 ainda está a ser utilizado na natureza.

O comprometimento das chaves IAM leva a outros comprometimentos: Os buckets S3 podiam ser listados e o seu conteúdo lido. Para piorar a situação, um dos buckets S3 continha um modelo de cloudformation, que continha variáveis de ambiente sensíveis (por exemplo, chaves da API Sendgrid).

Como é que defendo a minha infraestrutura de nuvem contra isto?

Agora, o que poderia ser feito para evitar essa perda total de dados? Os seus programadores poderiam ser extremamente cuidadosos e ter o cuidado de utilizar uma lista de permissões para os URLs que passam para file_get_contents. Podem até verificar se o conteúdo que recebem é uma imagem, se estiverem à espera de uma imagem. No entanto, a realidade é que este tipo de erros é difícil de evitar enquanto programador.

Seria muito melhor garantir que a sua infraestrutura tem defesas adicionais contra estes ataques. A nossa nova integração com a AWS dentro da segurança Aikido irá alertá-lo se a sua nuvem não tomar ativamente nenhuma das seguintes medidas. Cada uma destas medidas, por si só, teria impedido este ataque específico, mas recomendamos a implementação de todas elas. Utilize a nossa conta de avaliação gratuita para ver se a sua nuvem já está protegida contra estas ameaças. Veja como o Aikdido protege a sua aplicação contra vulnerabilidades aqui.

Medidas a adotar:

1. Migrar os nós EC2 IMDSv1 existentes para utilizar o IMDSv2
2. Não armazene nenhum segredo no ambiente dos seus servidores Web ou em modelos de formação de nuvem. Use uma ferramenta como o AWS Secrets Manager para carregar os segredos em tempo de execução.
3. Ao atribuir funções de IAM aos seus servidores EC2, certifique-se de que têm condições adicionais, como restringi-las a serem utilizadas apenas a partir da sua rede AWS local (a sua VPC). O exemplo abaixo permite que o seu servidor leia do S3, mas apenas se o servidor EC2 estiver a comunicar através de um ponto de extremidade VPC específico. Isto só é possível a partir da sua rede, pelo que o atacante não teria sido capaz de aceder aos buckets S3 a partir da 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 atacantes que chegam às jóias da coroa de empresas de software encadeando várias vulnerabilidades. Escrito por Willem Delbare, aproveitando os seus dez anos de experiência na construção e apoio a startups SaaS como CTO. As histórias vêm diretamente da rede de Willem e todas elas aconteceram realmente.