Descoberta vulnerabilidade de alta gravidade no Log4j 2.16 (CVE-2021-45105)

Durante a noite, a Apache divulgou que a versão 2.16 do Log4j também está vulnerável a um ataque de negação de serviço, que pode causar a falha completa da aplicação. A gravidade foi classificada como alta (7,5). No momento, a Snyk não tem conhecimento de PoCs completos nem de exploits em circulação. Foi emitido o CVE-2021-45105, e a Apache publicou uma nova versão com correção (2.17.1), para a qual recomendamos a atualização.

A equipe de pesquisa da Snyk está acompanhando de perto essa situação em constante evolução do Log4j e continuará compartilhando detalhes sobre vulnerabilidades assim que soubermos de algo.

Devo atualizar para a nova versão?

Eliminar vulnerabilidades das suas aplicações é sempre importante, mas, como já surgiram algumas na biblioteca Log4j, é preciso colocar esta em perspectiva. Trata-se de uma vulnerabilidade de negação de serviço, e não de execução arbitrária de código, como as duas anteriores; por isso, o risco potencial é menor. O aspecto mais importante aqui é a possibilidade de exploração. As duas vulnerabilidades anteriores podiam ser exploradas com clareza, e havia exemplos de exploits maduros e funcionais que comprovavam isso. Embora exista a possibilidade de explorar esta nova vulnerabilidade de negação de serviço, com os dados disponíveis no momento da redação, não está claro o quanto isso seria fácil ou comum.

Em resumo, se você puder e tiver tempo para corrigir essa vulnerabilidade, atualize para a versão 2.17.1. Mas, antes de atualizar tudo para a 2.17.1, é mais importante garantir que todas as suas versões do Log4j sejam, no mínimo, a 2.16.0, para reduzir o risco de execução arbitrária de código. Se ainda houver serviços que não foram atualizados, faz sentido passar diretamente para a versão mais recente, 2.17.1, para corrigir todos os problemas do Log4j divulgados recentemente.

Por que tantas vulnerabilidades no Log4j apareceram de repente?

Para entender por que tantas divulgações e versões correspondentes foram lançadas em sequência para essa biblioteca, é importante compreender todo o contexto do que está acontecendo e por que faz sentido que novas atualizações tenham sido — e talvez ainda sejam — lançadas.

1. Maior exposição à comunidade — a divulgação inicial da vulnerabilidade crítica de execução remota de código no Log4j atraiu toda a comunidade para o projeto. Com isso, muitos bugs que talvez antes passassem despercebidos estão vindo à tona graças aos esforços da comunidade de código aberto Java. Essa exposição também tem se estendido a outros projetos semelhantes, às vezes com resultados variados, à medida que a pressa em ajudar a divulgar possíveis vulnerabilidades se sobrepõe ao consenso da comunidade.

2. Correção de segurança inicial apressada — embora ainda estejamos entendendo exatamente o que aconteceu antes da divulgação do CVE-2021-44228, parece que o período habitual para divulgação responsável não foi seguido à risca, pois detalhes dessa vulnerabilidade vazaram para o público antes que uma correção completa estivesse pronta. A equipe da Apache precisou lançar uma correção o mais rápido possível. Com isso, outros vetores de ataque e problemas foram identificados, levando aos lançamentos seguintes. 

3. Compatibilidade com versões anteriores — o Log4j é um componente essencial do ecossistema Java. As novas versões precisam manter a compatibilidade com as anteriores para evitar problemas desnecessários que possam impedir os usuários de atualizar para uma versão nova e segura. Infelizmente, essa abordagem necessária e cautelosa impede mudanças amplas nas funcionalidades principais. Por isso, podem existir outros vetores de ataque ou soluções alternativas que ainda não haviam sido descobertos quando a correção foi publicada e que podem vir à tona à medida que a comunidade continua analisando o cenário de ameaças.

O que posso fazer para facilitar as coisas daqui para frente?

Considerando esse contexto, é provável que novas vulnerabilidades e versões correspondentes sejam lançadas em breve. É importante que os usuários do Log4j (e de outros pacotes de código aberto) estejam preparados para essa possibilidade. Estas são algumas práticas recomendadas para aprimorar seu programa de segurança de aplicações e facilitar o gerenciamento desses eventos de dia zero:

• Analise o código diariamente para encontrar as vulnerabilidades mais recentes em código gerenciado e até mesmo em código não gerenciado

• Crie uma SBOM para acompanhar sua cadeia de suprimentos de software

• Configure pipelines DevOps de CI/CD automatizados com segurança de aplicações integrada

• Sempre que possível, adote boas práticas de uso de código aberto, atualizando os pacotes para versões mais recentes. Assim, fica mais fácil instalar correções de segurança urgentes, com menos impacto na compatibilidade do seu projeto.

Siga-nos no LinkedIn, Twitter ou Facebook para acompanhar as últimas notícias sobre Log4Shell e outras vulnerabilidades críticas.