Os defensores pensam em listas, os atacantes pensam em gráficos,” disse John Lambert da Microsoft, resumindo a diferença fundamental de mentalidade entre aqueles que defendem sistemas de TI e aqueles que tentam comprometê-los.
A abordagem tradicional para os defensores é listar lacunas de segurança diretamente relacionadas aos seus ativos na rede e eliminar o máximo possível, começando pelas mais críticas. Já os adversários, começam com o objetivo final em mente e concentram-se em traçar o caminho em direção a uma violação. Eles geralmente procuram o elo mais fraco na cadeia de segurança para invadir e progredir com o ataque até chegar às joias da coroa.
As equipes de segurança devem abraçar a perspectiva do atacante para garantir que as defesas de cibersegurança de suas organizações sejam adequadas. Fazendo uma analogia com um exemplo cotidiano, a maneira padrão de defender nossa casa de intrusos é garantir que todas as portas estejam trancadas. Mas para validar que sua casa está protegida, é necessário testar sua segurança como um ladrão: tentando abrir as fechaduras, escalar janelas e procurar lugares onde as chaves da casa possam estar “seguras”.
Os testes de penetração atendem precisamente a essa necessidade: eles oferecem uma visão do que pode ser comprometido. A prática de testes de penetração existe há décadas, ajudando a revelar o quão resilientes são nossas redes contra ataques maliciosos. No entanto, com as empresas modernas aumentando o uso de serviços na nuvem, é tão necessário aplicar o conceito de testes de penetração tradicionais à nuvem.
A arquitetura em nuvem compreende recursos, identidades e configurações definidos programaticamente e que mudam rapidamente. Como resultado, a nuvem pode ser uma caixa de pandora de complexidade adicional em cibersegurança. Embora os principais provedores de serviços em nuvem implementem práticas rigorosas de segurança, isso pode gerar uma falsa sensação de segurança para organizações que podem não estar cientes de sua responsabilidade em proteger seus ativos na nuvem, conforme definido no modelo de responsabilidade compartilhada da nuvem. Por essas razões, os testes de penetração na nuvem são tão importantes quanto os testes de penetração de rede tradicionais – em alguns casos, até mais.
Neste post, exploramos os blocos de construção básicos dos testes de penetração na nuvem, focando em como os atacantes procuram e exploram lacunas de segurança em sua nuvem.
A seguir, uma explicação detalhada do que seu teste de penetração na nuvem deve abranger. Dependendo do modelo de entrega de serviços em nuvem escolhido, os limites de sua responsabilidade pela segurança podem variar. Em termos gerais, a responsabilidade dos provedores de serviços em nuvem termina onde começa a sua responsabilidade. O provedor de nuvem é responsável pela segurança do hardware e do software subjacentes que permitem seus serviços. Você é responsável por proteger tudo o que cria na nuvem – seus dados, chaves, ativos, serviços, aplicativos e configurações. Consideremos um exemplo do uso de funções Lambda para desenvolver aplicativos nativos da nuvem na Amazon Web Services (AWS). Enquanto a AWS aborda a segurança da infraestrutura de computação e armazenamento e do próprio serviço Lambda, cabe a você garantir que o acesso ao código e aos recursos de sua organização seja seguro. Portanto, é sua responsabilidade garantir que seus desenvolvedores não estejam armazenando credenciais no código das funções ou em variáveis de ambiente que possam ser usadas para comprometer dados sensíveis ou se mover lateralmente na rede se interceptadas por agentes maliciosos.
Para se preparar para vários cenários de violação, os testes de penetração devem usar diferentes pontos de partida: Black Box – o testador não tem acesso inicial dentro do ambiente em nuvem; Gray Box – o testador tem as credenciais de um usuário ou função selecionados como entrada inicial para mostrar o impacto potencial (também conhecido como “raio de explosão”) se uma identidade for comprometida. Para organizações com redes híbridas em nuvem e locais, uma compreensão completa e precisa da exposição ao risco só pode ser alcançada com a capacidade de testar os caminhos de ataque que cruzam entre esses ambientes. Por exemplo, uma máquina localizada no local é comprometida, e o atacante executa um RCE para extrair credenciais da máquina. Usando extração de senhas do navegador, o atacante obtém as credenciais de um desenvolvedor com privilégios em uma VM do Azure. A partir daí, o caminho para violar a nuvem está pavimentado, e esse processo é repetido em diferentes máquinas até que o invasor obtenha os mais altos privilégios no ambiente e possa usar qualquer recurso à vontade. Portanto, os testes de penetração na nuvem devem abranger cenários em que o acesso inicial no local pode levar um invasor a comprometer os recursos na nuvem e vice-versa.
Aqui estão cinco blocos de construção essenciais para testes de penetração na nuvem:
1. Reconhecimento e Descoberta: Mapear todos os ativos dentro do ambiente em nuvem de sua organização; cargas de trabalho, armazenamento, bancos de dados e identidades. A informação reunida nesta fase fornece o escopo de ativos que podem ser usados ou direcionados em um teste e uma linha de base para iniciar ações de ataque.
2. Avaliação de Vulnerabilidades: Revisões de configuração em nuvem e verificações de vulnerabilidades devem ser realizadas para descobrir má configurações e vulnerabilidades conhecidas no software em seus ativos em nuvem. Por exemplo, a segurança da rede em nuvem deve ser avaliada ao avaliar a configuração de controles como firewalls, redes privadas virtuais (VPNs), acesso e configuração de segmentação de rede. Esse processo é necessário para identificar vulnerabilidades, como recursos acessíveis publicamente ou conexões inseguras de VPCs, que poderiam permitir acesso não autorizado, movimento lateral, escalada de privilégios e exfiltração de dados. Outro recurso de alto risco são aplicativos da web, que são frequentemente visados por hackers, pois, por projeto, estão abertos para a Internet. Para validar que os controles de segurança e as implementações de segurança de software não permitem acesso não autorizado a serviços e dados sensíveis, os testes de penetração devem abranger aplicativos da web hospedados em nuvem. Os testes devem incluir os riscos de segurança do top 10 da OWASP, como validação de entrada, injeção de SQL, scripts entre sites (XSS) e falsificação de solicitação de servidor (SSRF). No entanto, varreduras de vulnerabilidades são apenas o começo. As má configurações e vulnerabilidades detectadas precisam ser testadas para verificar a exploração, com o objetivo de propagar um ataque exatamente como um adversário faria. Por exemplo, se um compartilhamento de armazenamento em nuvem acessível publicamente for detectado, ele poderá ser testado escaneando seu conteúdo em busca de segredos valiosos ou tentando exfiltrar dados.
3. Escalação de Privilégios: Métodos de escalonamento de privilégios podem conceder acesso a adversários a dados, aplicativos e serviços mais sensíveis. Os atacantes tentam obter privilégios mais altos através de: Explorar vulnerabilidades e má configurações projetadas para obter privilégios mais altos na rede; lacunas em gerenciamento de identidade e acesso (IAM), como usuários que estão em grupos onde não deveriam estar e funções que são excessivamente permissivas; comprometer identidades com privilégios mais altos por meio de coleta de credenciais – um conjunto de técnicas que envolve localizar e expor credenciais, chaves e tokens de sessão armazenados incorretamente em várias fontes, incluindo, mas não se limitando a arquivos, histórico de shell, registro, variáveis de ambiente, ferramentas de implantação e navegadores. Enquanto a escalada de privilégios é uma técnica de ataque comum usada em redes tradicionais, o desafio de proteger identidades e acesso para evitar tais ataques na nuvem é infinitamente maior. Primeiro, a complexidade das arquiteturas de IAM em nuvem é muito maior. A abundância de identidades humanas e de máquina e políticas intricadas de controle de acesso implementadas para apoiar a orquestração automatizada de recursos em nuvem provavelmente apresentará riscos que os atacantes podem explorar facilmente. Além disso, a combinação de controles de acesso em nuvem e local pode levar a um sistema de regras muito complexo, e os atacantes se beneficiam da complexidade. Segundo, os desenvolvedores que usam a infraestrutura em nuvem para criar seus aplicativos frequentemente colocam segredos codificados em seus códigos e podem esquecer ou negligenciar sua remoção, os expondo a agentes maliciosos.
4. Movimento Lateral: Os testes devem identificar possíveis caminhos entre recursos em nuvem, que os adversários podem aproveitar para coletar dados ou segredos adicionais e avançar em seus ataques. Em cenários de teste de ambientes híbridos, as técnicas de movimento lateral podem ser tentadas como um meio de transição entre locais e nuvem ou vice-versa. Portanto, proteger o ambiente em nuvem como um silo não funcionará. As organizações podem ser impactadas por ataques que se propagam por toda a superfície de ataque – a rede interna, os ativos voltados para o exterior e os ambientes em nuvem. Os adversários não veem as superfícies de ataque organizacionais como entidades desconectadas, mas sim como uma superfície única, então os defensores precisam adotar uma abordagem semelhante, atuando em todos os domínios para interceptar ataques. Para proteger a nuvem, é necessário validar todas as entradas que levam a ela.
5. Coleta de Dados e Exfiltração: A coleta de dados na computação em nuvem refere-se à reunião de dados de múltiplas fontes, principalmente sensíveis, como cartões de crédito, informações pessoais, senhas etc. Este é o principal motivo pelo qual os invasores hackeiam uma rede, para obter informações sensíveis. Às vezes, os adversários armazenarão os dados em um local centralizado, como um passo preliminar para concentrar os dados que desejam exfiltrar. Um teste de penetração na nuvem deve avaliar a capacidade de coletar e depois exfiltrar dados para um local externo e validar os controles de segurança da rede para testar se eles impedem a exfiltração para IOCs conhecidos. Viu este artigo interessante? Este artigo é uma contribuição de um de nossos parceiros valiosos. Siga-nos no Twitter e LinkedIn para ler mais conteúdos exclusivos que postamos.