fbpx

Pentest em seu ambiente AWS – um guia do CTO

Então, você tem pensado em fazer um Pentest em seu ambiente AWS. Excelente! O que isso deveria envolver exatamente? Existem muitas opções disponíveis e saber o que você precisa o ajudará a fazer seu orçamento de segurança, muitas vezes limitado, chegar o mais longe possível.

Em termos gerais, existem quatro áreas de foco principais para a maioria envolvendo AWS:

  • Sua infraestrutura em nuvem acessível externamente
  • Qualquer aplicativo (s) que você está criando ou hospedando
  • Sua infraestrutura interna de nuvem
  • Sua própria configuração AWS

Vamos dar uma olhada em cada um, começando com o mais importante:

Infraestrutura Externa

A boa notícia aqui é que, por padrão, a AWS faz o possível para ajudá-lo a permanecer razoavelmente seguro. Por exemplo, os grupos de segurança “launch-wizard- #” padrão não permitem que suas instâncias EC2 recebam comunicação do mundo externo, a menos que você especifique ativamente adicionando regras adicionais.

Dito isso, a AWS ainda permite que você tenha bastante corda para se enforcar, caso não tome cuidado. Erros clássicos, como equipes de engenharia alterando grupos de segurança para permitir todo o acesso de entrada, ainda são um problema, e a natureza do DevOps significa que os serviços podem ser ativados e desativados regularmente, nem sempre com o conhecimento dos gerentes de equipe.

Simplificando, não há maneira mais fácil para um hacker comprometer você do que encontrar uma falha de segurança simples em sua infraestrutura voltada para a Internet que foi esquecida, seja um banco de dados exposto ou software com vulnerabilidades conhecidas. Isso dá aos invasores a recompensa máxima, pelo mínimo de esforço e, portanto, a probabilidade de isso acontecer é a mais alta – portanto, deve ser sua primeira parada para consertar.

Normalmente, porém, esses tipos de fraquezas podem ser detectados facilmente por um scanner de vulnerabilidade e devido à natureza mutável de seu ambiente (e as novas vulnerabilidades sendo lançadas diariamente); são mais adequados para verificações contínuas do que para um pentest, que normalmente é realizado apenas uma ou duas vezes por ano. Felizmente, existem muitas soluções por aí, e você definitivamente deve usá-las antes mesmo de considerar um pentest, ou estará pagando alguém para lhe dizer algo que você já poderia saber.

Como é sua superfície de ataque mais exposta, você provavelmente não gostaria de remover sua infraestrutura externa do escopo de qualquer pen-test, mas não deveria atribuir uma grande proporção de seu orçamento a ela, se possível, e não espere ver muitos resultados além do que você espera de suas ferramentas de varredura de vulnerabilidade.

Aplicativo da Web

Muitas empresas que estão usando a AWS irão usá-lo para hospedar algum tipo de aplicativo (s) da web para seus clientes, funcionários ou parceiros. E como os aplicativos da web são projetados para serem expostos por sua natureza, eles garantem aos invasores a segunda maneira mais fácil de entrar em seus sistemas – se não forem desenvolvidos com segurança. Isso os torna a segunda superfície de ataque mais importante depois da infraestrutura externa.

Exemplos de tais ataques incluem o famoso hack TalkTalk, em que um cliente de 17 anos conseguiu acessar seu banco de dados de clientes e extrair milhões de registros.

Sempre considere o impacto e a probabilidade de um ataque nesta camada. O fato de seu aplicativo ser totalmente acessível ao público ou a um conjunto limitado de clientes deve levar em consideração sua tomada de decisão. Aplicativos com “avaliações gratuitas”, por exemplo, permitiriam que um invasor se inscrevesse e tentasse. Os serviços B2B para clientes / parceiros pagantes podem ter um perfil de ameaça mais baixo, embora ainda não desprezível, e os aplicativos para funcionários ainda mais baixos. Por outro lado, alguns aplicativos contêm tais informações confidenciais, o impacto pode superar seriamente a probabilidade.

Portanto, dependendo do perfil de risco do seu aplicativo, você pode descobrir que, se só puder pagar os testadores de penetração para fazerem alguns dias de trabalho, é altamente provável que você deva procurar passar o tempo deles. Embora existam ferramentas automatizadas para este tipo de teste e possam ser úteis para cobrir a lacuna entre os testes de penetração, nada no mercado hoje pode substituir a qualidade de um testador humano que entenderá a lógica de negócios de seu aplicativo e buscará maneiras de impactá-lo.

Infraestrutura Interna

A próxima camada de ataque é a infraestrutura na qual seu aplicativo foi criado. Tendo coberto a infraestrutura externa, o lado interno só estará acessível se um invasor já tiver violado suas defesas de alguma forma. Portanto, o perfil de ameaça aqui é secundário em relação aos dois anteriores.

Os testes de penetração da velha escola de data centers ou redes corporativas geralmente giram em torno de ganhar uma posição e, em seguida, “girar” de um sistema para outro, levando ao comprometimento total de contas de administrador ou sistemas principais.

É aqui que os ambientes da AWS podem ser diferentes dos testes de penetração mais tradicionais, já que a natureza definida por software das redes da AWS geralmente significa que controles mais rígidos são mantidos entre as redes e o movimento lateral é um desafio. Por exemplo, mais uma vez, os grupos de segurança “launch-wizard- #” padrão não permitem que suas instâncias EC2 conversem entre si, a menos que você especifique ativamente adicionando-as a um VPC ou adicionando regras adicionais. No entanto, todas as contas da AWS, exceto as mais simples, conseguem se safar com essas configurações simples e, conforme mostrado na recente violação do Capital One, é possível que invasores comprometam as credenciais de função do IAM e as usem para acessar recursos.

Além disso, o acesso integrado e os controles de segurança na AWS significam que é muito menos provável que você tenha criado contas de “administrador” em todo o ambiente que podem ser comprometidas por meio de qualquer uma de suas instâncias EC2. É mais provável que você esteja usando contas privilegiadas da AWS para fazer isso e, portanto, uma revisão de configuração da AWS pode agregar muito mais valor do que um teste de infraestrutura “interno”.

Da mesma forma, embora software não corrigido e serviços inseguros em sistemas internos possam ser um problema, isso depende de até que ponto você criou redes privadas em seu ambiente AWS e quais sistemas podem acessar quais outros. Quanto mais complexidade você tiver, mais um penteste interno pode agregar valor. Se você está simplesmente executando um punhado de EC2s, cada um com seu próprio grupo de segurança, convém pular um pen-test “interno” tradicional e, em vez disso, considerar uma revisão de configuração.

AWS Config

Como mencionado, o AWS pronto para uso faz muito por você em termos de segurança, mas uma revisão de configuração da AWS pode dizer se você configurou as coisas de maneira robusta.

Exemplos clássicos de configuração deficiente da AWS são os buckets S3 expostos de que você ouve falar com frequência, mas também podem incluir coisas como contas de administrador com muitos usuários sendo capazes de acessá-los.

Mais uma vez, isso muitas vezes pode significar pagar a alguém para lhe dizer o que você já sabe (ou poderia facilmente ter descoberto), então pode valer a pena experimentar algumas ferramentas gratuitas antes de encomendar um pen-test (um rápido Google mostra uma variedade de opções), já que a metodologia é provavelmente a mesma e você pode descobrir que precisa responder a muitas perguntas que poderia ter respondido sozinho de qualquer maneira.

Se, no entanto, você não está confiante quanto aos riscos da segurança ou, por motivos de conformidade, precisa de uma auditoria de terceiros, sinta-se à vontade para entrar em contato com um de nossos especialistas em segurança cibernética para discutir o que podemos fazer para ajudar.

Conclusão

O pentest na AWS deve ser tratado com cuidado, pois seria fácil gastar tempo e dinheiro nos lugares errados. O uso sensato da automação deve sempre vir antes das dispendiosas horas de consultoria e, quando necessárias, devem ser usadas da maneira mais econômica.