Webinar sobre Log4Shell: o que você precisa saber

Seja qual for sua função na área de tecnologia, você provavelmente já ouviu falar da vulnerabilidade Log4Shell, que afeta um grande número de aplicações Java, ou já teve que lidar com ela. Para divulgar as informações mais recentes sobre essa vulnerabilidade crítica de dia zero, realizamos recentemente um webinar para deixar todo mundo por dentro do assunto.

No webinar Log4Shell: o que você precisa saber, Steve Kinman (CISO de campo), Simon Maple (CTO de campo) e Kirill Efimov (líder da equipe de pesquisa de segurança) conversaram sobre a vulnerabilidade Log4Shell e como mitigá-la. Confira um breve resumo do que você vai aprender nessa discussão.

O que é Log4j?

Log4j é uma popular biblioteca Java de código aberto, amplamente usada para registrar logs em aplicações Java. O framework de logging usa o serviço JNDI oferecido pelo Java Development Kit (JDK) para buscar informações adicionais da aplicação. Isso torna os logs mais úteis para os desenvolvedores, enriquecendo os dados registrados com mais metadados. Muitos frameworks populares de aplicações Java usam Log4j por padrão, como Apache Struts 2, Apache Solr e Apache Druid.

O registro de logs é muito importante. Aplicações Java registram eventos o tempo todo, especialmente exceções e erros, para que os desenvolvedores entendam o que está acontecendo.

A vulnerabilidade Log4Shell

Log4Shell é o nome dado a uma vulnerabilidade crítica e fácil de explorar na biblioteca Log4j2. A vulnerabilidade (CVE-2021-44228) recebeu uma pontuação CVSS de 10, a mais alta possível.

Uma vulnerabilidade de dia zero crítica, muito difundida e fácil de explorar foi divulgada no Log4j. Esse vetor de ataque existe há cinco ou seis anos. Como é muito fácil explorá-la, há um grande número de ataques em andamento, e a situação está em constante evolução.

Como funciona a exploração da Log4Shell

O JNDI (Java Naming and Directory Interface) é um serviço de diretório semelhante ao LDAP, que permite usar um identificador exclusivo para obter código ou objetos Java. É comum que aplicações Java façam solicitações aos serviços JNDI para obter fontes de dados ou outras informações.

O framework de logging Log4j usa o JNDI para buscar variáveis e outras informações e enriquecer os dados registrados. O problema é que, durante o registro de logs, o Log4j pode tentar resolver strings perigosas em tempo de execução, inclusive URLs de um serviço JNDI não autorizado.

Isso significa que a vulnerabilidade Log4Shell pode permitir que um agente malicioso faça uma solicitação de uma aplicação Java ao próprio serviço JNDI, explorando o serviço de logging e fazendo com que esse serviço responda com um objeto ou código malicioso. Esse ataque de execução remota de código (RCE) pode ter consequências de longo alcance.

Os principais riscos da Log4Shell

No caso da Log4Shell, o risco direto é um ataque de execução remota de código. Por meio da injeção de código malicioso, um agente de ameaças pode implantar malware ou ransomware, assumir o controle de um servidor ou aplicação, exfiltrar dados, comprometer a integridade dos dados ou a disponibilidade da aplicação, ou desativar outros serviços de segurança.

Além do risco imediato de exploração, há outras preocupações relacionadas a aplicações Java vulneráveis. A vulnerabilidade Log4Shell também pode levar a falhas de conformidade regulatória, falhas nos controles de segurança na nuvem, falhas de segurança em aplicações SaaS de terceiros e violações de políticas de conformidade.

O maior risco é seu conselho de administração ou CEO perguntar: “Fomos afetados?” E, se você não tiver uma boa resposta, isso é um risco.

Como identificar a vulnerabilidade Log4Shell

Para as equipes de desenvolvimento Java, mitigar a Log4Shell exige identificar onde o Log4j pode estar sendo usado no grafo de dependências. Isso pode ser difícil, porque descobrimos que 60,8% dos clientes da Snyk usam o Log4j como dependência transitiva — ou seja, o framework de logging está dentro de outra biblioteca de código aberto que eles usam.

Uma das coisas que tornam essa vulnerabilidade ainda mais assustadora para as equipes de segurança é não saber se estão usando o Log4j. Se você não sabe com o que seu software foi realmente desenvolvido, talvez não saiba se foi afetado.

Você pode usar o Snyk para verificar se suas aplicações têm vulnerabilidades como a Log4Shell, mesmo quando esses problemas de segurança estão em dependências transitivas. Assim, você protege sua cadeia de suprimentos de software contra a introdução de riscos de segurança como a Log4Shell. A Snyk também criou um comando snyk log4shell para encontrar a vulnerabilidade em seus arquivos JAR não gerenciados e sombreados.

Como mitigar a exploração da Log4Shell

Depois de identificar a versão do Log4j que você está usando, verifique se ela é, no mínimo, a versão 2.17.1. A recomendação inicial, logo após a descoberta da vulnerabilidade de dia zero, era atualizar para a versão 2.15.0 para corrigir a Log4Shell, mas essa versão também apresenta outros problemas.

Nota do editor: Na época da gravação do webinar, a atualização recomendada era para a versão 2.16. Desde então, ela foi atualizada para a versão 2.17.1. Novas informações sobre essa vulnerabilidade surgem todos os dias, por isso recomendamos consultar regularmente nossa página de recursos sobre a vulnerabilidade Log4Shell para conferir as informações mais recentes.

Se você não puder atualizar a biblioteca imediatamente, será necessário reduzir a possibilidade de exploração da Log4Shell. Para ver o guia completo de correção, consulte nossa folha de consulta sobre a correção da Log4Shell, que atualizamos continuamente à medida que a situação evolui.

Essa vulnerabilidade continuará presente por anos, e o fato de ser de dia zero preocupa o setor. Ela continuará voltando à tona porque as pessoas podem voltar a usá-la ou porque ela pode estar em uma dependência que você desconhece.