Skip to main content

Programa de divulgação de vulnerabilidades da Snyk: o que acontece nos bastidores?

Escrito por
Headshot of Asaf Biton

Asaf Biton

14 de abril de 2020

0 minutos de leitura

Na Snyk, acreditamos firmemente na segurança da comunidade open source. Por isso, lançamos nosso programa de divulgação responsável de vulnerabilidades, que abrange todas as vulnerabilidades encontradas em pacotes open source gerenciados e em linguagens como JavaScript, Java, Python, .NET, Go, Ruby e PHP.

Por que divulgar vulnerabilidades com a Snyk?

Com nossa prática de divulgação de vulnerabilidades na Snyk, buscamos aproximar pesquisadores e mantenedores e aliviar alguns dos desafios e dificuldades associados à divulgação responsável, como discutimos em um artigo anterior.

Então, como aproximamos esses dois lados? Quando uma nova vulnerabilidade é comunicada à Snyk, ela é encaminhada diretamente à equipe de segurança, que faz a triagem e verifica o relato. Como empresa que prioriza desenvolvedores, acreditamos em uma abordagem que também considere o ponto de vista dos mantenedores. Mantemos uma conversa aberta e colaborativa do início ao fim (de acordo com nossa política de divulgação de vulnerabilidades). Buscamos ouvir as duas perspectivas e chegar a uma decisão que seja aceita pelo mantenedor e também seja a mais responsável, com base em nossa experiência e conhecimento, levando em conta todos os fatores — por exemplo, o contexto do pacote, a gravidade, a probabilidade de exploração e outros.

A Snyk também é uma CNA (Autoridade de Numeração de CVEs) e, por isso, pode atribuir IDs de CVE a problemas relatados. Depois que uma correção é disponibilizada (ou, se não houver resposta em até 50 dias), atribuímos um ID de CVE ao problema e publicamos um comunicado público. A atribuição de um CVE a uma vulnerabilidade é fundamental, pois informa todo o ecossistema sobre o problema e permite que desenvolvedores e organizações tomem as medidas necessárias para proteger seu código.

Durante todo o processo, enviamos atualizações periódicas à pessoa que relatou a vulnerabilidade e, ainda mais importante, damos os créditos a ela por essa importante descoberta.

Até agora, nosso programa divulgou de forma responsável 88 vulnerabilidades descobertas por pesquisadores externos. Vamos conhecer um desses casos.

Estudo de caso: parceria com a Johns Hopkins University

Recentemente, trabalhamos com pesquisadores da Johns Hopkins University em uma divulgação em larga escala de 57 vulnerabilidades.

Como parte de sua tese, a equipe da Johns Hopkins University desenvolveu uma maneira revolucionária de automatizar a identificação de vulnerabilidades:

"Propomos um conceito inovador, chamado Object Property Graph (OPG), para capturar as interações entre objetos JavaScript e facilitar a detecção de vulnerabilidades em JavaScript. Um OPG representa todas as informações sobre nomes de objetos, como nomes de variáveis e propriedades, escopos de objetos e os próprios objetos, como nós em uma estrutura semelhante a um grafo. Assim, é possível percorrer o grafo para resolver um objeto durante a execução. O OPG tem dois principais usos: (i) facilitar a construção de um CFG e DFG melhor, ou seja, mais precisos, diante de uma resolução de objeto desconhecida; e (ii) fornecer as interações entre objetos para que seja possível consultá-las em busca de determinados padrões de vulnerabilidade.

Projetamos e implementamos uma estrutura, chamada OPGen, para gerar OPGs para aplicações Node.js durante uma chamada execução simulada. Aplicamos o OPGen para detectar quatro tipos de vulnerabilidades em Node.js: injeção de comandos, poluição de protótipo, execução arbitrária de código e travessia de caminho.

Sobre o CPG (grafo de propriedades de código), adicionamos os nós de objetos e as arestas relacionadas. Para isso, simulamos a execução do código e verificamos se existe algum fluxo de dados que começa na entrada do usuário e pode chegar às funções de destino."

- Song Li, JHU Security Labs

A equipe entrou em contato conosco pelo formulário de divulgação de vulnerabilidades. Respondemos com um convite para uma chamada de vídeo, a fim de conversar sobre a natureza e a abrangência das descobertas e sobre como poderíamos ajudar.

Depois de entendermos a dimensão da divulgação, criamos um repositório privado compartilhado, onde a equipe poderia adicionar novas descobertas. A equipe nos enviou o tipo de vulnerabilidade, o pacote e as versões afetadas, uma prova de conceito (POC) e uma referência ao código vulnerável. Tudo em um formato próprio, integrado a um pipeline personalizado para nossos sistemas internos, o que nos ajudou a lidar com eficiência com a grande quantidade de descobertas.

Com uma ferramenta interna que criamos, verificamos as POCs relevantes e, em seguida, fizemos a triagem completa e trabalhamos com os mantenedores envolvidos para divulgar a vulnerabilidade de forma responsável.

Até hoje, publicamos mais de 55 vulnerabilidades dessa parceria, incluindo casos de injeção de comandos, travessia de caminho, poluição de protótipo e execução de código. Alguns exemplos são SNYK-JS-BLAMER-559541, SNYK-JS-BODYMEN-548897 e SNYK-JS-PULVERIZR-560122.

Seguimos trabalhando em estreita colaboração com a equipe da JHU Security Labs em novas descobertas e vulnerabilidades que ainda não foram publicadas.

Como começar?

Um primeiro passo importante é ler nossa política de divulgação de vulnerabilidades.

Depois disso, a forma recomendada de enviar um relato é usar o formulário de divulgação dedicado.

Inclua o máximo possível de informações, como:

  • descrição do problema

  • etapas para reproduzir o problema (ou uma prova de conceito)

  • dados de contato — para sabermos a quem dar os créditos e como entrar em contato caso precisemos de mais informações.

Se preferir, você também pode nos enviar um e-mail para report@snyk.io. Mais uma vez, inclua o máximo possível de informações.

Leia mais

Blog

Modelos de ponta encontraram as vulnerabilidades. Só o atacante encontrou as cadeias.

A análise estática encontrou as falhas, mas só os testes de ataque em aplicações ativas provaram como elas poderiam ser encadeadas para causar invasões. Uma comparação entre Evo COS, Claude Security e Claude Code Security.

feature insights context
Blog

Os ataques autônomos já chegaram. A defesa precisa acompanhar o ritmo.

Os atacantes autônomos estão reduzindo o tempo disponível para a defesa. Saiba como a descoberta, a correção, a validação e a prevenção contínuas ajudam as equipes de segurança a acompanhar esse ritmo.

Blog

Seu backlog de vulnerabilidades não é mais uma dívida técnica — é uma superfície de ataque

Um backlog crescente de vulnerabilidades é mais do que uma dívida técnica: ele é uma superfície de ataque. Entenda por que suposições de risco desatualizadas, atacantes automatizados e descobertas encadeadas exigem uma nova abordagem.