22 de março de 2022
Por Thyaga Vasudevan - VP de Gestão de Produtos, Skyhigh Security
A mudança para uma arquitetura nativa da cloud para as suas aplicações empresariais pode proporcionar um enorme valor comercial, acrescentando escala e agilidade e, ao mesmo tempo, aliviando tarefas onerosas como a aplicação de patches e a atualização da infraestrutura do servidor.
No entanto, em cada ambiente de nuvem, seja Amazon Web Services (AWS), Azure ou Google Cloud, existe uma nova categoria de risco. As ameaças nativas da nuvem resultam do novo contexto e dos requisitos de configuração que tem num ambiente de nuvem. Historicamente, as definições predefinidas, como o acesso público a objectos de armazenamento, deixaram os dados confidenciais à vista de todos, fáceis de roubar por qualquer pessoa que procure estas fraquezas.
É fácil cometer erros num novo ambiente, com novas definições introduzidas continuamente à medida que novos recursos são adicionados pelos fornecedores de serviços em nuvem. A configuração do seu ambiente de nuvem é sempre da sua responsabilidade. A AWS e outros não têm qualquer controlo sobre a forma como utiliza os seus serviços. Eles são um modelo a partir do qual pode construir.
Não compreender o resultado das suas configurações e a forma como constrói aplicações nativas da nuvem pode ter consequências catastróficas. E até mesmo os clientes mais experientes da nuvem podem sofrer com essas consequências.
O caso em questão é a violação que a Capital One sofreu há quase três anos, em que um atacante teve acesso aos números da segurança social de 100 milhões de indivíduos dos EUA e aos números da segurança social de 6 milhões de indivíduos do Canadá. O atacante utilizou várias técnicas para aceder aos dados, mas uma das principais conclusões do ataque foi o facto de uma funcionalidade de segurança concebida para proteger o acesso a máquinas virtuais - instâncias Elastic Compute Cloud ou EC - ter permitido o acesso do atacante. O recurso é chamado de serviço de metadados de instância ou IMDS.
Ataques aos metadados da instância
A versão 1 do IMDS (IMDSv1) foi lançada em 2012 para permitir uma maneira mais segura de as instâncias do EC2 interagirem com outros serviços da AWS. Em vez de deixar as chaves do AWS na instância, os clientes agora podem fazer com que a instância do EC2 consulte o serviço de metadados para obter credenciais e fazer chamadas de API do AWS para outros serviços do AWS. Por exemplo, se uma instância EC2 obtivesse alguns dados do cliente, poderia usar o IMDSv1 para armazenar esses dados num bucket do Amazon Simple Storage Service (S3). Foi exatamente esta capacidade que o atacante utilizou para extrair informações sensíveis de um bucket S3 utilizado para armazenar informações sobre os clientes da Capital One.
Nos nossos próprios testes, conseguimos duplicar a forma como esta extração de dados poderia funcionar em qualquer aplicação. No nosso exemplo, uma equipa de epidemiologistas criou uma aplicação nativa da nuvem no AWS com um painel de controlo público para representar visualmente os dados que mostram o seu progresso na análise do genoma de um vírus.
Durante a fase de desenvolvimento desta aplicação, a equipa deparou-se com um desafio. A maioria dos recursos na sua Nuvem Privada Virtual (VPC) devia estar escondida da Internet. O único recurso na sua VPC destinado à visualização pública era o painel de controlo.
O bucket S3 que aloja os seus dados precisava de permanecer privado. Para extrair dados do S3 para o painel de controlo público, adicionaram um proxy reverso, actuando como intermediário. Tudo o que foi necessário foi uma rápida pesquisa no Google e algumas linhas de código para adicionar isto à sua aplicação.
Para a equipa de epidemiologistas, o proxy invertido era uma solução básica e elegante que funcionava perfeitamente para o seu caso de utilização. O que eles não se aperceberam é que isso os preparou para uma violação maciça.
A instância de computação que executa o proxy reverso recebeu uma função de IAM com permissão para acessar seu bucket S3 privado. As credenciais para o proxy reverso acessar o S3 foram obtidas dos metadados da instância.
Um atacante que visitava o site e estava interessado nos seus dados reparou que a equipa tinha referenciado o endereço IP do proxy invertido no painel de controlo. O atacante verificou então se conseguia ligar-se a ele. Depois de confirmar a sua conetividade, o atacante verificou se podia aceder aos metadados da instância através do proxy invertido. Obtenha sucesso.
Através do proxy reverso e dos metadados da instância, o atacante descobriu credenciais para o balde de armazenamento S3 privado da equipa.
Agora, com acesso ao bucket S3, o atacante podia roubar dados altamente sensíveis que a equipa tinha armazenado para a sua aplicação. O atacante simplesmente sincronizou o bucket S3 de destino com o seu próprio bucket S3 noutra conta AWS e os dados passaram a ser seus.
Este tipo de ataque é apenas uma das 43 técnicas descritas pelo MITRE na sua estrutura ATT&CK para ambientes de nuvem: https://attack.mitre.org/matrices/enterprise/cloud/
Como o AWS atenua os ataques aos metadados da instância
Para melhorar a segurança deste serviço, a AWS lançou o IMDSv2, que adiciona várias novas camadas de proteção.
No IMDSv2, os utilizadores externos são impedidos de receber credenciais, permitindo que apenas os recursos da aplicação as recebam. Leia mais sobre esta camada de proteção e o IMDSv2 aqui: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
No entanto, o desafio continua a ser o facto de o IMDSv1 continuar vivo. Não há nada na AWS que impeça os clientes de utilizar o IMDSv1, e ainda pode utilizá-lo por predefinição para todas as suas instâncias EC2. Como mencionámos anteriormente, não é da responsabilidade da AWS garantir que está a utilizar a nuvem de forma segura. Essa responsabilidade recai exclusivamente sobre o cliente.
No ataque que acabámos de descrever, o proxy inverso foi mal configurado para permitir que pedidos externos chegassem a recursos internos. Se a equipa tivesse configurado a sua instância de computação para utilizar o IMDSv2, o acesso não autorizado do agente de ameaça externo teria sido bloqueado.
Como o Skyhigh Cloud Native Application Protection pode ajudar
Em Skyhigh Security, temos várias abordagens que o podem ajudar a detetar e prevenir ataques como este. A Skyhigh Cloud Native Application Protection Platform (CNAPP) é a nossa plataforma de segurança nativa da nuvem que lhe permite monitorizar e atualizar configurações no AWS, Azure, GCP, juntamente com uma vasta gama de medidas de segurança adicionais sobre as quais pode ler aqui.
Utilizando uma integração API direta com o AWS, o Skyhigh CNAPP monitoriza continuamente o Amazon CloudWatch - um serviço de monitorização de aplicações e infra-estruturas - para indicar qual a versão do IMDS que está a utilizar em cada instância EC2.
Quando o CloudWatch regista uma instância que utiliza ativamente o IMDSv1, o Skyhigh CNAPP gera um incidente de segurança, notificando-o para atualizar a sua configuração para o IMDSv2, o que evitará o acesso não autorizado às suas credenciais por utilizadores externos.
Incidentes de política Skyhigh CNAPP para a configuração da versão IMDS
É uma prática recomendada impor o IMDSv2 nas suas instâncias EC2 para todos os códigos e utilizadores locais. Assim que especificar que o IMDSv2 tem de ser utilizado, o IMDSv1 deixará de funcionar. A AWS tem instruções passo a passo sobre como configurar as suas instâncias para utilizar o IMDSv2 aqui.
Para além deste exemplo de ataque, o Skyhigh CNAPP permite-lhe implementar uma série de práticas recomendadas para proteger as suas aplicações nativas da cloud:
- Audite continuamente as suas configurações. Com o Skyhigh CNAPP, pode analisar os modelos do AWS CloudFormation antes de entrarem em produção e, em seguida, detetar qualquer "desvio" nas suas configurações ao longo do tempo. Isto permite-lhe detetar configurações incorrectas e aplicar um modelo de privilégios mínimos para a permissão de recursos.
- Aplique a Confiança Zero. Utilize a confiança zero como metodologia, em que apenas recursos específicos podem ser executados e comunicar uns com os outros. Tudo o resto é bloqueado.
- Verifique se há vulnerabilidades de código. Particularmente com modelos de distribuição de software aberto como o Docker, é importante monitorizar os recursos da sua aplicação para detetar vulnerabilidades de forma contínua.
- Detecte anomalias e ameaças. Com a Análise do Comportamento de Utilizadores e Entidades (UEBA), pode avaliar milhões de eventos na nuvem para descobrir actividades anómalas e ameaças reais, como o roubo de credenciais.
- Execute o DLP em objectos de armazenamento. Tal como qualquer outro serviço de nuvem que sancione, a sua rede ou pontos finais, no AWS pode e deve classificar os seus dados no S3 e executar data loss prevention para impedir tentativas de exfiltração.
Entre em contacto connosco para falar sobre a implementação destas medidas na sua própria organização.
Voltar aos blogues