Justo quando o Natal se aproxima, uma vulnerabilidade crítica em uma biblioteca do Apache chamada Log4j 2 bateu à porta de muitos usuários. A Log4j é uma biblioteca de registro de logs baseada em Java que é bastante utilizada por muitos produtos, serviços e componentes Java. Não é de gerar tanta surpresa que a falha, que marcou 10 em cada 10 na escala de gravidade do CVSS e coloca inúmeros servidores em risco de serem tomados por cibercriminosos, tenha chamado à atenção não apenas do setor de segurança, mas também de outras indústrias.

De fato, com a publicação do código do exploit como prova de conceito já disponível on-line, estamos agora testemunhando uma corrida entre os cibercriminosos que estão varrendo a internet e explorando sistemas vulneráveis, e aqueles do setor de defesa, que estão atualizando sistemas e implementando mitigações correspondentes, assim como os desenvolvedores, que estão auditando aplicativos e bibliotecas de código para qualquer dependência que possa incluir versões vulneráveis da biblioteca log4j.

O que é a Log4Shell?

Indexado como CVE-2021-44228, a falha consiste em uma vulnerabilidade de execução de código remoto (RCE, pela sigla em inglês) que permite que um atacante execute o código de sua escolha em um servidor afetado. Se o adversário de alguma forma ganhar acesso à rede local, mesmo que os sistemas internos não estejam expostos à internet, ela pode ser explorada. Em última análise, uma vulnerabilidade de RCE significa que um atacante não precisa ter acesso físico para executar um código arbitrário que pode levar a um controle completo sobre os sistemas afetados e ao roubo de dados confidenciais.

Linha do tempo

Para ajudar a entender como os eventos em torno dessa vulnerabilidade crítica se desdobraram, confira esta linha do tempo:

  • 26 de novembro: o ID da CVE é reservado para a vulnerabilidade.
  • 1 de dezembro: o primeiro exploit conhecido para essa vulnerabilidade é detectado em atividade no contexto de um ataque.
  • 10 de dezembro: o ID da CVE é publicado e um patch é lançado.
  • 11 de dezembro: às 14h24 (CET), o módulo de proteção contra ataques de rede da ESET recebeu uma atualização de detecção para dessa vulnerabilidade.

Detecção

A ESET publicou uma detecção para os exploits dessa vulnerabilidade que poderiam estar presentes tanto no tráfego de entrada quanto no de saída nos sistemas Windows. Os atacantes que tentarem se mover lateralmente de tais sistemas serão bloqueados. A detecção contra tentativas de exploração foi implementada com os seguintes nomes de detecção:

  • JAVA/Exploit.CVE-2021-44228
  • JAVA/Exploit.CVE-2021-44228.B

Veja mais: Log4Shell: atacantes estão explorando a vulnerabilidade para distribuir malware

Medidas de mitigação

Para se proteger dos exploits para essa vulnerabilidade, é essencial encontrar todas as versões vulneráveis da biblioteca. Comece fazendo uma lista ordenada de sistemas que devem ser pesquisados, avaliando-os um a um à medida que você for avançando na lista. A parte mais difícil pode ser olhar as versões vulneráveis existentes em arquivos Java Archive (JAR) como dependências transitivas.

Aqui estão alguns scripts básicos que podem ser usados (que devem ser modificados para se adequar aos seus sistemas):

  • Detecte a presença da Log4j em seus sistemas (Linux e Windows)

Este script, disponível no GitHub, procura o arquivo JndiLookup.class defeituoso em qualquer arquivo .jar em seu sistema.

Linux

sudo grep -r --include "*.jar" JndiLookup.class /

 

Windows

findstr /s /i /c:"JndiLookup.class" C:\*.jar
  • Detecte tentativas de exploração da vulnerabilidade em seus registros (Linux)

Este script, também disponível no link do GitHub acima, procura por tentativas de exploração em arquivos não compactados no diretório de registros do Linux /var/log e em todos os seus subdiretórios:

Grep

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

 

Zgrep

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+
  • Registre os resultados

Após executar quaisquer scripts ou ferramentas de detecção, certifique-se de registrar os resultados de modo a ajudar a criar uma documentação de auditoria completa de todos os seus sistemas. Uma auditoria deve constar se você encontrou uma Log4j no sistema e se houve alguma tentativa de exploração descoberta nos logs.

  • Atualize para a última versão da Log4j

Todas as versões da Log4j, desde 2.0-beta9 à 2.14.1, são vulneráveis. Note que essa biblioteca não deve ser confundida com a log4j-api, que não é afetada por essa vulnerabilidade. O melhor remédio é atualizar suas dependências para usar a última versão, que é a 2.15.0.

Embora as versões 1.x da Log4j não sejam afetadas por essa vulnerabilidade em particular, elas têm outras vulnerabilidades. É importante, portanto, que haja planos concretos de migração para a última versão da biblioteca. Na verdade, agora é o melhor momento para realizar essa atualização.

  • Bloqueie endereços IP suspeitos

Para finalizar, os endereços IP que são conhecidos como suspeitos podem ser bloqueados com o seu firewall e/ou sistema de prevenção de intrusão.

O alerta para os clientes da ESET está disponível aqui (em inglês).