da SeerLight
A construção de qualquer serviço inclui necessariamente um trabalho constante de segurança. Segurança é um processo contínuo que inclui análise e melhoria constante da segurança do produto, monitoramento de novidades sobre vulnerabilidades e muito mais. Incluindo auditorias. As auditorias são realizadas tanto internamente como por especialistas externos, que podem ajudar radicalmente na segurança porque não estão imersos no projeto e têm a mente aberta.
O artigo é sobre a visão mais direta de especialistas externos que ajudaram a equipe Mail.ru Cloud Solutions (MCS) a testar o serviço em nuvem e sobre o que eles encontraram. Como “força externa”, a MCS escolheu a empresa Digital Security, conhecida por sua alta expertise nos círculos de segurança da informação. E neste artigo analisaremos algumas vulnerabilidades interessantes encontradas como parte de uma auditoria externa - para que você evite o mesmo rake ao criar seu próprio serviço de nuvem.
Описание продукта
é uma plataforma para construção de infraestrutura virtual na nuvem. Inclui IaaS, PaaS e um mercado de imagens de aplicativos prontas para desenvolvedores. Tendo em conta a arquitetura 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 entre si, incluindo rede, redes privadas em SDN;
- OpenStack e seus componentes abertos;
- S3 de nosso próprio projeto;
- IAM: projetos multilocatários com modelo;
- Visão (visão computacional): APIs e vulnerabilidades ao trabalhar com imagens;
- interface web e ataques web clássicos;
- vulnerabilidades de componentes PaaS;
- API de todos os componentes.
Talvez isso seja tudo o que é essencial para a história futura.
Que tipo de trabalho foi realizado e por que foi necessário?
Uma auditoria de segurança visa identificar vulnerabilidades e erros de configuração que podem levar ao vazamento de dados pessoais, modificação de informações confidenciais ou interrupção da disponibilidade do serviço.
Durante o trabalho, que dura em média de 1 a 2 meses, os auditores repetem as ações de potenciais invasores e procuram vulnerabilidades nas partes cliente e servidor do serviço selecionado. No âmbito da auditoria à plataforma cloud MCS foram identificados os seguintes objetivos:
- Análise de autenticação no serviço. Vulnerabilidades neste componente ajudariam a entrar imediatamente nas contas de outras pessoas.
- Estudando o modelo e controle de acesso entre diferentes contas. Para um invasor, a capacidade de obter acesso à máquina virtual de outra pessoa é uma meta desejável.
- Vulnerabilidades do lado do cliente. XSS/CSRF/CRLF/etc. É possível atacar outros usuários através de links maliciosos?
- Vulnerabilidades do lado do servidor: RCE e todos os tipos de injeções (SQL/XXE/SSRF e assim por diante). As vulnerabilidades do servidor são geralmente mais difíceis de encontrar, mas levam ao comprometimento de muitos usuários ao mesmo tempo.
- Análise do isolamento do segmento de usuários no nível da rede. Para um invasor, a falta de isolamento aumenta muito a superfície de ataque contra outros usuários.
- Análise de lógica de negócios. É possível enganar empresas e criar máquinas virtuais de graça?
Neste projeto, o trabalho foi realizado segundo o modelo “Gray-box”: os auditores interagiram com o serviço com privilégios de usuários comuns, mas possuíam parcialmente o código-fonte da API e tiveram a oportunidade de esclarecer detalhes com os desenvolvedores. Este é geralmente 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 de o auditor começar a enviar vários payloads (o payload usado para realizar o ataque) para locais aleatórios, é necessário entender como as coisas funcionam e quais funcionalidades são fornecidas. Pode parecer que este é um exercício inútil, pois na maioria dos locais estudados não haverá vulnerabilidades. Mas só a compreensão da estrutura da aplicação e da lógica de seu funcionamento permitirá encontrar os vetores de ataque mais complexos.
É importante encontrar lugares que pareçam suspeitos ou que sejam de alguma forma muito diferentes dos outros. E a primeira vulnerabilidade perigosa foi encontrada desta forma.
IDOR
As vulnerabilidades IDOR (Insecure Direct Object Reference) são uma das vulnerabilidades mais comuns na lógica de negócios, o que permite que um ou outro obtenha acesso a objetos aos quais o acesso não é realmente permitido. As vulnerabilidades do IDOR criam a possibilidade de obter informações sobre um usuário em diversos graus de criticidade.
Uma das opções do IDOR é realizar ações com objetos do sistema (usuários, contas bancárias, itens do carrinho de compras) manipulando identificadores de acesso a esses objetos. Isso leva às consequências mais imprevisíveis. Por exemplo, a possibilidade de substituir a conta do remetente dos fundos, através da qual você pode roubá-los de outros usuários.
No caso do MCS, os auditores acabaram de descobrir uma vulnerabilidade IDOR associada a identificadores não seguros. Na conta pessoal do usuário, identificadores UUID eram usados para acessar quaisquer objetos, que pareciam, como dizem os especialistas em segurança, impressionantemente inseguros (ou seja, protegidos contra ataques de força bruta). Mas para certas entidades, descobriu-se que números previsíveis regulares são usados para obter informações sobre os utilizadores da aplicação. Acho que você pode adivinhar que era possível alterar o ID do usuário em um, enviar a solicitação novamente e assim obter informações contornando 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)
O bom dos produtos OpenSource é que eles possuem um grande número de fóruns com descrições técnicas detalhadas dos problemas que surgem e, se você tiver sorte, uma descrição da solução. Mas esta moeda tem um outro lado: vulnerabilidades conhecidas também são descritas em detalhes. Por exemplo, existem descrições maravilhosas de vulnerabilidades no fórum OpenStack и , que por algum motivo ninguém tem pressa em consertar.
Uma funcionalidade comum dos aplicativos é a capacidade do usuário enviar um link para o servidor, no qual o servidor clica (por exemplo, para baixar uma imagem de uma fonte especificada). Se as ferramentas de segurança não filtrarem os próprios links ou as respostas retornadas do servidor aos usuários, tal funcionalidade poderá ser facilmente utilizada pelos invasores.
As vulnerabilidades do SSRF podem avançar muito no desenvolvimento de um ataque. Um invasor pode obter:
- acesso limitado à rede local atacada, por exemplo, apenas através de determinados segmentos de rede e utilizando um determinado protocolo;
- acesso total à rede local, se for possível fazer o downgrade do nível de aplicação para o nível de transporte e, como resultado, gerenciamento total de carga no nível de aplicação;
- acesso para leitura de arquivos locais no servidor (se o esquema file:/// for suportado);
- И многое другое.
Uma vulnerabilidade SSRF é conhecida há muito tempo no OpenStack, que é de natureza “cega”: quando você entra em contato com o servidor, você não recebe uma resposta dele, mas recebe diferentes tipos de erros/atrasos, dependendo do resultado da solicitação . Com base nisso, você pode realizar uma varredura de portas em hosts da rede interna, com todas as consequências que não devem ser subestimadas. Por exemplo, um produto pode ter uma API de back-office que só pode ser acessada pela rede corporativa. Com documentação (não se esqueça dos insiders), um invasor pode usar SSRF para acessar métodos internos. Por exemplo, se você conseguiu de alguma forma obter uma lista aproximada de URLs úteis, usando o SSRF, você pode examiná-los e executar uma solicitação - relativamente falando, transferir dinheiro de uma conta para outra ou alterar limites.
Esta não é a primeira vez que uma vulnerabilidade SSRF foi descoberta no OpenStack. No passado, era possível baixar imagens VM ISO de um link direto, o que também levava a consequências semelhantes. Este recurso foi removido do OpenStack. Aparentemente, a comunidade considerou esta a solução mais simples e confiável para o problema.
E em relatório disponível publicamente do serviço HackerOne (h1), a exploração de um SSRF não mais cego com a capacidade de ler metadados de instância leva ao acesso Root a toda a infraestrutura do Shopify.
No MCS, vulnerabilidades SSRF foram descobertas em dois locais com funcionalidades semelhantes, 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 o problema mesmo assim, sem esperar pela comunidade.
XSS em vez de carregar shells
Apesar de centenas de estudos escritos, ano após ano o ataque XSS (cross-site scripting) ainda é o mais vulnerabilidade da web (ou ?).
Os uploads de arquivos são o local favorito de qualquer pesquisador de segurança. Muitas vezes acontece que você pode carregar um script arbitrário (asp/jsp/php) e executar comandos do sistema operacional, na terminologia dos pentesters - “carregar shell”. Mas a popularidade de tais vulnerabilidades funciona em ambas as direções: elas são lembradas e soluções são desenvolvidas contra elas, de modo que recentemente a probabilidade de “carregar um shell” tende a zero.
A equipe atacante (representada pela Digital Security) teve sorte. OK, no MCS do lado do servidor o conteúdo dos arquivos baixados foi verificado, apenas imagens foram permitidas. Mas SVG também é uma imagem. Como as imagens SVG podem ser perigosas? Porque você pode incorporar trechos de JavaScript neles!
Descobriu-se que os ficheiros descarregados estão disponíveis para todos os utilizadores do serviço MCS, o que significa que é possível atacar outros utilizadores da nuvem, nomeadamente administradores.
Um exemplo de ataque XSS em um formulário de login de phishing
Exemplos de exploração de ataques XSS:
- Por que tentar roubar uma sessão (especialmente porque agora os cookies somente HTTP estão em todos os lugares, protegidos contra roubo usando scripts js), se o script carregado pode acessar imediatamente a API do recurso? Nesse caso, a carga útil pode usar solicitações XHR para 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 (política de proteção de conteúdo) proibir a injeção de JavaScript, um invasor poderá sobreviver sem ele. Usando HTML puro, crie um formulário de login falso para o site e roube a senha do administrador por meio deste phishing avançado: a página de phishing do usuário termina na mesma URL e é mais difícil para o usuário detectá-la.
- Finalmente, o invasor pode organizar — defina cookies maiores que 4 KB. O usuário só precisa abrir o link uma vez, e todo o site fica inacessível até que o usuário pense em limpar especificamente o navegador: na grande maioria dos casos, o servidor web se recusará a aceitar tal cliente.
Vejamos um exemplo de outro XSS detectado, desta vez com uma exploração mais inteligente. O serviço MCS permite combinar configurações de firewall em grupos. O nome do grupo era onde o XSS foi detectado. Sua peculiaridade era que o vetor não era acionado imediatamente, não ao visualizar a lista de regras, mas ao excluir um grupo:
Ou seja, o cenário acabou sendo o seguinte: um invasor cria uma regra de firewall com “load” no nome, o administrador percebe isso depois de um tempo e inicia o processo de exclusão. E é aqui que o JS malicioso funciona.
Para que os desenvolvedores MCS se protejam contra XSS em imagens SVG carregadas (se não puderem ser omitidas), a equipe de Segurança Digital recomendou:
- Coloque os arquivos enviados pelos usuários em um domínio separado que não tenha nada a ver com “cookies”. O script será executado no contexto de um domínio diferente e não representará uma ameaça ao MCS.
- Na resposta HTTP do servidor, envie o cabeçalho "Disposição de conteúdo: anexo". Então os arquivos serão baixados pelo navegador e não executados.
Além disso, existem agora muitas maneiras disponíveis para os desenvolvedores mitigarem os riscos de exploração do XSS:
- usando o sinalizador “Somente HTTP”, você pode tornar os cabeçalhos de “Cookies” da sessão inacessíveis para JavaScript malicioso;
- tornará muito mais difícil para um invasor explorar o XSS;
- mecanismos de modelo modernos, como Angular ou React, limpam automaticamente os dados do usuário antes de enviá-los para o navegador do usuário.
Vulnerabilidades de autenticação de dois fatores
Para melhorar a segurança da conta, os usuários são sempre aconselhados a habilitar 2FA (autenticação de dois fatores). Na verdade, esta é uma forma eficaz de impedir que um invasor obtenha acesso a um serviço se as credenciais do usuário tiverem sido comprometidas.
Mas será que usar um segundo fator de autenticação sempre garante a segurança da conta? Existem os seguintes problemas de segurança na implementação do 2FA:
- Pesquisa de força bruta do código OTP (códigos únicos). Apesar da simplicidade de operação, erros como falta de proteção contra força bruta OTP também são encontrados por grandes empresas: , .
- Algoritmo de geração fraco, por exemplo, a capacidade de prever o próximo código.
- Erros lógicos, como a capacidade de solicitar OTP de outra pessoa no seu telefone, como este do Shopify.
No caso do MCS, o 2FA é implementado com base no Google Authenticator e . O protocolo em si já foi testado ao longo do tempo, mas vale a pena verificar a implementação da verificação de código no lado do aplicativo.
MCS 2FA é usado em vários lugares:
- Ao autenticar o usuário. Há proteção contra força bruta: o usuário tem apenas algumas tentativas para inserir uma senha de uso único, depois a entrada é bloqueada por um tempo. Isso bloqueia a possibilidade de seleção de OTP por força bruta.
- Ao gerar códigos de backup offline para realizar 2FA, bem como desativá-lo. Aqui não foi implementada nenhuma proteção de força bruta, o que possibilitou, caso você tivesse uma senha de conta e uma sessão ativa, regenerar códigos de backup ou desabilitar completamente o 2FA.
Considerando que os códigos de backup estavam localizados na mesma faixa de valores de string daqueles gerados pela aplicação OTP, a chance de encontrar o código em pouco tempo era muito maior.
O processo de seleção de um OTP para desabilitar 2FA usando a ferramenta “Burp: Intruder”
resultado
No geral, o MCS parece ser um produto seguro. Durante a auditoria, a equipe de pentesting não conseguiu obter acesso às VMs dos clientes e aos seus dados, e as vulnerabilidades encontradas foram rapidamente corrigidas pela equipe do MCS.
Mas aqui é importante ressaltar que a segurança é um trabalho contínuo. Os serviços não são estáticos, estão em constante evolução. E é impossível desenvolver um produto completamente sem vulnerabilidades. Mas você pode encontrá-los a tempo e minimizar a chance de recorrência.
Agora todas as vulnerabilidades mencionadas no MCS já foram corrigidas. E para reduzir ao mínimo o número de novos e reduzir a sua vida útil, a equipa da plataforma continua a fazer o seguinte:
- realizar regularmente auditorias por empresas externas;
- apoiar e desenvolver a participação;
- envolver-se em segurança. 🙂
Fonte: habr.com