Auditoria de segurança da plataforma em nuvem MCS

SkyShip Dusk por SeerLight

A construção de qualquer serviço inclui necessariamente trabalho constante de segurança. A segurança é um processo contínuo que inclui análise e aprimoramento contínuos da segurança do produto, monitoramento de notícias sobre vulnerabilidades e muito mais. Incluindo - auditorias. As auditorias são realizadas por conta própria e por especialistas externos que podem ajudar dramaticamente na segurança, pois não estão imersos no projeto e têm uma visão clara.

O artigo é sobre essa aparência muito impopular de especialistas externos que ajudaram a equipe do Mail.ru Cloud Solutions (MCS) a testar o serviço em nuvem e sobre o que encontraram. Como "forças externas", o MCS escolheu a Digital Security, conhecida por sua alta experiência na comunidade de segurança. E neste artigo, analisaremos algumas vulnerabilidades interessantes que foram encontradas como parte de uma auditoria externa - para que você obtenha o mesmo rake ao prestar seu serviço em nuvem.

Descrição do Produto

O Mail.ru Cloud Solutions (MCS) é uma plataforma para a construção de infraestrutura virtual na nuvem. Inclui IaaSs, PaaSs, um mercado de imagens de aplicativos prontas para desenvolvedores. Considerando a arquitetura do MCS, foi necessário verificar a segurança do produto nas seguintes áreas:

• proteção da infraestrutura do ambiente de virtualização: hipervisores, roteamento, firewalls;
  
• proteção da infraestrutura virtual dos clientes: isolamento um do outro, incluindo redes, redes privadas no SDN;
  
• OpenStack e seus componentes abertos;
  
• S3 desenvolvimento próprio;
  
• IAM: projetos de vários inquilinos com um modelo;
  
• Visão (visão de máquina): API e vulnerabilidades ao trabalhar com imagens;
  
• interface da web e ataques clássicos da web;
  
• vulnerabilidades dos componentes PaaS;
  
• API de todos os componentes.
  

Talvez tudo o que é essencial para a história subsequente seja tudo.

Que tipo de trabalho foi realizado e por que eles são necessários?

Uma auditoria de segurança visa identificar vulnerabilidades e erros de configuração que podem levar a vazamento de dados pessoais, modificação de informações confidenciais ou violação da disponibilidade de serviços.

Durante o trabalho, que dura em média de um a dois meses, os auditores repetem as ações de possíveis invasores e procuram vulnerabilidades nas partes do cliente e servidor do serviço selecionado. No contexto da auditoria da plataforma em nuvem MCS, os seguintes objetivos foram identificados:

1. Análise de autenticação no serviço. Vulnerabilidades neste componente ajudariam a entrar imediatamente nas contas de outras pessoas.
   
2. O estudo do modelo e controle de acesso entre diferentes contas. Para um invasor, a capacidade de acessar a máquina virtual de outra pessoa é um alvo bem-vindo.
   
3. Vulnerabilidades do lado do cliente. XSS / CSRF / CRLF / etc. Talvez seja possível atacar outros usuários através de links maliciosos?
   
4. Vulnerabilidades no lado do servidor: RCE e todos os tipos de injeções (SQL / XXE / SSRF e assim por diante). As vulnerabilidades do servidor geralmente são mais difíceis de encontrar, mas levam ao comprometimento de muitos usuários ao mesmo tempo.
   
5. Análise de isolamento de segmentos de rede de segmentos de usuários. Para um invasor, a falta de isolamento aumenta significativamente a superfície de ataque de outros usuários.
   
6. Análise de lógica de negócios. É possível enganar uma empresa e criar máquinas virtuais de graça?
   

Neste projeto, o trabalho foi realizado de acordo com o modelo Gray-box: os auditores interagiram com o serviço com os privilégios dos usuários comuns, mas possuíam parcialmente o código fonte da API e tiveram a oportunidade de esclarecer detalhes com os desenvolvedores. Normalmente, esse é o modelo de trabalho mais conveniente e ao mesmo tempo bastante realista: as informações internas ainda podem ser coletadas por um invasor, isso é apenas uma questão de tempo.

Vulnerabilidades encontradas

Antes que o auditor comece a enviar várias cargas úteis (carga útil usada para atacar) para locais aleatórios, é necessário entender como funciona, que funcionalidade é apresentada. Pode parecer que este é um exercício fútil, porque na maioria dos locais estudados não haverá vulnerabilidades. Porém, apenas um entendimento da estrutura do aplicativo e da lógica de sua operação permitirá encontrar os vetores de ataque mais complexos.

É importante encontrar lugares que pareçam suspeitos ou algo muito diferente dos outros. E a primeira vulnerabilidade perigosa foi encontrada dessa maneira.

IDOR

As vulnerabilidades IDOR (Referência Direta a Objetos Inseguros, links diretos inseguros a objetos) são uma das vulnerabilidades mais comuns na lógica de negócios que permite que, de uma maneira ou de outra, obtenha acesso a objetos aos quais o acesso não é realmente permitido. As vulnerabilidades do IDOR criam a possibilidade de obter informações do usuário com graus variados de criticidade.

Uma das opções do IDOR é executar ações com objetos do sistema (usuários, contas bancárias, mercadorias na cesta) manipulando identificadores de acesso para esses objetos. Isso leva às consequências mais imprevisíveis. Por exemplo, a possibilidade de substituição da conta do remetente, devido à qual você pode roubá-los de outros usuários.

No caso do MCS, os auditores descobriram a vulnerabilidade do IDOR associada aos identificadores que não são do sistema. Na conta pessoal do usuário, para acessar qualquer objeto, foram utilizados UUIDs, que pareciam, como dizem os seguranças, impressionantemente não grosseiros (ou seja, protegidos contra ataques de força bruta). Porém, para certas entidades, descobriu-se que números previsíveis comuns são usados ​​para obter informações sobre usuários de aplicativos. Acho que você percebeu que era possível alterar o ID do usuário por um, enviar a solicitação novamente e, assim, obter informações ignorando a ACL (lista de controle de acesso, regras de acesso a dados para processos e usuários).

Falsificação de solicitação do lado do servidor (SSRF)

Os produtos OpenSource são bons porque possuem um grande número de fóruns com uma descrição técnica detalhada dos problemas que surgem e, se você tiver sorte, com uma descrição da solução. Mas esta moeda tem um outro lado: vulnerabilidades conhecidas também são detalhadas. Por exemplo, o fórum do OpenStack possui descrições maravilhosas das vulnerabilidades [XSS] e [SSRF] , que por algum motivo ninguém está com pressa de corrigir.

A funcionalidade frequente do aplicativo é a capacidade do usuário enviar um link para o servidor em que ele clica (por exemplo, para baixar uma imagem de uma fonte especificada). Com a filtragem de segurança insuficiente dos links ou respostas retornadas do servidor para os usuários, essa funcionalidade é facilmente usada pelos atacantes.

As vulnerabilidades do SSRF podem avançar bastante no desenvolvimento de ataques. Um invasor pode obter:

• acesso limitado à rede local atacada, por exemplo, apenas em determinados segmentos de rede e em um determinado protocolo;
  
• acesso total à rede local, se for possível fazer o downgrade do nível do aplicativo para o nível de transporte e, como resultado, gerenciamento de carga total no nível do aplicativo;
  
• acesso à leitura de arquivos locais no servidor (se o esquema file: /// for suportado);
  
• e muito mais
  

O OpenStack é conhecido por sua vulnerabilidade "cega" do SSRF: quando você acessa o servidor, não recebe uma resposta dele, mas obtém diferentes tipos de erros / atrasos, dependendo do resultado da solicitação. Com base nisso, você pode verificar as portas nos hosts da rede interna, com todas as conseqüências resultantes, que não devem ser subestimadas. Por exemplo, um produto pode ter uma API para back-office, disponível apenas na rede corporativa. Possuindo documentação (não se esqueça de informações privilegiadas), um invasor pode usar métodos internos usando o SSRF. Por exemplo, se você conseguiu, de alguma forma, obter uma lista aproximada de URLs úteis, usando o SSRF, você pode examiná-las e executar uma solicitação - relativamente falando, transfira dinheiro de uma conta para outra ou altere os limites.

Este não é o primeiro caso de detecção de vulnerabilidades do SSRF no OpenStack. No passado, era possível fazer o download de imagens ISO da VM por um link direto, o que também levava a consequências semelhantes. Este recurso está atualmente removido do OpenStack. Aparentemente, a comunidade considerou essa a solução mais fácil e confiável para o problema.

E neste relatório publicamente disponível do serviço HackerOne (h1), a exploração de um SSRF não cego com a capacidade de ler metadados da instância leva ao acesso raiz a toda a infraestrutura do Shopify.

No MCS, em dois locais com funcionalidade semelhante, as vulnerabilidades do SSRF foram descobertas, mas eram quase impossíveis de explorar devido a firewalls e outras proteções. De uma forma ou de outra, a equipe do MCS resolveu esse problema de qualquer maneira, sem esperar pela comunidade.

XSS em vez de carregar shells

Apesar de centenas de estudos escritos, de um ano para outro o XSS (ataque de script entre sites) ainda é a vulnerabilidade da Web mais comum (ou ataque ?).

Baixar arquivos é o local favorito de qualquer pesquisador de segurança. Frequentemente, você pode carregar um script arbitrário (asp / jsp / php) e executar comandos do SO, na terminologia de pentesters - “load shell”. Mas a popularidade de tais vulnerabilidades funciona em ambas as direções: elas são lembradas e são desenvolvidas ferramentas contra elas; recentemente, a probabilidade de "carregar o shell" tendia a zero.

A equipe atacante (representada pela Digital Security) teve sorte. OK, no MCS, no lado do servidor, o conteúdo dos arquivos baixados foi verificado, apenas imagens foram permitidas. Mas SVG também é uma imagem. E o que pode ser perigoso imagens SVG? Porque você pode incorporar fragmentos de JavaScript neles!

Os arquivos baixados estão disponíveis para todos os usuários do serviço MCS - o que significa que você pode atacar outros usuários da nuvem, ou seja, administradores.


Um exemplo de uso de um formulário de login de phishing usando um ataque XSS

Exemplos de exploração de um ataque XSS:

• Por que tentar roubar uma sessão (especialmente porque agora em todos os lugares, os cookies somente HTTP são protegidos contra roubo usando js-scripts) se o script baixado pode acessar imediatamente a API do recurso? Nesse caso, a carga útil pode alterar a configuração do servidor por meio de solicitações XHR, por exemplo, adicionar a chave SSH pública do invasor e obter acesso SSH ao servidor.
  
• Se a política de CSP (política de proteção de conteúdo) proibir a implementação de JavaScript, um invasor poderá ficar sem ela. Em HTML puro, crie o formulário de login falso do site e roube a senha do administrador por meio de phishing avançado: a página de phishing do usuário está no mesmo URL e é mais difícil detectá-lo.
  
• Por fim, um invasor pode organizar cookies de configuração de DoS para clientes maiores que 4 KB. Basta que o usuário abra o link uma vez e todo o site se torne inacessível até que você tente limpar especialmente o navegador: na grande maioria dos casos, o servidor da Web se recusará a aceitar esse cliente.
  

Vejamos um exemplo de mais um XSS revelado, desta vez com operações mais complicadas. O serviço MCS permite combinar configurações de firewall em grupos. O XSS foi descoberto no nome do grupo. Sua peculiaridade era que o vetor não funcionava imediatamente, não ao exibir a lista de regras, mas quando o grupo foi excluído:



Ou seja, o cenário era o seguinte: um invasor cria uma regra de firewall com uma "carga" no nome, o administrador percebe isso depois de um tempo e inicia o processo de exclusão. E aqui o JS malicioso também cumpre.

Para os desenvolvedores do MCS, para proteger contra o XSS em imagens SVG para download (se elas não puderem ser abandonadas), a equipe de Segurança Digital recomendou:

• Hospede arquivos carregados por usuários em um domínio separado que não tenha nada a ver com "cookie". O script será executado no contexto de outro domínio e não representará uma ameaça para o MCS.
  
• Na resposta HTTP do servidor, dê o cabeçalho "Disposição do conteúdo: anexo". Os arquivos serão baixados pelo navegador e não executados.
  

Além disso, agora existem muitas maneiras disponíveis para os desenvolvedores reduzirem os riscos de operar o XSS:

• usando o sinalizador "HTTP Only", você pode tornar os cabeçalhos da sessão de cookies inacessíveis ao JavaScript malicioso;
  
• uma política CSP corretamente implementada complicará significativamente a operação do XSS para um invasor;
  
• mecanismos de modelos modernos, como Angular ou React, limpam automaticamente os dados do usuário antes de exibi-los no navegador do usuário.
  

Vulnerabilidades de autenticação de dois fatores

Para aumentar a segurança da conta, os usuários são sempre aconselhados a habilitar 2FA (autenticação de dois fatores). De fato, essa é uma maneira eficaz de impedir que um invasor obtenha acesso ao serviço se as credenciais do usuário tiverem sido comprometidas.

Mas o uso do segundo fator de autenticação sempre garante a segurança da conta? Em uma implementação 2FA, existem esses problemas de segurança:

• Pesquisa detalhada do código OTP (códigos únicos). Apesar da simplicidade de operação, erros como a falta de proteção contra o bruto OTP também são encontrados por grandes empresas: o caso Slack , o caso Facebook .
  
• Algoritmo de geração fraco, por exemplo, a capacidade de prever o código a seguir.
  
• Erros lógicos, por exemplo, a capacidade de solicitar o OTP de outra pessoa no seu telefone, como ocorreu com o Shopify.
  

No caso do MCS, o 2FA é implementado com base no Google Authenticator e no Duo . O protocolo em si já foi testado com o tempo, mas vale a pena verificar a implementação da verificação de código no lado do aplicativo.

O MCS 2FA é usado em vários lugares:

• Na autenticação do usuário. Aqui há proteção contra força bruta: o usuário tem apenas algumas tentativas para inserir uma senha descartável e a entrada fica bloqueada por um tempo. Isso bloqueia a capacidade de interromper o OTP.
  
• Ao gerar códigos de backup offline para executar o 2FA, bem como desativá-lo. Aqui, a proteção contra força bruta não foi implementada, o que tornou possível regenerar códigos de backup ou desativar completamente o 2FA se houvesse uma senha para a conta e uma sessão ativa.
  

Considerando que os códigos de backup estavam localizados no mesmo intervalo de valores de linha daqueles gerados pelo aplicativo OTP, a chance de pegar o código em um curto espaço de tempo era muito maior.


O processo de seleção do OTP para desativar o 2FA usando a ferramenta Burp: Intruder

Resultado

Em geral, o MCS como produto acabou sendo seguro. Durante a auditoria, a equipe do Pentester não pôde acessar as VMs do cliente e seus dados, e as vulnerabilidades encontradas foram rapidamente corrigidas pela equipe do MCS.

Mas aqui é importante observar que a segurança é um trabalho contínuo. Os serviços não são estáticos, estão em constante evolução. E desenvolver um produto completamente sem vulnerabilidades é impossível. Mas você pode encontrá-los a tempo e minimizar a chance de repetição.

Agora todas as vulnerabilidades mencionadas no MCS já foram corrigidas. E, para minimizar o número de novos e reduzir a vida útil, a equipe da plataforma continua fazendo isso:

• realizar auditorias regulares por empresas externas;
  
• apoiar e desenvolver a participação no grupo Mail.ru do programa Bug Bounty ;
  
• fazer segurança. :)