A ameaça persistente: por que vulnerabilidades graves como Log4Shell e Spring4Shell continuam sendo relevantes

Como desenvolvedores, estamos sempre equilibrando funcionalidades, correções e prazos. Ainda assim, um problema que passa despercebido com frequência é o uso contínuo de versões vulneráveis do Log4j e do Spring Framework em muitos projetos. Apesar da grande repercussão das vulnerabilidades Log4Shell e Spring4Shell, um número surpreendente de aplicações ainda funciona com essas verdadeiras bombas-relógio. Isso não é um simples descuido — é um grande risco. Somos criadores por natureza, mas construir também significa garantir que nossas estruturas sejam seguras.

O dilema de quem desenvolve

Como desenvolvedores, estamos sempre tentando equilibrar o lançamento de novas funcionalidades com a manutenção dos projetos e recursos existentes. É um malabarismo que exige tempo e muita concentração. Acompanhar as dependências de cada projeto e garantir que estejam atualizadas pode parecer uma batalha difícil, especialmente quando há pressão para entregar novas funcionalidades. No meio dessa correria, vulnerabilidades críticas como Log4Shell e Spring4Shell podem passar despercebidas — não por negligência, mas pelo enorme volume de tarefas que gerenciamos diariamente. Ainda assim, é essencial reconhecer que a segurança das aplicações que desenvolvemos é parte fundamental do desenvolvimento de software hoje.

A situação atual do Log4Shell

Lembra do Log4Shell? Aquela grave vulnerabilidade no Apache Log4j, descoberta em 2021, que permitia que invasores executassem código no seu servidor ao registrar uma string especial? Um invasor podia usar uma consulta JNDI com o protocolo LDAP para injetar um arquivo de classe pré-compilado e executar código malicioso. Mesmo em versões mais recentes do Java, essa vulnerabilidade podia causar danos por meio de ataques de desserialização. A complexidade de exploração dessa vulnerabilidade crítica é considerada muito baixa, o que torna a ameaça ainda maior que o habitual. Confira nosso artigo no blog para entender todos os detalhes do problema.

Mais de 20% das empresas ainda estão vulneráveis ao Log4Shell.

Hoje, muitas empresas ainda têm uma versão desatualizada e vulnerável da biblioteca Log4j em algum de seus projetos. Entre as empresas que analisam o código de produção em busca de vulnerabilidades, 21% ainda têm projetos vulneráveis ao Log4Shell. Isso significa que mais de 60 mil projetos continuam sob risco de sofrer uma invasão por causa de uma vulnerabilidade divulgada e corrigida há mais de dois anos. É muita coisa! Como essas empresas já usam ferramentas de segurança e trabalham ativamente para corrigir os problemas que encontram, o número real de versões vulneráveis do Log4j em uso deve ser muito maior. Só de pensar nisso já dá medo — e é bastante preocupante.

Spring4Shell em circulação

Outro exemplo notório foi o Spring4Shell, divulgado em março de 2022. A vulnerabilidade no spring-beans também podia permitir a execução remota de código malicioso. Embora a complexidade do ataque fosse baixa e houvesse exploits para casos específicos, o impacto foi menor que o do Log4Shell. Confira o artigo no blog dedicado ao assunto para saber mais.

Ao estender essa vulnerabilidade ao Glassfish com um novo exploit em abril de 2022, a equipe da Snyk comprovou que ela é muito relevante e pode ser explorada em muitos outros casos, além do exploit inicial para o Tomcat.

Assim como o Log4Shell, descobrimos que o Spring4Shell ainda está presente em ambientes reais. Cerca de 35% das empresas ainda têm projetos vulneráveis ao Spring4Shell. Embora o risco de uma invasão por Spring4Shell não fosse tão alto quanto o do Log4Shell, a equipe da Snyk demonstrou várias possibilidades de exploração ao identificar e desenvolver uma prova de conceito (PoC) de exploit para o Glassfish. Isso mostra que ameaças aparentemente menores ainda podem causar vulnerabilidades graves. O fato de ainda não haver um exploit publicado não significa que uma aplicação não possa ser comprometida por uma vulnerabilidade!

Além disso, isso mostra que muitas aplicações Spring dependem de versões antigas e desatualizadas do framework, e que atualizar e manter as aplicações existentes não é visto como prioridade. Mas, no fundo, sabemos que isso é uma bomba-relógio prestes a explodir.

Um alerta para todos que mantêm aplicações

Vamos direto ao ponto. Todos conhecemos o orgulho de ver nosso código finalmente funcionando sem problemas, e a última coisa que queremos é voltar a mexer nele — ainda mais por algo que parece tão simples quanto atualizar bibliotecas. Mas é o seguinte: as vulnerabilidades Log4Shell e Spring4Shell não vão se corrigir sozinhas. E, sinceramente, não são pequenos bugs que podemos ignorar. São enormes brechas na segurança da nossa aplicação. Se você ainda tem vulnerabilidades como Log4Shell ou Spring4Shell no seu ambiente, está se expondo desnecessariamente a ataques de alta gravidade!

A Snyk pode ajudar a detectar e corrigir vulnerabilidades de segurança nas aplicações. A plataforma se integra aos fluxos de trabalho de desenvolvimento de várias maneiras, como por meio de repositórios Git, da interface de linha de comando (CLI) ou de pipelines de integração contínua (CI) existentes. Assim, desenvolvedores podem identificar riscos de segurança no início do ciclo de desenvolvimento, antes que se tornem problemas maiores. O cadastro é gratuito e dá acesso imediato aos recursos. Mas o verdadeiro valor está na forma como as vulnerabilidades identificadas são gerenciadas e corrigidas.

Precisamos assumir nossa responsabilidade. Não basta encontrar uma correção rápida ou esperar que uma simples atualização resolva tudo. Às vezes, precisamos tomar a difícil decisão de remover ou substituir uma biblioteca vulnerável. Sim, isso pode nos atrasar um pouco e não é a parte mais empolgante do trabalho, mas é fundamental. O importante é garantir que nosso código seja sólido não só hoje, mas também no futuro.

Então, não vamos esperar que outra pessoa resolva esses problemas. Com as ferramentas certas, podemos identificar essas vulnerabilidades logo no início, mas cabe a nós agir. Somos responsáveis por reforçar nossas defesas, corrigir as vulnerabilidades e manter nossas aplicações seguras. Vamos nessa — não apenas como programadores, mas como profissionais comprometidos com o próprio trabalho e em garantir que ele seja o mais seguro possível.