“Os defensores pensam em listas, os atacantes pensam em gráficos”, disse John Lambert da Microsoft, destilando a diferença basic de mentalidade entre aqueles que defendem os sistemas de TI e aqueles que tentam comprometê-los.
A abordagem tradicional para os defensores é listar as lacunas de segurança diretamente relacionadas aos seus ativos na rede e eliminar tantas quanto possível, começando pelas mais críticas. Os adversários, por outro lado, começam com o objetivo closing em mente e concentram-se em traçar o caminho para uma violação. Eles geralmente procuram o elo mais fraco da cadeia de segurança para invadir e progredir no ataque até as joias da coroa.
As equipes de segurança devem adotar a perspectiva do invasor para garantir que as defesas de segurança cibernética da sua organização sejam adequadas. Fazendo uma analogia com um exemplo da vida quotidiana, a forma padrão de defender a nossa casa de intrusões é garantir que todas as portas estão trancadas. Mas para validar que sua casa está protegida é necessário testar sua segurança como um ladrão: tentar arrombar as fechaduras, passar pelas janelas e procurar locais onde as chaves da casa possam ser armazenadas “com segurança”.
Os testes de penetração atendem precisamente a essa necessidade: fornecem uma visão do invasor sobre o 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 as nossas redes contra ataques maliciosos. No entanto, com as empresas modernas aumentando o uso de serviços em nuvem, é igualmente necessário aplicar o conceito de testes de penetração tradicionais à nuvem.
A nuvem não é um porto seguro – saiba o que você precisa proteger
As arquiteturas de nuvem compreendem recursos, identidades e configurações que são definidas programaticamente e mudam em ritmo rápido. Como resultado, a nuvem pode ser uma caixa de Pandora com complexidade adicional de segurança cibernética. Embora os principais fornecedores de serviços em nuvem implementem práticas de segurança rigorosas, isso pode gerar uma falsa sensação de segurança para as organizações, que podem não estar conscientes da sua responsabilidade em proteger os seus ativos na nuvem, conforme definido pelo modelo de responsabilidade partilhada na nuvem. Por essas razões, o pentesting na nuvem é tão importante quanto o teste de penetração de rede tradicional – em alguns casos, até mais.
Nesta postagem do weblog, exploramos os blocos de construção básicos do pentesting na nuvem, com foco em como os invasores procuram e exploram brechas de segurança na sua nuvem.
O que seu Cloud Pentest deve cobrir
Dependendo do modelo de entrega de serviços em nuvem escolhido, os limites da 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 por proteger o {hardware} e o software program subjacente que permite seus serviços. Você é responsável por proteger tudo o que cria na nuvem: seus dados, chaves, ativos, serviços, aplicativos e configurações. Considere um exemplo de uso de funções Lambda para desenvolver aplicativos nativos da nuvem na Amazon Net Companies (AWS). Embora a AWS trate da segurança da infraestrutura de computação e armazenamento e do próprio serviço Lambda, é sua responsabilidade garantir que o acesso ao código e aos recursos da sua organização seja seguro. Portanto, cabe a você garantir que seus desenvolvedores não armazenem credenciais no código das funções ou em variáveis de ambiente que possam ser usadas para comprometer dados confidenciais ou mover-se lateralmente na rede se forem interceptados por agentes mal-intencionados.
Para se preparar para vários cenários de violação, os testes de penetração devem utilizar diferentes pontos de partida:
- Black Field – o testador não tem acesso inicial ao ambiente de nuvem.
- Caixa cinza – o testador tem as credenciais de um usuário ou função selecionada 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 locais e de nuvem híbrida, uma compreensão completa e precisa da exposição ao risco só pode ser alcançada com a capacidade de testar caminhos de ataque que cruzam esses ambientes. Por exemplo, uma máquina native é comprometida e o invasor executa um RCE para coletar credenciais da máquina. Usando a extração de senha do navegador, o invasor obtém as credenciais de um desenvolvedor com privilégios em uma VM do Azure. A partir daí, o caminho para violar a nuvem é pavimentado, e esse processo é repetido em diferentes máquinas até que o invasor obtenha os privilégios mais altos do ambiente e possa aproveitar qualquer recurso à vontade. Portanto, os testes de penetração na nuvem devem abranger cenários em que o acesso inicial no native possa levar um invasor a comprometer os recursos da nuvem e vice-versa.
Aqui estão cinco blocos de construção principais para testes de penetração na nuvem:
1. Reconhecimento e Descoberta
Esta primeira etapa envolve mapear todos os ativos do ambiente de nuvem da sua organização; cargas de trabalho, armazenamento, bancos de dados e identidades. As informações coletadas nesta fase fornecem o escopo dos ativos que podem ser usados ou direcionados em um teste e uma linha de base para iniciar ações de ataque.
No pentesting de rede tradicional, o escopo do teste normalmente é definido pelos endereços IP dos endpoints a serem incluídos no teste. Os recursos da nuvem, por outro lado, são identificados por identificadores exclusivos e o acesso a eles é habilitado por meio de APIs. Portanto, a abordagem típica para reconhecimento em testes de nuvem é coletar as informações dos ativos no início de um teste, conectando-se à API da nuvem da organização.
2. Avaliação de Vulnerabilidade
Revisões de configuração de nuvem e verificações de vulnerabilidades devem ser realizadas para descobrir configurações incorretas e vulnerabilidades de software program conhecidas em seus ativos de nuvem. Por exemplo, a segurança da rede em nuvem deve ser avaliada avaliando a configuração de controles como firewalls, redes privadas virtuais (VPNs), acesso e configurações de segmentação de rede. Este processo é necessário para identificar pontos fracos, como recursos acessíveis publicamente ou conexões de peering de nuvem privada digital (VPC) inseguras, que podem permitir acesso não autorizado, movimentação lateral, escalonamento de privilégios e exfiltração de dados.
Outro recurso de alto risco são as aplicações internet, que são comumente alvo de hackers porque, por definição, estão abertas à Web. Para validar que os controles de segurança e as implementações de segurança de software program não permitem acesso não autorizado a serviços e dados confidenciais, os testes de penetração devem abranger aplicações internet hospedadas na nuvem. Os testes devem incluir os 10 principais riscos de segurança do OWASP, como validação de entrada, injeção de SQL, cross-site scripting (XSS) e Server-Facet Request Forgery (SSRF).
No entanto, as verificações de vulnerabilidades são apenas o começo. As configurações incorretas e as vulnerabilidades detectadas precisam ser testadas quanto à capacidade de exploração, com o objetivo de propagar um ataque exatamente como um adversário faria. Por exemplo, se um bucket de armazenamento em nuvem acessível ao público for detectado, ele poderá ser testado examinando seu conteúdo em busca de segredos valiosos ou tentando exfiltrar dados.
3. Escalação de privilégios
Os métodos de escalonamento de privilégios podem conceder aos adversários acesso a dados, aplicações e serviços mais confidenciais. Os invasores tentam obter privilégios mais elevados:
- Explorar vulnerabilidades e configurações incorretas projetadas para obter privilégios mais elevados na rede
- Lacunas no gerenciamento de identidade e acesso (IAM), como usuários que estão em grupos nos quais não deveriam estar e funções 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 indevidamente em várias fontes, incluindo, entre outros, arquivos, histórico de shell, registro, variáveis de ambiente, ferramentas de implantação e navegadores.
Embora a escalada de privilégios seja uma técnica de ataque comum usada em redes tradicionais, o desafio de proteger identidades e acesso para evitar tais ataques na nuvem é exponencialmente maior.
Primeiro, a complexidade das arquiteturas IAM em nuvem é muito maior. A abundância de identidades humanas e de máquinas e as intrincadas políticas de controle de acesso implementadas para apoiar a orquestração automatizada de recursos em nuvem provavelmente introduzirão riscos que os invasores podem explorar facilmente. Não apenas isso, mas a combinação de controles de acesso na nuvem e no native pode levar a um sistema de regras muito complexo, e os invasores prosperam com a complexidade.
Em segundo lugar, os desenvolvedores que usam infraestrutura em nuvem para criar seus aplicativos muitas vezes colocam segredos codificados em seu código e podem esquecer ou deixar de removê-los, expondo-os a atores mal-intencionados.
4. Movimento Lateral
Os testes devem identificar possíveis caminhos entre os recursos da nuvem, que os adversários podem aproveitar para coletar dados ou segredos confidenciais adicionais e avançar em seus ataques.
Em cenários de teste de ambiente híbrido, as técnicas de movimento lateral podem ser tentadas como um meio de migrar do native para a nuvem ou vice-versa. Portanto, proteger o ambiente de nuvem como um silo não funcionará. As organizações podem ser afetadas por ataques que se propagam por toda a superfície de ataque – a rede interna, ativos externos e ambientes de nuvem. Os adversários não veem as superfícies de ataque organizacionais como entidades desconectadas, mas sim como uma única superfície, por isso os defensores precisam adotar uma abordagem semelhante, trabalhando em vários domínios para interceptar ataques. Para proteger a nuvem, é preciso validar todas as incursões que levam a ela.
5. Coleta e Exfiltração de Dados
A coleta de dados na computação em nuvem refere-se à coleta de dados de vários recursos, principalmente de natureza sensível, como cartões de crédito, informações pessoais, senhas, and so on. Este é o principal motivo pelo qual os invasores invadem uma rede para obter informações confidenciais. Às vezes, os adversários armazenam os dados num native centralizado, como um passo preliminar para concentrar os dados que gostariam de exfiltrar.
Um pentest na nuvem deve avaliar a capacidade de coletar e exfiltrar dados para um native externo e validar os controles de segurança da rede para testar se eles evitam a exfiltração para IOCs conhecidos.
Pentesting na nuvem: chaves para o sucesso
Ao iniciar a jornada de teste de penetração na nuvem, é essential que você gaste algum tempo entendendo o escopo de seus serviços e ativos em nuvem e quais partes da superfície de ataque estão em suas mãos para proteger de acordo com o modelo de responsabilidade compartilhada. Assim, é possível tomar decisões informadas sobre investimentos em testes de nuvem dentro do contexto da exposição ao risco da sua organização.
Como observação closing, a eficácia de um programa de pentesting na nuvem não é determinada apenas pela profundidade e amplitude dos testes, mas também pela frequência dos testes. O ritmo das mudanças nas redes locais está prejudicando a eficácia dos longos ciclos manuais de testes de penetração. Na nuvem, é um arraso. Assim como as equipes de nuvem e de P&D estão automatizando suas operações e implantações em nuvem, as equipes de segurança devem mudar de direção para automatizar suas atividades de testes de penetração na nuvem e, em última análise, complementar o ciclo de integração contínua/implantação contínua com validação contínua.
Para validar com segurança a resiliência da sua empresa a ataques nativos da nuvem, saiba mais sobre o Pentera Cloud e ouça a gravação sob demanda sobre Colocando a segurança da nuvem no teste de resistência.
