por SeerLight
A construção de qualquer serviço obrigatoriamente inclui um trabalho constante na segurança. A segurança é um processo contínuo que envolve análise e melhoria contínuas da proteção do produto, monitoramento de notícias sobre vulnerabilidades e muito mais. Isso inclui auditorias. As auditorias são realizadas tanto internamente quanto por especialistas externos que podem ajudar radicalmente com a segurança, pois não estão imersos no projeto e têm uma visão desobstruída.
Este artigo trata dessa visão desobstruída de especialistas externos que ajudaram a equipe da Mail.ru Cloud Solutions (MCS) a testar o serviço em nuvem, e sobre o que eles encontraram. Como ‘forças externas’, a MCS escolheu a empresa Digital Security, conhecida por sua alta especialização nos círculos de segurança da informação. Neste artigo, analisaremos algumas vulnerabilidades interessantes encontradas durante a auditoria externa — para que você não enfrente as mesmas armadilhas ao criar seu próprio serviço em nuvem.
Descrição do produto
é uma plataforma para a construção de infraestrutura virtual na nuvem. Inclui IaaS, PaaS e um marketplace de imagens de aplicativos prontas para desenvolvedores. Dada a arquitetura da MCS, era 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 mútuo, incluindo redes privadas em SDN;
- OpenStack e seus componentes abertos;
- S3 desenvolvido internamente;
- IAM: projetos multitenant com modelo de papéis;
- Visão (visão computacional): API e vulnerabilidades ao trabalhar com imagens;
- interface web e ataques web clássicos;
- vulnerabilidades de componentes PaaS;
- API de todos os componentes.
Talvez, do que é significativo para a história em diante — é tudo.
Quais trabalhos foram realizados e por que são necessários?
A auditoria de segurança é voltada para a identificação de vulnerabilidades e erros de configuração que podem levar ao vazamento de dados pessoais, modificação de informações sensíveis ou à interrupção da disponibilidade dos serviços.
Durante as atividades, que duram em média de 1 a 2 meses, os auditores repetem as ações de potenciais invasores e buscam vulnerabilidades na parte do cliente e no servidor do serviço escolhido. No contexto da auditoria da plataforma em nuvem MCS, foram definidos os seguintes objetivos:
- Análise de autenticação no serviço. Vulnerabilidades neste componente poderiam permitir acesso imediato a contas alheias.
- Estudo do modelo de roles e da segregação de acesso entre diferentes contas. Para um invasor, a possibilidade de acessar a máquina virtual de outra pessoa é um objetivo desejado.
- Vulnerabilidades da parte do cliente. XSS/CSRF/CRLF/etc. Será que existe uma possibilidade de atacar outros usuários através de links maliciosos?
- Vulnerabilidades da parte do servidor: RCE e várias injeções (SQL/XXE/SSRF e assim por diante). Vulnerabilidades de servidor, em geral, são mais difíceis de encontrar, mas podem levar à compromissão de múltiplos usuários ao mesmo tempo.
- Análise da segregação de segmentos de usuários em nível de rede. Para um invasor, a ausência de isolamento aumenta significativamente a superfície de ataque sobre outros usuários.
- Análise da lógica de negócios. É possível enganar o sistema e criar máquinas virtuais gratuitamente?
Neste projeto, os trabalhos foram realizados sob o modelo ‘Gray-box’: os auditores interagiram com o serviço com privilégios de usuários comuns, mas possuíam parcialmente os códigos-fonte da API e tinham a possibilidade de esclarecer detalhes com os desenvolvedores. Normalmente, este é o modelo de trabalho mais conveniente e ao mesmo tempo bastante realista: informações internas ainda podem ser coletadas por um invasor, é apenas uma questão de tempo.
Vulnerabilidades encontradas
Antes que o auditor comece a enviar diferentes payloads (cargas úteis utilizadas para conduzir o ataque) em lugares aleatórios, é necessário entender como tudo funciona e qual funcionalidade está disponível. Pode parecer uma atividade inútil, já que na maioria dos locais estudados não haverá nenhuma vulnerabilidade. Mas somente o entendimento da estrutura do aplicativo e da lógica de seu funcionamento permitirá encontrar os vetores de ataque mais difíceis.
É importante identificar locais que parecem suspeitos ou que diferem significativamente de outros. E a primeira vulnerabilidade crítica foi encontrada exatamente dessa forma.
IDOR
As vulnerabilidades IDOR (Insecure Direct Object Reference, referências diretas inseguras a objetos) são uma das formas mais comuns de vulnerabilidades em lógica de negócios, que permitem, de alguma forma, acessar objetos para os quais o acesso não é realmente permitido. As vulnerabilidades IDOR oferecem a possibilidade de obter informações sobre o usuário de diferentes graus de criticidade.
Uma das formas de IDOR é a execução de ações com objetos do sistema (usuários, contas bancárias, produtos no carrinho) por meio da manipulação de identificadores de acesso a esses objetos. Isso pode levar a consequências extremamente imprevisíveis. Por exemplo, à possibilidade de troca da conta remetente de fundos, através da qual é possível roubar de outros usuários.
No caso da MCS, os auditores descobriram uma vulnerabilidade IDOR relacionada a identificadores inseguros. No painel do usuário, para acesso a qualquer objeto, foram utilizados identificadores UUID, que pareciam, como dizem os especialistas em segurança, ser impressionantemente difíceis de quebrar (ou seja, protegidos contra ataques de força bruta). Mas para certas entidades, foi descoberto que, para obter informações sobre usuários do aplicativo, foram utilizados números comuns e previsíveis. Acho que você pode imaginar que era possível alterar o ID do usuário para um a mais, reenviar a solicitação e obter assim informações à revelia da ACL (lista de controle de acesso, regras de acesso a dados para processos e usuários).
Server Side Request Forgery (SSRF)
Produtos Open Source são bons porque existem uma enorme quantidade de fóruns com descrições técnicas detalhadas dos problemas que surgem e, se você tiver sorte, com a descrição das soluções. Mas essa moeda tem um lado negativo: também são descritas detalhadamente as vulnerabilidades conhecidas. Por exemplo, no fórum OpenStack, existem descrições excelentes de vulnerabilidades. e , que ninguém parece estar apressado para corrigir.
Uma funcionalidade comum dos aplicativos é a capacidade do usuário de enviar ao servidor um link pelo qual o servidor navega (por exemplo, para carregar uma imagem da fonte especificada). Com filtração insuficiente por parte dos mecanismos de segurança, esse funcionalidade pode ser facilmente explorada por invasores.
As vulnerabilidades SSRF podem avançar significativamente o desenvolvimento de um ataque. Um invasor pode obter:
- acesso restrito à rede local atacada, por exemplo, apenas em certos segmentos da rede e por um protocolo específico;
- acesso total à rede local, se houver possibilidade de retroceder do nível de aplicativo para o nível de transporte e, como resultado, total controle sobre a carga no nível de aplicativo;
- acesso para leitura de arquivos locais no servidor (se o esquema file:/// for suportado);
- e muito mais.
No OpenStack, a vulnerabilidade SSRF é amplamente conhecida e tem um caráter "cego": ao se conectar ao servidor, você não recebe uma resposta, mas sim diferentes tipos de erros/delays, dependendo do resultado da solicitação. Com isso, é possível realizar a varredura de portas em hosts na rede interna, com todas as consequências que não devem ser subestimadas. Por exemplo, o produto pode ter uma API para o back-office, acessível apenas a partir da rede corporativa. Com a documentação (não esqueçamos dos insiders), o invasor pode usar a SSRF para acessar métodos internos. Por exemplo, se de alguma forma foi possível obter uma lista aproximada de URLs úteis, é possível utilizar a SSRF para fazer solicitações — por exemplo, transferir dinheiro de uma conta para outra ou alterar limites.
Este não é o primeiro caso de descoberta de uma vulnerabilidade SSRF no OpenStack. No passado, havia a possibilidade de carregar imagens ISO de VMs através de links diretos, o que também levava a consequências semelhantes. Atualmente, essa função foi removida do OpenStack. Parece que a comunidade considerou isso a solução mais simples e confiável para o problema.
E em um relatório publicamente disponível do serviço HackerOne (h1), a exploração já não é uma SSRF cega com a possibilidade de leitura de metadados da instância, levando a obter acesso Root a toda a infraestrutura do Shopify.
No MCS, em dois lugares com funcionalidades semelhantes, foram descobertas vulnerabilidades SSRF, mas era praticamente impossível explorá-las devido a firewalls e outras proteções. De qualquer forma, a equipe do MCS resolveu o problema sem esperar pela comunidade.
XSS em vez de carregar "shells"
Apesar das centenas de pesquisas escritas, ano após ano, o XSS (ataque de script entre sites) ainda é o mais vulnerabilidade web (ou ?).
O upload de arquivos é o lugar favorito de qualquer pesquisador de segurança. Frequentemente, é possível fazer o upload de um script arbitrário (asp/jsp/php) e executar comandos do sistema operacional, o que os pentesters chamam de "fazer upload de um shell". No entanto, a popularidade dessas vulnerabilidades funciona em ambas as direções: elas são lembradas e ferramentas são desenvolvidas para combatê-las, então a probabilidade de "fazer upload de um shell" tem diminuído para quase zero.
A equipe de ataque (representada pela Digital Security) teve sorte. OK, no MCS, o conteúdo dos arquivos enviados foi verificado no lado do servidor, permitindo apenas imagens. Mas SVG também é uma imagem. E quais são os perigos das imagens SVG? O fato de que fragmentos de JavaScript podem ser incorporados a elas!
Descobriu-se que os arquivos enviados estão acessíveis a todos os usuários do serviço MCS — o que significa que é possível atacar outros usuários da nuvem, especificamente — os administradores.
Exemplo de injeção usando um ataque XSS em um formulário de login de phishing
Exemplos de exploração de ataque XSS:
- Por que tentar roubar uma sessão (especialmente agora que todos os cookies são HTTP-Only, protegidos contra roubo por scripts js), se o script carregado pode se comunicar diretamente com a API do recurso? Nesse caso, a carga útil pode, por meio de solicitações XHR, alterar a configuração do servidor, por exemplo, adicionar a chave SSH pública do invasor e obter acesso SSH ao servidor.
- Se a política CSP (Content Security Policy) proíbe a injeção de JavaScript, o invasor pode agir sem ele. Pode criar uma forma de entrada falsa em HTML puro e roubar a senha do administrador por meio de um phishing avançado: a página de phishing para o usuário aparece na mesma URL, tornando mais difícil para o usuário detectá-la.
- Finalmente, o invasor pode causar — definindo Cookies com um tamanho maior que 4 Kbytes. O usuário só precisa abrir o link uma vez — e todo o site fica indisponível, até que ele perceba que precisa limpar o navegador: na esmagadora maioria dos casos, o servidor web se recusa a aceitar tal cliente.
Vamos considerar um exemplo de outra XSS descoberta, desta vez com uma exploração mais elaborada. O serviço MCS permite agrupar configurações de firewall. A XSS foi encontrada no nome do grupo. Sua particularidade era que o vetor não disparava imediatamente, não ao visualizar a lista de regras, mas ao excluir o grupo:
Ou seja, o cenário era o seguinte: um invasor cria uma regra de firewall com uma 'carga' no nome, o administrador a nota depois de um tempo, inicia o processo de exclusão. E é aqui que o JavaScript malicioso é executado.
Para proteger os desenvolvedores do MCS contra XSS em imagens SVG carregadas (se não puderem ser descartadas), a equipe de Segurança Digital recomendou:
- Hospedar os arquivos carregados pelos usuários em um domínio separado, que não tenha relação com o 'cookie'. O script será executado no contexto de outro domínio e não representará uma ameaça para o MCS.
- No cabeçalho da resposta HTTP do servidor, retornar o cabeçalho 'Content-disposition: attachment'. Assim, os arquivos serão baixados pelo navegador, e não executados.
Além disso, atualmente há muitas maneiras disponíveis para os desenvolvedores mitigarem os riscos de exploração de XSS:
- com a flag 'HTTP Only', é possível tornar os cabeçalhos de sessão 'Cookies' inacessíveis para JavaScript malicioso;
- dificultará significativamente a exploração de XSS por parte de um invasor;
- frameworks modernos, como Angular ou React, limpam automaticamente os dados do usuário antes de exibi-los no navegador do usuário.
Vulnerabilidades da autenticação de dois fatores
Para aumentar a segurança das contas, os usuários são sempre aconselhados a ativar a 2FA (autenticação de dois fatores). De fato, é uma maneira eficaz de impedir que um invasor acesse o serviço, caso as credenciais do usuário tenham sido comprometidas.
Mas o uso de um segundo fator de autenticação sempre garante a segurança da conta? Na implementação de 2FA, existem problemas de segurança como:
- Força bruta do código OTP (códigos de uso único). Apesar da simplicidade de exploração, erros como a falta de proteção contra força bruta de OTP são comuns, mesmo em grandes empresas: , .
- Algoritmo de geração fraco, como a possibilidade de prever o próximo código.
- Erros lógicos, como a possibilidade de solicitar o OTP de outra pessoa para o seu telefone, como foi o caso do Shopify.
No caso do MCS, a 2FA é implementada com base no Google Authenticator e . O protocolo já foi testado pelo tempo, mas a implementação da verificação do código no lado do aplicativo deve ser verificada.
No MCS, a 2FA é utilizada em vários lugares:
- Na autenticação do usuário. Aqui há proteção contra tentativas excessivas: o usuário tem apenas algumas tentativas de entrada da senha única, após as quais a entrada é bloqueada por um tempo. Isso impede a possibilidade de realizar a força bruta do OTP.
- Na geração de códigos de backup offline para a execução do 2FA, bem como na sua desativação. Aqui, não havia implementação de proteção contra tentativas excessivas, o que permitia, tendo a senha da conta e uma sessão ativa, regenerar os códigos de backup ou desativar o 2FA completamente.
Considerando que os códigos de backup estavam no mesmo intervalo de valores que os OTP gerados pelo aplicativo, a chance de adivinhar um código em pouco tempo era significativamente maior.
O processo de adivinhação do OTP para desativar o 2FA usando a ferramenta "Burp: Intruder"
Resultado
De modo geral, o MCS como produto se mostrou seguro. Durante a auditoria, a equipe de pentesters não conseguiu acessar as VMs dos clientes e seus dados, e as vulnerabilidades encontradas foram rapidamente corrigidas pela equipe do MCS.
Mas é importante observar que a segurança é um trabalho contínuo. Os serviços não são estáticos, eles estão em constante desenvolvimento. E é impossível desenvolver um produto completamente sem vulnerabilidades. No entanto, é possível identificá-las a tempo e minimizar a chance de repetição.
Agora, todas as vulnerabilidades mencionadas no MCS já foram corrigidas. Para minimizar o número de novas e reduzir o tempo de sua existência, a equipe da plataforma continua fazendo o seguinte:
- realiza auditorias regularmente com empresas externas;
- apoia e desenvolve a participação;
- trabalha com segurança. 🙂
Fonte: habr.com
