A vulnerabilidade Log4Shell é o presente de Natal indesejado de 2021

Por Steve Povolny e Douglas McKee · 19 de janeiro de 2022

Visão geral

Em 9 de dezembro, uma vulnerabilidade (CVE-2021-44228) foi publicada no Twitter juntamente com uma PoC no GitHub para a biblioteca de registro Apache Log4j. O bug foi informado originalmente à Apache em 24 de novembro por Chen Zhaojun, da equipe de segurança Alibaba Cloud.

O impacto dessa vulnerabilidade tem o potencial de ser imenso devido ao seu efeito em qualquer produto que tenha integrado a biblioteca Log4j em seus aplicativos, incluindo produtos de gigantes da Internet como Apple iCloud, Steam, armazenamento Samsung Cloud e milhares de produtos e serviços adicionais. Isso é só o começo, já que o Java é muito usado em aplicativos que abrangem quase todos os setores, mas há precauções e estratégias que as empresas podem empregar como proteção proativa para aumentar sua resiliência e se proteger dessas ameaças mais modernas e predominantes.

O que é isso?

A vulnerabilidade existe devido à forma como o recurso JNDI (Java Naming and Directory Interface, interface de nomeação e diretório) resolve variáveis. Quando uma referência JNDI é escrita em um log, a JNDI busca tudo o que for necessário para resolver a variável. Para concluir o processo, ela faz download e executa quaisquer classes remotas necessárias. Isso vale tanto para aplicativos do lado do cliente quanto do servidor, já que os principais requisitos para a vulnerabilidade são qualquer campo de entrada controlado pelo atacante e essa entrada sendo passada para o log.

Para orquestrar esse ataque, um atacante pode usar várias pesquisas diferentes da JNDI. A pesquisa mais popular hoje tanto em PoCs quanto em exploração ativa usa o LDAP; no entanto, outras pesquisas como RMI e DNS também são vetores de ataque viáveis. Convém destacar que os vetores de ataque simplistas LDAP/RMI só funcionam com versões mais antigas do JDK. Algumas publicações demonstraram métodos para contornar essa limitação e conseguir executar código, embora com maior complexidade no ataque.

As vulnerabilidades de desserialização de objetos Java não são uma nova geração de vulnerabilidades ou ataques. Pesquisas ofensivas anteriores, como “marshalsec”, podem ser aplicadas a essa vulnerabilidade, tornando a execução de códigos bastante simples.

Evolução da ameaça e o que está sendo feito

• Em 14 de dezembro, foi confirmado que o Log4j versão 1.2 é vulnerável a ataques semelhantes através do componente JMSAppender e foi emitido o CVE-2021-4104. É importante notar que esse caso não é tão facilmente explorável quanto as versões 2.0-alpha1 a 2.16.0. Para que a exploração ocorra, o JMSAppender deve estar ativado e definido com as configurações TopicBindingName ou TopicConnectionFactoryBindingName permitindo que o JMSAppender execute solicitações JNDI. Essa não é a configuração padrão.

Após essa confirmação, a Apache lançou uma nova versão do Log4j, versão 2.16.0. Essa atualização desabilitou a JNDI por padrão, exigindo que o usuário ativasse explicitamente o recurso JNDI e removesse completamente o suporte a pesquisas de mensagens.

• Então, em 18 de dezembro, uma nova vulnerabilidade de negação de serviço (DoS), CVE-2021-45105, foi descoberta afetando as versões 2.0-alpha1 até 2.16.0 do Log4j. Para minimizar a vulnerabilidade original do Log4j, a Apache desativou completamente as pesquisas de JNDI na versão 2.16.0, mas as pesquisas autorreferenciais permaneceram uma possibilidade em configurações não padrão. Quando uma variável aninhada é substituída pela classe StrSubstitutor, ela chama recursivamente a classe substitute(). Quando essa variável aninhada remete recursivamente à variável que está sendo substituída, ela leva a uma recursão infinita e uma condição de DoS no servidor. Pesquisas atuais mostram que isso não leva a execução de código, como as vulnerabilidades anteriores.

A partir desse ponto, a Apache lançou uma nova versão do Log4j, versão 2.17.0, para abordar a mais recente vulnerabilidade de DoS. Duas classes adicionais foram criadas a partir de StrSubstitutor para gerenciar a análise de sequências de caracteres que podem conter entrada do usuário. Essas adições não permitem avaliação recursiva. Devido à exploração dessa vulnerabilidade que leva a DoS, ela é considerada menos crítica do que as vulnerabilidades log4j relatadas anteriormente que podem levar à execução remota de código.

É importante notar que, para que a exploração seja bem-sucedida, existem várias condições não padronizadas que precisam ser atendidas. Como a situação do Log4j continua a evoluir, recomendamos a atualização para a versão 2.17.1, sempre que possível, além de aproveitar esse tempo para rever as estratégias e práticas gerais de segurança à medida que embarcamos neste novo ano.

Uma perspectiva positiva

Há muitas informações sobre diferentes maneiras de minimizar essa vulnerabilidade, com oportunidades para humanos e máquinas aprenderem e se adaptarem juntos de maneira sempre ativa. À medida que as ameaças se tornam mais dinâmicas, estratégias e processos também precisam garantir que as operações comerciais estejam otimizadas e protegidas. O Log4j representa uma oportunidade decisiva para que as empresas deixem de pensar nas ameaças como um prejuízo inevitável e, em vez disso, as vejam como uma oportunidade de crescimento, aprendizado e adaptação, que servirão de base para maior resiliência e uma vantagem comercial no futuro.

Temos acompanhado de perto essa vulnerabilidade desde que se tornou conhecida, pois reconhecemos o quão fundamental é para a segurança ser uma entidade viva e acompanhar ameaças em rápida evolução, como a do Log4j. Nossa meta inicial era determinar a facilidade de exploração usando a PoC pública, que reproduzimos e confirmamos. Isso foi feito usando-se o contêiner Docker público e uma arquitetura cliente/servidor aproveitando tanto LDAP quanto RMI, juntamente com a marshalsec para explorar a versão 2.14.1 do Log4j.

Daqui para frente, planejamos testar variações da exploração fornecida usando serviços adicionais, como DNS. Enquanto isso, lançamos uma assinatura de rede KB95088 para clientes que utilizam NSP (Network Security Platform). A assinatura detecta tentativas de explorar CVE-2021-44228 sobre LDAP. Essa assinatura pode ser expandida para incluir outros protocolos ou serviços, e assinaturas adicionais podem ser liberadas para complementar a cobertura.

Procurando por mais recursos?

A cobertura completa sobre essa vulnerabilidade pode ser acompanhada em nosso boletim de segurança aqui e uma lista cada vez maior de PoCs e ferramentas pode ser encontrada aqui:

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• https://github.com/christophetd/log4shell-vulnerable-app
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://rules.emergingthreatspro.com/open/
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone