Análise técnica da violação causada por uma configuração incorreta na nuvem da Capital One

ATUALIZAÇÃO: 26 de agosto de 2019

Desde a publicação deste artigo, a AWS fez algumas declarações públicas sobre a violação que ajudam a esclarecer o que provavelmente aconteceu. Em sua resposta ao senador Ron Wyden, a AWS declarou:

"Conforme a Capital One explicou em seu anúncio público, o ataque ocorreu devido a um erro de configuração na camada de aplicação de um firewall instalado pela Capital One, agravado por permissões definidas pela empresa que provavelmente eram mais abrangentes do que o previsto. Depois de obter acesso por meio do firewall configurado incorretamente e contar com permissões mais amplas para acessar recursos, acreditamos que foi usado um ataque SSRF (uma das várias formas pelas quais um invasor poderia ter obtido acesso a dados depois de entrar pelo firewall configurado incorretamente)."

"Como discutimos acima, o SSRF não foi o principal fator do ataque. Não temos conhecimento de outros comprometimentos relevantes de clientes da AWS por SSRF."

Muito se falou sobre o provável uso de SSRF na violação, mas, como a AWS deixa claro, esse não foi o principal fator do ataque. O problema foi a configuração excessivamente permissiva dos recursos na nuvem. Esta publicação descreve em detalhes algumas formas como esses recursos podem ter sido configurados incorretamente e como essas falhas podem ter sido exploradas.

PUBLICAÇÃO ORIGINAL: 1º de agosto de 2019

Esta é uma análise técnica de como a violação da Capital One pode ter ocorrido, com base nas evidências da denúncia criminal. Quero começar dizendo que tenho grande respeito pela equipe de nuvem da Capital One e amigos que fazem parte dela. A equipe é referência em computação em nuvem, e o que aconteceu poderia ter ocorrido com quase qualquer organização. Também não estou criticando a Amazon Web Services (AWS), meu antigo empregador. A AWS oferece serviços seguros, e tenho apenas respeito por ela. O objetivo desta publicação é explorar uma combinação de ataques a firewall, IAM e S3 para ilustrar alguns dos perigos das configurações incorretas na nuvem que todas as organizações que usam a nuvem devem levar em conta.

Para escrever este artigo, analisei os detalhes técnicos da denúncia do FBI e, em seguida, formulei uma hipótese sobre como o ataque pode ter ocorrido. Depois, simulei o ataque na minha conta de desenvolvimento para incluir detalhes específicos nesta publicação.

Os fatos que conhecemos

Temos poucas informações sobre o ataque, obtidas na denúncia do FBI e em publicações da suposta invasora nas redes sociais. Ao que tudo indica, ela usou Tor e IPredator em conjunto para ocultar sua identidade e, por meio desses serviços, descobriu um firewall configurado incorretamente no ambiente AWS da Capital One. Não está claro se o ataque foi direcionado à Capital One ou se foi oportunista, após a descoberta da falha de configuração.

Muitos artigos já abordaram as possíveis motivações e a biografia da invasora, então vou deixar esses assuntos de lado e me concentrar nos aspectos técnicos. Sabemos que o ataque envolveu quatro elementos:

• Firewall configurado incorretamente

• Acesso a uma instância do EC2

• Acesso ao S3 por meio de uma função do IAM

• Descoberta e cópia de buckets do S3.

Cada um desses elementos é explorado em detalhes a seguir.

Como o ataque pode ter acontecido

Temos alguns detalhes, mas não muitos. Por isso, precisei recorrer a bastante especulação e interpretação dos fatos disponíveis. Vou indicar claramente quando estiver especulando ao percorrer as etapas do ataque a seguir. O diagrama abaixo mostra meu ambiente de teste, no qual simulei alguns aspectos da violação da Capital One.

O ambiente inclui:

1. uma rede VPC básica

2. um grupo de segurança que permite HTTP(S) e SSH

3. um bucket privado do S3

4. duas funções do IAM: uma com acesso ao S3 e outra sem

5. uma instância do EC2 com endereço IP público e a função do IAM sem acesso ao S3

Meu objetivo era sair do acesso ao shell da instância do EC2 e chegar à possibilidade de acessar e copiar os dados do S3 nos buckets privados.

Antes de detalhar as etapas, vale observar que o FBI conseguiu acesso por meio de uma denúncia sobre um arquivo hospedado no GitHub. O arquivo continha o endereço IP de um servidor e três comandos:

"A Capital One determinou que o arquivo de 21 de abril continha código para três comandos, além de uma lista com mais de 700 pastas ou buckets de dados." Vamos detalhar cada um desses comandos, o que eles podem ter sido e a possível estratégia usada pela invasora.

Etapa um: firewall configurado incorretamente

Segundo a denúncia do FBI, "Uma configuração incorreta do firewall permitiu que comandos chegassem ao servidor e fossem executados por ele, possibilitando o acesso a pastas ou buckets... (III.A.10)"

Isso sugere que o firewall era externo ao servidor, e não local, embora isso não seja afirmado explicitamente. Há muitos appliances virtuais de firewall disponíveis na AWS, mas, em geral, seria um grupo de segurança. Parece que uma porta perigosa ficou aberta no tipo de firewall usado, o que pode ter sido o ponto de entrada inicial do ataque. É possível que uma porta SSH tenha sido aberta para uma janela de manutenção, ou talvez o servidor tivesse sobrado de um projeto de desenvolvimento e já não estivesse em uso. Outra possibilidade é que o servidor executasse um aplicativo como MongoDB ou ElasticSearch, que exige uma porta aberta para funcionar, mas que nunca deveria ter sido exposto à Internet pelo firewall. Seja qual for o cenário, a invasora encontrou um caminho para entrar na infraestrutura de computação em nuvem da Capital One.

Etapa dois: acesso a uma instância do EC2

Com base na descrição da entidade comprometida como um “servidor” na denúncia do FBI e no fato de que a invasora conseguiu extrair credenciais do IAM dele, parece que uma instância do EC2 foi comprometida. Pode ter sido uma vulnerabilidade no aplicativo ou no sistema operacional — simplesmente não sabemos. Para simular o ataque, presumi que a invasora obteve acesso ao shell, mas não acesso root à instância, já que todas as etapas restantes podem ser concluídas com acesso básico ao shell.

Etapa três: acesso ao S3 por meio de uma função do IAM

..."A Capital One determinou que o primeiro comando, quando executado, obteve as credenciais de segurança de uma conta chamada ***-WAF-Role que, por sua vez, permitia o acesso a determinadas pastas da Capital One na empresa de computação em nuvem. (III.A.11)"

Grande parte da “ação” nessa violação envolveu o acesso a buckets privados do S3 por meio de funções do IAM, aparentemente usando comandos da AWS CLI no servidor comprometido. A imprensa deu bastante destaque ao nome da função, mas não há evidências concretas de que o servidor em si fosse um WAF. É comum “emprestar” funções do IAM em ambientes AWS dinâmicos (não é uma prática recomendável, mas é comum). Além disso, como veremos a seguir, as associações de políticas podem ser alteradas e muitas vezes têm “Role” no nome, como no exemplo abaixo. Talvez esse servidor fosse apenas um recurso esquecido, sem tags para aparecer nos painéis das ferramentas de gerenciamento. Raramente encontrei uma conta AWS de grande porte sem recursos órfãos espalhados por algum lugar.

Se o servidor fosse um WAF e tivesse acesso intencional de leitura e gravação a buckets e objetos que contivessem dados pessoais identificáveis (PII), essa seria uma estratégia de defesa ingênua, por motivos óbvios — sobretudo porque uma única configuração incorreta do firewall permitiria contornar todas as defesas arquitetônicas dos dados confidenciais. Mas essa não é a única explicação para a violação. Suspeito que houve mais fatores envolvidos, com o uso de recursos do IAM e do EC2 projetados para oferecer flexibilidade, mas que podem ter sido usados indevidamente para conceder privilégios adicionais.

Como a denúncia menciona o “primeiro comando”, acho razoável supor que se tratava de um script da AWS CLI. Se a instância do EC2 já tivesse acesso ao S3, a invasora precisaria executar algo como:

> curl http://169.254.169.254/latest/meta-data/iam/security-credentials/DemonstrationEC2Role

Esse comando recupera as credenciais temporárias atuais do IAM da função, usando os metadados da instância do EC2. A saída é semelhante a esta:

{

  "Code" : "Success",

  "LastUpdated" : "2019-07-31T19:41:16Z",

  "Type" : "AWS-HMAC",

  "AccessKeyId" : "***************",

  "SecretAccessKey" : "**************************",

  "Token" : "AgoJb3JpZ2luX2VjEDQaCXVzLWVhc3QtMiJGMEQCIG9qFNkzROR8KaLKTTxaWYpxuE1J8ogMUWLF6EhddivjAiB84nwhPoUQl4IIWb5oGfXjc3QzRTP7nm/fG8ANqGnrJyrjAwit//////////Hpraage6UuR7XmrrdM09c9thue+fbUjYYGFHtiun96KrcDeZrJXwV/Dj8+pbn2Ivw0UydaC7Jj+XUkr8izWG7h/Hpraage6UuR7XmrrdM09c9thue++IaAjZPsutjIhkDEuggqriQCdA/4QwHgXFAjs0VzgFly9l29EVWMzvIncKQEIGFxofqwhMcOpN4uP7wseMctpqVfUfjumC/EisdYFUo8UaDctYObXBCk8tL/HvvMmJrF0aDYmcsaQ8Geu67X9LQk45xr/Hpraage6UuR7XmrrdM09c9thue+qy0evQBJbqmfrhg1bZktctodqOkngdyFN/CYDu3jVIyiLxH/3PmGedzkjJ+julYzunhj9i8V5ej4UIyGDU2KOORaRosLM+lFDJSZDfiihWvfXYYDDJkLX+tJel9qFYTqDcppVTcIjJO8yJQOYRBAvk32nu1mdkQMmafl+CwxMfppbsrja9c6A/c16tv/WcPrCzmJiu6yqbk+4QwHgXFAjs0VzgFly9l29EVWMzvIncKQEIGFxofqwhMcOpN4uP7wseMctpqVfUfjumC+Hpraage6UuR7XmrrdM09c9thue/9ZmdktOg6HAtI89GOP10OE2gJ0Pq4Er/+hUh/+LOmi3QSoALCitT2d09o/iCcXY/zzCT3ofqBTq1AQ5XbIYPbAZiKVyquo2M6EYqiODBNsSQLiMBJgZldv8LOhYOgIxz302gTBvSr7zl2vWrm5gEr9twKx1ApMkaMY0h1kNTgwTsBHm9hVdvidN3QhBzt3s7u2nvcGx5r+dWDkTQ3BI6fD31tdDKOtm7fZO9ziSgFu8U3o3ncAytioWYGXXtZN2FLzBtqp+mq6E8gc1lZnoCGkGApXltdJVSC2+tkXQJLYyF1Ubd00GH+QV8cxE/zr4=",

  "Expiration" : "2019-08-01T02:17:11Z"

}

Where the access key and secret access key are replaced with *'s and the token corrupted to protect the innocent.

Isso seria tudo de que ela precisaria para acessar os buckets do S3 e seu conteúdo.

Mas há outra possibilidade para o que esse “primeiro comando” fez, e todos que usam AWS precisam conhecê-la. Se o servidor comprometido não tivesse acesso aos buckets privados do S3, mas pudesse listar e associar políticas do IAM, a invasora poderia ter usado esses recursos para, na prática, procurar credenciais que permitissem esse acesso. Como as permissões do IAM muitas vezes não têm relação com os controles de acesso à rede no nível de IP, e os serviços da AWS se conectam por meio do IAM, essas funções e políticas formam uma espécie de rede alternativa, que precisa ser protegida como uma rede tradicional. O IAM se torna um dos principais meios de “movimentação lateral” no ambiente de nuvem.

Por exemplo, o comando abaixo substitui um conjunto de permissões do IAM por outro:

> aws ec2 replace-iam-instance-profile-association --association-id iip-assoc-00facaf2870f3bcc9 --iam-instance-profile Name=DemonstrationEC2Role

e retorna o resultado a seguir, mostrando que substituí com sucesso as permissões do IAM existentes pelas definidas na política DemonstrationEC2Role:

{

    "IamInstanceProfileAssociation": {

        "InstanceId": "i-0f566edb3389ac1f7",

        "State": "associated",

        "AssociationId": "iip-assoc-00facaf2870f3bcc9",

        "IamInstanceProfile": {

            "Id": "AIPA6MYZKKFJL2Y2G5UPO",

            "Arn": "arn:aws:iam::989506195794:instance-profile/DemonstrationEC2Role"

        }

    }

}

Outros comandos úteis para esse tipo de busca incluem:

> aws iam list-roles

> aws iam list-policies

> aws iam list-instance-profiles

Eles fazem exatamente o que o nome indica: listam os recursos do IAM disponíveis que uma invasora poderia querer usar depois de obter acesso ao shell de uma instância do EC2.

Neste exemplo, substituí um perfil limitado do IAM por outro com permissões adicionais para o S3. Não podemos descartar que a invasora tenha usado uma abordagem semelhante na violação da Capital One. Tenha sido esse o caso ou não, é fundamental levar esse recurso em conta ao configurar funções do IAM para suas instâncias do EC2, especialmente as voltadas à Internet: as permissões do IAM podem efetivamente “alcançar” recursos privados do seu ambiente.

Em qualquer um dos cenários, a invasora obteve as credenciais necessárias para recuperar informações do S3 e copiá-las.

Etapa quatro: descoberta e cópia de buckets do S3

"A Capital One determinou que o terceiro comando (o “comando Sync”), quando executado, usou a função ***-WAF-Role para extrair ou copiar dados das pastas ou dos buckets do armazenamento da Capital One para os quais essa conta tinha as permissões necessárias. (III.A.11)"

Isso sugere o uso do comando `aws s3 sync` da AWS CLI e reforça a hipótese de que a invasora obteve acesso ao shell da instância do EC2 e usou a AWS CLI para executar esses comandos. Segundo a denúncia do Departamento de Justiça, ela listou os buckets do S3 com o segundo comando, o que sugere que a função do IAM usada tinha permissões de listagem e de leitura no S3. Isso evidencia o perigo de uma única função do IAM ter permissões tão amplas no S3: mesmo nesse ponto, sem conseguir descobrir os buckets de destino, a invasora provavelmente não teria conseguido capturar muitos dados — ou nenhum.

Recomendações

1. Monitore continuamente grupos de segurança com permissões excessivas e qualquer outro mecanismo de acesso aberto a 0.0.0.0/0. Verificar os recursos no momento da criação é necessário, mas está longe de ser suficiente. A infraestrutura de nuvem é criada e modificada por meio de APIs, o que significa que ela costuma se desviar da configuração esperada ao longo do tempo, conforme diferentes equipes e pessoas interagem com ela.

2. Aplique o princípio do menor privilégio e limite rigorosamente as funções do IAM ao mínimo necessário para a função de negócio do recurso que as utiliza. No caso do S3, você pode considerar endpoints públicos distintos para operações de leitura e gravação, com funções do IAM separadas que não possam executar a outra operação. Elimine todos os casos de uso em produção que permitam listar buckets do S3 e prefira segredos compartilhados ou outros mecanismos.

3. Não permita que instâncias do EC2 tenham funções do IAM que autorizem associar ou substituir políticas de funções em ambientes de produção.

4. Remova rigorosamente os recursos de nuvem sem uso — especialmente servidores e buckets do S3 — que tenham sobrado de atividades anteriores de desenvolvimento ou depuração em produção.

5. Inclua a busca por configurações incorretas na infraestrutura em nuvem nos seus testes de penetração. Contrate profissionais externos para esses testes e certifique-se de que eles saibam identificar e explorar configurações incorretas na nuvem.