A mudança para a nuvem
Vamos dar uma breve olhada em por que a segurança na nuvem é um tópico tão importante antes de começarmos com o hacking na nuvem!
As empresas estão migrando rapidamente da infraestrutura hospedada no data center e no local para arquiteturas híbridas que incluem infraestrutura como serviço (IaaS) hospedada na nuvem. Qual é a razão por trás disso? Existem vários benefícios de usar a nuvem:
O acesso aos dados está disponível a qualquer momento e de qualquer local.
Segurança aprimorada (os provedores de nuvem podem corrigir o problema de uma vez por todas)
Custo reduzido em despesas de CAPEX x OPEX e computação sem servidor PAYG (elasticidade)
Escalabilidade e flexibilidade, permitindo que as empresas sejam responsivas
Um único painel de vidro para gerenciamento e monitoramento
Pacotes de segurança integrados, como o Azure Sentinel
Amazon Web Services, Microsoft Azure e Google Cloud Platform são os três maiores provedores de serviços em nuvem no momento, com uma participação de mercado combinada de mais de 60%.
Dados baseados em: Participação no mercado mundial da Statista de provedores de serviços de infraestrutura em nuvem.
Com o rápido aumento na adoção da computação em nuvem, as empresas precisam cada vez mais de pessoas que possam gerenciar, proteger e realizar auditorias de segurança nesse novo tipo de infraestrutura. De acordo com o Occupational Outlook Handbook for Information Security Analysts do Bureau of Labor Statistics dos EUA, lançado em setembro de 2021, as profissões de segurança cibernética em geral são um dos setores profissionais que mais crescem, com funções ligadas à segurança na nuvem em demanda particularmente alta.
Uma migração perigosa?
Deixar de se preparar é se preparar para falhar. Isso é especialmente verdadeiro para migrações na nuvem. Pode parecer simples “levantar e mudar” os serviços existentes para a nova infraestrutura, mas requer uma preparação cuidadosa de vários ângulos, incluindo a segurança. Simplesmente migrar uma infraestrutura ou aplicativo para a nuvem não garante segurança, escalabilidade ou redundância. Alguns dos erros mais comuns de segurança na nuvem estão listados abaixo.
Contas de serviço padrão com privilégios excessivos
Falta de visibilidade (levando a shadow IT)
Falta de pessoal com o conhecimento necessário para gerenciar a segurança de aplicativos e serviços em nuvem
Erros de configuração que expõem dados confidenciais
Mal-entendido ou falta de conhecimento dos relacionamentos e controles de acesso entre os recursos de nuvem provisionados
Uso indevido ou falta de política que teria evitado configurações incorretas ou configurações de segurança fracas
Serviços em nuvem expostos publicamente
Agora vamos examinar alguns serviços de nuvem comuns e começar a hackear!
Leitura relacionada: Guia de pentesting da AWS
Armazenamento na núvem
O armazenamento em nuvem é atraente devido à sua facilidade de gerenciamento e alta escalabilidade. No entanto, muitas empresas sofreram danos à reputação e danos financeiros como resultado de depósitos de armazenamento mal configurados publicamente acessíveis na AWS, Azure e GCP, ou pelo armazenamento não intencional de dados privados em armazenamento em nuvem pública provisionado adequadamente.
Anteriormente, isso se devia ao fato de que, quando um administrador criava um bucket Amazon S3 (Simple Storage Service), as configurações pré-preenchidas permitiam o acesso público por padrão. No entanto, a Amazon logo começou a exibir um aviso ao criar um bucket, informando aos usuários que o recurso e os dados subjacentes seriam públicos.
Um aviso adicional foi exibido ao configurar arquivos carregados no bucket para serem lidos por todos.
Apesar do fato de que as configurações de criação de bucket do S3 agora são seguras por padrão e vários avisos alertam os administradores sobre configurações inseguras, as violações de dados causadas por buckets S3 com vazamento continuam a ocorrer.
Existem sites como https://buckets.grayhatwarfare.com/ , que nos permitem pesquisar recursos de blob AWS S3 e Azure contendo dados acessíveis publicamente.
Hacking prático
Considere o seguinte estudo de caso do Mega Bank, uma corporação (fictícia) que nos pediu para realizar uma avaliação de sua infraestrutura de nuvem.
A inspeção do código-fonte do site revela que as imagens do site estão sendo armazenadas em um bucket do Amazon S3 chamado megabank-supportstorage.
Observação: embora este artigo se concentre na AWS, os problemas de segurança originados pela configuração inadequada dos serviços em nuvem podem afetar a AWS, o Azure e o GCP (e outras plataformas de nuvem) igualmente.
Vamos instalar a AWS CLI para interagir com este recurso.
sudo pip install awscli --upgrade --user
Em seguida, para listar recursivamente o conteúdo desse depósito, emita o comando abaixo.
aws s3 ls s3://megabank-supportstorage --recursive
Como esperado, isso revela imagens do site, mas também parece que algumas informações críticas foram armazenadas ali por acidente. Para baixar o relatório de teste de penetração localmente, execute o seguinte comando.
aws s3 sync s3://megabank-supportstorage/pentest_report/
O relatório contém uma série de vulnerabilidades altas e críticas que, se não forem abordadas, podem permitir que agentes mal-intencionados comprometam a rede da empresa e acessem seus dados.
Aprendizado:
Não habilite o acesso público para armazenamento em nuvem se isso não for necessário.
Não armazene informações confidenciais em armazenamento em nuvem que possa ser legitimamente configurado para acesso público.
Nomeie o armazenamento em nuvem adequadamente para que seja óbvio para que serve o armazenamento.
Recurso recomendado: Como se tornar um engenheiro de segurança na nuvem
Computar metadados da instância
Outro serviço de nuvem implicado em grandes violações de dados é o AWS Instance Metadata Service, que fornece aos administradores informações para configurar e gerenciar suas instâncias do Elastic Compute Cloud (EC2). O serviço Instance Metadata está vinculado ao endereço IP 169.254.169.254, que é um endereço de link local interno que não é exposto ou roteável externamente. Podemos interagir com o serviço localmente por meio de uma API REST. Emita o comando abaixo para retornar os metadados do EC2.
curl 169.254.169.254/latest/meta-data/
Esses metadados podem conter informações confidenciais, como credenciais, se os administradores tiverem anexado uma função do IAM à instância do EC2. Como os metadados só podem ser acessados internamente, isso pode não parecer particularmente interessante do ponto de vista da segurança. A presença desses metadados, por outro lado, torna as vulnerabilidades de falsificação de solicitação do lado do servidor (SSRF) em aplicativos hospedados em instâncias de computação ainda mais sérias.
Embora os métodos discutidos nesta postagem funcionem nos casos em que a versão herdada do Instance Metadata Service (IMDSv1) está habilitada, eles não funcionarão com o IMDSv2 mais seguro, que requer autenticação de token. No entanto, o IMDSv1 ainda está ativado por padrão, o que significa que esse problema ainda é extremamente importante.
Vamos continuar hackeando!
Hacking prático
Desta vez, o cliente (fictício) Mega Logística solicitou uma avaliação de segurança. A inspeção de seu site revela vários serviços, um portal e um link chamado Status.
O link Status nos leva à página status.php, que contém funcionalidade para verificar o status dos serviços da empresa.
Examinar o código-fonte revela que um formulário oculto é usado para passar o valor padrão de megalogistic-prod.htb para a página de back-end, que está de alguma forma envolvida na obtenção do status.
Clicar em “Verificar” retorna uma página de status, listando a disponibilidade de vários serviços.
A inspeção da solicitação em Burp e também na barra de endereços revela que o valor padrão é fornecido como um valor para o parâmetro name em uma solicitação GET.
O ping do nome de domínio da empresa megalogistic.htb revela que o endereço IP é do espaço de endereço da AWS, portanto, é possível que o site esteja sendo hospedado em uma instância do EC2. Colar e abrir o URL abaixo na barra de endereço retorna valores de metadados, confirmando que o site está realmente hospedado em uma instância EC2, que está usando IMDSv1.
http://megalogistic.htb/status.php?name=169.254.169.254/latest/meta-data/
Navegar até o caminho /latest/meta-data/iam/info revela que uma função do IAM chamada support foi anexada à instância do EC2.
http://megalogistic.htb/status.php?name=169.254.169.254/latest/meta-data/iam/info
A emissão da solicitação abaixo foi bem-sucedida e ganhamos algumas chaves para o usuário IAM!
http://megalogistic.htb/status.php?name=169.254.169.254/latest/meta-data/iam/security-credentials/support
O AccessKeyId e o SecretAccessKey são usados para assinar solicitações programáticas que fazemos à AWS. Também vemos um token de sessão com tempo limitado, fornecido pelo AWS Security Token Service (AWS STS), que nos permite autenticar nos recursos da nuvem. O comando aws configure nos permite salvar esses valores em um arquivo de credenciais da AWS, localizado em ~/.aws/credentials.
Em seguida, emita separadamente o comando abaixo para adicionar o token de sessão ao arquivo de credenciais.
aws configure set aws_session_token "<token_value>"
Emitir o seguinte comando (efetivamente whoami para AWS) verifica se nossa função atual é suporte.
aws sts get-caller-identity
Agora vamos ver quais privilégios temos.
aws iam list-attached-user-policies --user-name support
Acesso administrativo total a toda a conta da AWS e fim de jogo!
Aprendizado:
Utilize a versão 2 do Instance Metadata Service (IMDSv2).
Se você precisar atribuir uma função do IAM a uma instância do EC2, certifique-se de que ela tenha apenas as permissões mínimas necessárias para executar as tarefas necessárias (de acordo com o princípio do privilégio mínimo).
Esteja ciente de que a presença de metadados de instância pode tornar vulnerabilidades como SSRF muito mais perigosas.
Esses exemplos mostraram com que rapidez e facilidade um ambiente de nuvem pode ser comprometido devido a configurações incorretas e deixando as configurações padrão inalteradas. É fundamental estar ciente dos riscos e planejar com antecedência antes de migrar e provisionar a infraestrutura de nuvem.
Assim como há semelhanças entre a infraestrutura tradicional e a de nuvem, também há um certo grau de cruzamento entre os testes de penetração de infraestrutura tradicional e de nuvem . Podemos atualizar a cadeia de eliminação para nuvem, que é abordada na próxima seção.
A cadeia de destruição da infraestrutura de nuvem
Uma cadeia de destruição é útil para conceituar e associar as etapas que os invasores podem executar em diferentes fases de sua operação.
O Recon envolve a enumeração e identificação da superfície de ataque da infraestrutura de nuvem, bem como a interação com serviços de nuvem expostos publicamente. Frutas fáceis, como baldes S3 e baldes de armazenamento Azure/GCP, podem gerar chaves de nuvem e SSH, senhas, documentos confidenciais e informações de identificação pessoal (PII). Com acesso a chaves ou outras credenciais, podemos tentar nos infiltrar no ambiente de destino. Serão realizadas atividades iniciais de conscientização situacional, como identificação de outros recursos da nuvem e das permissões e privilégios associados ao seu usuário ou aplicativo atual.
Com uma base na infraestrutura de nuvem, procuraríamos realizar atividades de escalonamento de privilégios. A escalação de privilégios em um recurso de nuvem específico ou no ambiente de nuvem geral é útil, pois nos permite realizar atividades adicionais, como acessar dados de outros usuários e arquivos de shell de nuvem ou capturar tráfego e demonstra o impacto de nosso comprometimento. Ser capaz de assumir a função de um usuário mais privilegiado também aumenta a probabilidade de podermos nos mover lateralmente entre recursos de nuvem, contas (AWS), projetos (GCP) grupos de recursos (Azure) ou mover lateralmente de um locatário do Azure para um domínio AD local. Na etapa final, podemos demonstrar o impacto pela exfiltração segura de recursos (supondo que isso tenha sido aprovado pelo cliente).
Aprendizado adicional
Espero que você tenha gostado desta introdução à segurança na nuvem, que é um assunto tão interessante! Para mais informações práticas sobre hacking e aprendizado sobre segurança na nuvem, confira as máquinas Hack the Box Bucket , Sink , Stacked e nossos novos laboratórios de nuvem BlackSky inovadores para empresas.
A tempestade que se aproxima
Se você quiser saber mais sobre hacking na nuvem, inscreva-se em nosso próximo webinar The Gathering Storm em 22 de novembro. Esta é uma ótima maneira de começar sua jornada de aprendizado quando se trata de pentesting na nuvem. Clique aqui para se registrar .
Comentários
Postar um comentário