Como o Snyk Social Trends ajuda você a corrigir vulnerabilidades críticas

Recentemente, o Snyk adicionou Social Trends aos seus dados de vulnerabilidades. Esse novo indicador mostra quais vulnerabilidades estão em alta, para ajudar você a priorizar melhor a correção. Nossa equipe de pesquisa descobriu uma forte correlação entre vulnerabilidades em alta nas redes sociais e a existência de exploits capazes de causar danos reais ao seu aplicativo.

Acompanhar as tendências nas redes sociais sobre vulnerabilidades de segurança faz sentido na prática. Quando uma vulnerabilidade específica desperta muito interesse nas redes sociais — no Twitter, por exemplo —, isso significa que muita gente conhece o problema. Estatisticamente, também significa que há mais pessoas querendo fazer mal a você. Por isso, pode ser importante dar atenção especial às vulnerabilidades do seu sistema que estão em alta nas redes sociais.

Vamos ver o Snyk Social Trends (análise de sentimento sobre vulnerabilidades) em ação.

Um exemplo em alta no Java

Criei um pequeno aplicativo Java usando uma versão desatualizada do Spring Boot, 2.2.0-RELEASE. Depois de conectar o repositório do GitHub à minha conta Snyk, encontrei a vulnerabilidade abaixo no topo da lista, porque ela está em alta nas redes sociais.

É uma vulnerabilidade de execução remota de código (RCE) na versão incorporada do Apache Tomcat, incluída no pacote starter específico do Spring Boot que estou usando. Ao clicar no botão de tendências, encontrei muitos tweets sobre essa vulnerabilidade específica e um exploit funcional já publicado. Vou voltar a esse assunto mais adiante, mas primeiro, deixe-me explicar a vulnerabilidade.

Entenda a vulnerabilidade de execução remota de código CVE-2020-9484

Vou explicar brevemente como funciona essa vulnerabilidade de RCE no Tomcat. Ela está presente em todas as versões do Tomcat, inclusive na versão incorporada fornecida com o Spring Boot. Também é bom saber que uma atualização que corrige o problema já está disponível para todas as versões.

Imagine que você esteja usando o PersistentManager com um FileStore no Tomcat. O PersistentManager gerencia a sessão, usada para preservar o estado entre as solicitações do cliente ao servidor. Por padrão, o Tomcat usa o StandardManager, que mantém as sessões na memória. Já o PersistenManager transfere as sessões para o armazenamento quando ficam inativas por alguns segundos. Esse armazenamento pode ser um disco, usando o FileStore, ou um banco de dados, usando o JDBCStore.

Com o FileStore, o Tomcat armazena as sessões em um local predefinido como <JSESSIONID>.session. Se uma nova solicitação com um ID de sessão não encontrar a sessão na memória, o PersistentManager procura entre as sessões armazenadas em disco e, quando encontra, desserializa o objeto de sessão armazenado e o carrega na memória.

Mas e se minha sessão for algo como JSESSIONID=../../../../../../../foo/mysession? Por causa da travessia de diretório, o Tomcat vai procurar mysession.session no diretório foo. Se eu conseguir, por algum motivo, enviar um arquivo para esse sistema, posso enviar um arquivo de sessão serializado. Depois, posso acionar a desserialização definindo meu JSESSIONID para o local correspondente. Dependendo do objeto serializado, a desserialização pode levar à execução remota de código malicioso.

Para saber mais sobre os riscos das vulnerabilidades de desserialização, leia a publicação do blog Serialização e desserialização em Java: explicando a vulnerabilidade de desserialização do Java.

Para saber mais sobre essa vulnerabilidade no Tomcat, este ótimo artigo em redtimmy.com explica o problema em detalhes. Você encontra uma prova de conceito do exploit neste repositório do GitHub:  https://github.com/masahiro331/CVE-2020-9484

Como o Snyk Social Trends ajuda você a priorizar o que importa

Você pode dizer que essa vulnerabilidade tem vários pré-requisitos para ser realmente explorada.

1. O PersistentManager precisa estar ativado com o FileStore

2. Os invasores precisam conseguir enviar um arquivo arbitrário

3. É preciso haver um gadget disponível no classpath para o ataque de desserialização

Algumas pessoas podem descartar o problema, dizendo que, por causa desses pré-requisitos, poucos casos são realmente exploráveis. No entanto, como o assunto estava recebendo muita atenção no Twitter, fui investigar melhor e vi que não era tão difícil mudar o gerenciador de sessões para o PersistentManger com FileStore. Além disso, com a quantidade de dependências que uso no aplicativo, é bem possível que haja um gadget por lá.

Então, se alguém da minha equipe decidir, por algum motivo, usar o PersistentManger com FileStore, só faltará permitir o envio de arquivos arbitrários. Como as violações de segurança quase sempre são resultado de uma cadeia de eventos que leva ao desastre — e não de um único evento ou vulnerabilidade —, não acho que seja possível simplesmente ignorar uma vulnerabilidade como essa. Ainda mais quando há correções disponíveis.

Mais importante: se uma vulnerabilidade está em alta, isso significa que muita gente sabe dela e está falando sobre ela — inclusive pessoas mal-intencionadas. Para mim, isso é um sinal de que preciso investigar a vulnerabilidade com ainda mais atenção para descobrir se estou vulnerável agora ou se estarei no futuro.

Ao incluir o indicador de tendência na interface do Snyk, não só destacamos a vulnerabilidade, como também aumentamos sua pontuação de prioridade por esse motivo. Por isso, acreditamos que monitorar as redes sociais para medir a popularidade de uma vulnerabilidade específica é uma ferramenta poderosa para evitar que erros de segurança óbvios e conhecidos passem despercebidos. Então, quando você vir a etiqueta de tendência, recomendamos que examine novamente uma vulnerabilidade que talvez tenha ignorado antes.