Negação de serviço por expressão regular em websocket-extensions

Boas-vindas à nova série do blog da Snyk! Nesta série mensal, a Snyk revisita as vulnerabilidades descobertas ou reportadas à nossa equipe de pesquisa. Escolhemos uma vulnerabilidade relevante do mês anterior e contamos a história por trás de sua descoberta, pesquisa e divulgação. Destacamos os pesquisadores, desenvolvedores e usuários que ajudam a identificar e corrigir vulnerabilidades em toda a comunidade de código aberto.

Estamos dando início a esta série mensal com uma vulnerabilidade descoberta no pacote websocket-extensions.

Vulnerabilidade: ReDoS em websocket-extensionsCVEs atribuídos:CVE-2020-7662, CVE-2020-7663Analista da Snyk:Sam SanoopDescoberta por: Robert McLaughlin

Em 2 de junho de 2020, a equipe de pesquisa de segurança da Snyk publicou uma vulnerabilidade de negação de serviço por expressão regular (ReDoS) identificada no popular pacote websocket-extensions, que afetava mais de 13 mil projetos analisados pela Snyk. A vulnerabilidade foi reportada à Snyk por Robert McLaughlin, doutorando no programa de Ciência da Computação da Universidade da Califórnia em Santa Bárbara. Robert trabalha no SecLab da UCSB e se dedica à “detecção e correção automatizadas de vulnerabilidades de segurança em software”. Robert pesquisava vulnerabilidades ReDoS no ecossistema Node.js quando identificou o problema.

Ele nos contou que descobriu a vulnerabilidade inicialmente depois de coletar uma grande amostra de expressões regulares de pacotes npm populares. A equipe do laboratório usou ferramentas de análise de ReDoS para examinar as amostras coletadas. No fim, essa vulnerabilidade foi identificada com a ferramenta de código aberto RegexStaticAnalysis, publicada e mantida por Nicolaas Weideman.

A vulnerabilidade identificada poderia permitir que um usuário mal-intencionado atacasse o algoritmo de expressão regular. Ao fornecer uma entrada criada especificamente para esse fim, o invasor pode provocar uma situação conhecida como “retrocesso catastrófico”, em que o mecanismo de estado da RegEx precisa analisar um grande número de caminhos possíveis para determinar se a string corresponde ao padrão da RegEx. Saiba mais sobre vulnerabilidades ReDoS neste artigo.

Fonte: relatório State of Open Source Security 2019 da Snyk

Além de sua pesquisa, Robert desenvolveu uma exploração de prova de conceito, que forneceu ao nos reportar a vulnerabilidade. Sam Sanoop, analista da equipe de segurança da Snyk, ficou encarregado de validar se a vulnerabilidade podia ser reproduzida. No entanto, a princípio, Sam não conseguiu reproduzir a exploração em um contêiner de teste usando a POC fornecida. Robert então deu a Sam orientações adicionais sobre como executar a exploração. Depois que alguns detalhes da carga útil do ataque foram esclarecidos, Sam conseguiu confirmar que a vulnerabilidade podia, de fato, ser reproduzida.

Além de simplesmente confirmar que havia código vulnerável, Sam também verificou se, no contexto do pacote (isto é, na forma como ele foi projetado para ser usado), tratava-se realmente de uma vulnerabilidade que precisava ser corrigida. Essa etapa é especialmente importante ao lidar com vulnerabilidades ReDoS. Há muitos padrões de RegEx no código aberto que, ao serem analisados, podem parecer vulneráveis, mas, na realidade, não podem ser explorados.

Depois de confirmar a validade, o impacto e a gravidade da vulnerabilidade, Sam investigou a base de código do pacote. Ele localizou a linha de código que introduziu a vulnerabilidade e elaborou orientações para corrigir o problema específico encontrado no código. Com essas informações, Sam atribuiu dois CVEs para descrever a vulnerabilidade nas versões JavaScript e Ruby do pacote. Sam também entrou em contato com o responsável pelo reporte para confirmar que a vulnerabilidade havia sido verificada, compartilhar os números de CVE que estavam sendo reservados e informar que a Snyk entraria em contato com o mantenedor. Em seguida, Sam também procurou o mantenedor do pacote e compartilhou os detalhes da vulnerabilidade, além de recomendações específicas para implementar uma correção.

Neste caso, websocket-extensions é um pacote mantido com bastante atividade, e o mantenedor respondeu rapidamente às informações recebidas. Em poucas horas, ele respondeu a Sam confirmando que havia entendido a vulnerabilidade e que estava trabalhando em uma correção. Sam forneceu os números de CVE para que o mantenedor pudesse mencioná-los ao lançar a correção, e os dois combinaram uma data para divulgar a vulnerabilidade. O mantenedor conseguiu lançar uma correção em até um dia após a Snyk reportar o problema, e os relatos da vulnerabilidade foram publicados no dia seguinte.

Esta vulnerabilidade é um ótimo exemplo de como o processo de divulgação da Snyk ajuda pesquisadores a reportar suas descobertas e receber crédito por elas, ao mesmo tempo que promove a colaboração com mantenedores de código aberto. Robert, o pesquisador que reportou essa vulnerabilidade, nos contou por que escolheu fazer a divulgação pela Snyk:

“Meu principal objetivo ao divulgar uma vulnerabilidade é obter a atribuição de um CVE, e a Snyk faz isso muito bem. Também valorizo o fato de a Snyk entrar em contato com os mantenedores responsáveis e coordenar uma correção.” - Robert McLaughlin

O objetivo da Snyk é garantir a validade e a possibilidade de exploração das vulnerabilidades, além de oferecer aos mantenedores um processo de divulgação responsável e orientações detalhadas para corrigi-las. Para saber mais sobre essa vulnerabilidade ou como reportar uma vulnerabilidade descoberta em um projeto de código aberto, consulte os links abaixo.

• Reporte uma vulnerabilidade

• Descrição da vulnerabilidade (JavaScript)

• Descrição da vulnerabilidade (Ruby)