0
0
Esta é uma exploração técnica de como a violação da Capital One pode ter ocorrido, com base nas evidências que temos da queixa criminal. Eu quero começar dizendo que eu respeito profundamente a equipe de nuvem da Capital One, e tenho amigos nela. Eles são líderes em computação em nuvem e o que aconteceu com eles poderia ter acontecido com praticamente qualquer pessoa. Também não estou criticando a Amazon Web Services (AWS) , meu empregador anterior. Eles oferecem serviços seguros e eu não tenho nada além de respeito por eles. O objetivo deste post é explorar uma combinação de ataque firewall / IAM / S3 para ilustrar alguns dos perigos das configurações incorretas da nuvem que toda organização na nuvem deve atender.
Para escrever isso, analisei os detalhes técnicos da queixa do FBI e, em seguida, formulei uma hipótese de como o ataque poderia ter ocorrido. Em seguida, simulei o ataque na minha conta de desenvolvimento, para poder fornecer detalhes específicos nesta postagem.
Os fatos como os conhecemos
Temos um punhado de informações sobre o ataque da denúncia do FBI e de postagens em mídias sociais do suposto agressor. Parece que o invasor usou Tor e IPredator em combinação para ofuscar sua identidade e, por meio desses serviços, descobriu um firewall mal configurado no ambiente do Capital One AWS. O que não está claro é se este foi um ataque direcionado ao Capital One, ou um ataque oportunista ao encontrar o erro de configuração.
Muitos artigos foram escritos sobre as possíveis motivações e biografia do atacante, então deixarei isso de lado para me concentrar nas especificidades técnicas. Havia quatro elementos diferentes para o ataque que conhecemos:
- Firewall mal configurado
- Obtendo acesso a uma instância do EC2
- Obtendo o acesso ao papel do IAM ao S3
- Descoberta e duplicação do bucket do S3.
Cada um dos itens acima é explorado em alguns detalhes abaixo.
Como o hack poderia ter acontecido
Temos alguns detalhes, mas na verdade não são muitos, e, portanto, empreguei uma quantidade razoável de especulação e interpretação dos fatos que temos. Vou dizer claramente quando estou especulando enquanto percorremos os passos do ataque abaixo. O diagrama abaixo mostra meu ambiente de sandbox, onde simulei alguns aspectos da violação do Capital One.
O ambiente contém:
- uma rede VPC básica
- um grupo de segurança que permite HTTP (S) e SSH
- um balde S3 privado
- dois papéis IAM – um com acesso S3 e um sem
- Uma Instância do EC2 com um endereço IP público, com a função do IAM que não tem acesso ao S3
Meu objetivo era ir do acesso ao shell da instância do EC2 à capacidade de acessar e copiar os dados do S3 nos buckets privados.
Antes de entrarmos em detalhes sobre as várias etapas, é importante ressaltar que o FBI obteve acesso por meio de uma dica para um arquivo hospedado pelo GitHub que continha o endereço IP de um servidor, junto com 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 baldes de dados.” Entramos em detalhes sobre cada um desses comandos e o que eles poderiam ter sido e a possível estratégia usada pelo invasor.
Etapa 1: firewall mal configurado
De acordo com a queixa do FBI, “Uma configuração incorreta do firewall permitia que os comandos alcançassem e fossem executados por esse servidor, o que permitia o acesso a pastas ou baldes … (III.A.10)”
Isso sugere que o firewall era externo ao servidor versus um firewall local, embora não seja explícito. Embora existam muitos dispositivos virtuais de firewall disponíveis na AWS, geralmente isso seria um grupo de segurança. Parece que uma porta perigosa foi deixada aberta em qualquer tipo de firewall em uso, e isso pode ter sido a abertura inicial do ataque. É possível que uma porta SSH tenha sido aberta para uma janela de manutenção, ou talvez o servidor em questão tenha sido deixado por esforços de desenvolvimento e não esteja mais em uso. Outra possibilidade é que o servidor estava executando um aplicativo como o MongoDB ou o ElasticSearch que requer uma porta aberta para funcionar, mas que nunca deveria ter sido exposto à Internet através do firewall. Quaisquer que sejam os detalhes, o invasor encontrou um caminho para a infraestrutura de computação em nuvem da CapitalOne.
Etapa 2: obter acesso a uma instância do EC2
Com base na descrição da entidade comprometida da denúncia do FBI como um “servidor” e que o invasor conseguiu extrair credenciais do IAM, parece que uma Instância do EC2 foi violada. Isso pode ter sido um aplicativo ou vulnerabilidade do sistema operacional – nós simplesmente não sabemos. Para o propósito de minha simulação do ataque, presumi que o atacante obteve acesso ao shell, mas não acesso root à instância, pois todas as etapas restantes requerem apenas acesso básico ao shell para serem concluídas com êxito.
Etapa três: acesso ao papel do IAM ao S3
… “A CapitalOne determinou que o primeiro comando, quando executado, obtinha as credenciais de segurança para uma conta conhecida como *** – WAF-Role que, por sua vez, permitia o acesso a certas pastas da Capital One na Cloud Computing Company. .A.11) “
Grande parte da “ação” nessa violação foi via acesso ao papel do IAM aos buckets privados do S3, aparentemente por meio dos comandos do AWS CLI do servidor comprometido. Muito já foi feito sobre o nome do papel na imprensa até o momento, mas não há evidências sólidas de que esse servidor fosse ele próprio um WAF. É comum “emprestar” papéis do IAM em ambientes dinâmicos da AWS (não é uma ótima prática, mas é uma prática comum), e também, como será mostrado abaixo, associações de políticas podem ser alteradas e geralmente têm “Papel” no nome , como mostrado no exemplo abaixo. Talvez esse servidor fosse algo deixado sem tags para trazê-lo em painéis de ferramentas de gerenciamento. Eu raramente vi uma conta considerável da AWS sem recursos órfãos em torno de um lugar ou outro.
Se o próprio servidor fosse um WAF e intencionalmente tivesse acesso de leitura / gravação a buckets e objetos nesses buckets contendo dados PII, essa era uma estratégia de defesa ingênua por razões óbvias – principalmente um único erro de configuração do firewall seria capaz de violar todos os defesas arquitetônicas para os dados sensíveis. Essa não é a única explicação para a violação, no entanto, e suspeito que ela tenha sido mais usada, usando recursos do IAM e do EC2 projetados para flexibilidade, mas que podem ser usados indevidamente para conceder privilégios adicionais.
Dado que eles estão descrevendo o “primeiro comando”, acho razoável assumir que eles estão se referindo a um script AWS CLI. Se a instância do EC2 já tivesse acesso ao S3, o invasor teria apenas que executar algo como:
> curl http://169.254.169.254/latest/meta-data/iam/security-credentials/DemonstrationEC2Role
Esse comando recupera as credenciais temporárias do IAM atuais da função dos metadados da instância do EC2. A saída é assim:
Esse comando recupera as credenciais temporárias do IAM atuais da função dos metadados da instância do EC2. A saída é assim:
{
“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 é tudo o que seria necessário para acessar os buckets do S3 e seu conteúdo.
Mas há outra possibilidade quanto ao que esse “primeiro comando” fez, e todos que usam o AWS precisam estar cientes disso. Se o servidor comprometido não tivesse acesso aos buckets privados do S3, mas tivesse permissões para listar e anexar políticas do IAM, o invasor poderia ter usado esses recursos para ir essencialmente comprar um conjunto de credenciais que fornecessem esse acesso. Como as permissões do IAM geralmente não têm relação com controles de acesso à rede em 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 meio primário de “movimento lateral” dentro do ambiente de nuvem.
O comando abaixo, por exemplo, 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
que retorna o seguinte, mostrando que substituí com sucesso as permissões do IAM existentes para aquelas 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 tal expedição de pesca incluem:
Outros comandos úteis para tal expedição de pesca incluem:
> aws iam list-roles
> aws iam list-policies
> aws iam list-instance-profiles
Isso faz o que diz na lata – enumerar o catálogo de recursos disponíveis do IAM que um atacante pode querer usar depois de ter o shell em uma instância do EC2.
Neste exemplo, substituí um perfil limitado do IAM por um com permissões adicionais para o S3. Não podemos descartar que o atacante executou uma abordagem semelhante na violação do Capital One. Seja ou não esse o caso, é um recurso essencial a ser lembrado quando você configura as funções do IAM para suas instâncias do EC2, especialmente aquelas voltadas ao público, já que as permissões do IAM podem “saltar” para recursos privados em seu ambiente.
Em qualquer cenário, o invasor obteve acesso às credenciais necessárias para recuperar informações do S3 e duplicar essas informações.
Etapa 4: Descoberta e duplicação do bucket do S3
“Capital One determinou que o terceiro comando (o” Sync Command “), quando executado, usava o papel *** – WAF para extrair ou copiar dados dessas pastas ou baldes no espaço de armazenamento do Capital One para o qual o *** – A conta do WAF-Role tinha as permissões necessárias (III.A.11) “
Isso sugere o uso do comando AWS CLI aws s3 sync, então acho que é mais uma evidência de que o atacante ganhou acesso ao shell à instância do EC2 e usou o AWS CLI para executar esses comandos. De acordo com a DoJ Complaint, o invasor listou os buckets S3 com o segundo comando, o que sugere que a função do IAM que ela usou tinha S3 listada, além de acesso de leitura. Isso destaca o perigo de uma única função do IAM ter essa ampla gama de permissões do S3, pois, mesmo nesse ponto, sem a capacidade de descobrir os intervalos de destino, o atacante provavelmente não conseguiria capturar muito se houvesse dados.
Recomendações
- Monitore constantemente os Grupos de Segurança excessivamente permissivos ou qualquer outro mecanismo de acesso de 0.0.0.0/0. Verificar o provisionamento é necessário, mas não é bom o suficiente. A infraestrutura de nuvem é criada e modificada por meio da API, o que significa que ela está, com frequência, à deriva com o tempo, à medida que diferentes equipes e pessoas interagem com ela.
- Aplique o princípio do menor privilégio e limita implacavelmente as funções do IAM ao que é absolutamente necessário para a função de negócios do recurso que usa essa função. No caso do S3, você pode considerar diferentes terminais públicos para operações de leitura e gravação, com diferentes funções do IAM que não podem executar a outra função. Elimine todos os casos de uso de produção nos quais a listagem de buckets do S3 está ativada, em favor de segredos compartilhados ou outros mecanismos.
- Não permita que as instâncias do EC2 tenham funções do IAM que permitam anexar ou substituir políticas de função em qualquer ambiente de produção.
- Limpa impiedosamente os recursos de nuvem não utilizados (especialmente servidores e buckets S3) que sobraram dos esforços anteriores de desenvolvimento ou depuração de produção.
- Incluir configuração incorreta da infraestrutura de nuvem nos seus esforços de teste de caneta. Use testadores de caneta externos e verifique se eles estão bem informados sobre como encontrar e explorar configurações incorretas da nuvem.
FONTE: https://www.fugue.co/blog/a-technical-analysis-of-the-capital-one-cloud-misconfiguration-breach