Log4Sheel: o primeiro ano de vida

Há um ano, em dezembro de 2021, a vulnerabilidade Log4Shell (CVE-2021-44228) na biblioteca Apache Log4j chegou com tudo. Embora no início do ano não estivesse mais nas primeiras páginas dos meios de comunicação de TI, em novembro de 2022 ressurgiu quando foi relatado que cibercriminosos haviam explorado a vulnerabilidade para atacar uma agência federal dos EUA e instalar um minerador de criptomoeda em seus sistemas. Esse é um bom motivo para explicar o que o Log4Shell realmente é, por que é muito cedo para ignorá-lo e como proteger sua infraestrutura.

O que é a biblioteca Apache Log4j?

Como o Java SDK inicialmente não suportava registros, os desenvolvedores tiveram que escrever suas próprias soluções e, quando a API oficial do Java Logging apareceu, já havia algumas delas por aí. Uma delas é a Apache Log4j, uma popular biblioteca Java de código aberto em desenvolvimento desde 2001. Não é, de forma alguma, a única solução de registro em Java, mas certamente uma das mais populares. Muitas soluções alternativas são essencialmente ramificações da Log4j que apareceram em diferentes estágios de desenvolvimento da biblioteca.

O que é a vulnerabilidade Log4Shell?

A biblioteca Log4j permite registrar todos os eventos do sistema automaticamente. Ele usa um conjunto padrão de interfaces para acessar dados Java Naming and Directory Interface (JNDI). Em novembro de 2021, descobriu-se que, durante o registro, ele é capaz de executar comandos JNDI passados ​​a ele por um evento, por exemplo, no campo Header de uma solicitação, em uma mensagem de bate-papo ou na descrição de um erro 404 em um site página.

A vulnerabilidade permite que os cibercriminosos, pelo menos teoricamente, façam o que quiserem no sistema da vítima (se nenhuma medida de segurança adicional entrar em ação). Na prática, os invasores costumam usar o Log4Shell para instalar mineradores ilegais e realizar ataques de ransomware. Mas também usos mais exóticos foram reportados, incluindo ataques direcionados, espalhando o botnet Mirai e até RickRolling – tocando o (irritantemente viciante) hit “Never Gonna Give You Up” do cantor dos anos 80 Rick Astley.

Por que ele é tão perigoso e ainda uma ameaça?

Java é uma das principais linguagens de programação; usada em muitos sistemas de backend — de pequenos servidores corporativos aos de automação industrial e dispositivos IoT. A maioria desses sistemas implementa o registro de uma forma ou de outra. Durante anos, a maneira mais fácil de fazer isso era usar a biblioteca Log4j. Quando, em dezembro de 2021, foi relatado que ela continha uma vulnerabilidade, os especialistas declararam que seria um grande problema por muitos anos. Aqui está alguns dos principais motivos:

• O Log4j é usado em uma vasta gama de aplicativos Java. No momento da descoberta, a vulnerabilidade estava presente em mais de 000 pacotes (artefatos) no Maven Central (o maior repositório de pacotes Java), o que representa 8% de seu número total. Segundo especialistas, cerca de 40% das redes em todo o mundo estavam sob risco do Log4Shell.
• Além de computadores e servidores convencionais, o Java também é usado em equipamentos industriais, médicos e outros equipamentos especializados. Eles também são conhecidos por fazer uso da biblioteca Log4j.
• Os usuários finais de soluções com o Log4j embutidos, se não souberem que o software contém uma vulnerabilidade, podem adiar a atualização.
• Os desenvolvedores de soluções que usam a biblioteca Log4j podem ter falido há muito tempo, saído do mercado ou retirado o suporte para seus programas. Mesmo que os usuários finais desejem atualizar, essa opção pode não estar mais disponível, enquanto mudar para outro software pode não ser tão fácil.
• Log4j é uma biblioteca de código aberto, o que significa que os programadores podem copiá-la, modificá-la e usá-la em seus projetos. Infelizmente, nem todos os desenvolvedores aderem estritamente às regras de licenciamento e nem sempre indicam a autoria do código. Então, em teoria, a mesma vulnerabilidade pode ser encontrada em um projeto de terceiros em que oficialmente não há Log4j.
• O Log4Shell era uma vulnerabilidade de zero-day, o que significa que os cibercriminosos o exploraram antes que as informações sobre o ataque fossem publicadas. Há evidências que sugerem que os invasores ficaram anônimos ao menos nove dias antes de se tornarem públicos.
• Entre os programas afetados estavam os produtos VMware, em particular a popular solução de infraestrutura de desktop virtual VMware Horizon. Muitos ataques registrados penetraram no sistema por meio desse mesmo software.
• As atualizações do programa terão pouco efeito caso os invasores já estejam dentro do sistema. De forma alguma todos os ataques começam imediatamente após a penetração, e é bem possível que muitos sistemas contenham backdoors até hoje. 

Danos atuais

Para ser justo, devemos observar que até agora nenhuma consequência catastrófica da exploração do Log4Shell foi registrada – ou, pelo menos, nenhuma que o público em geral tenha conhecimento. Mesmo assim, a vulnerabilidade causou uma grande dor de cabeça para desenvolvedores e especialistas em segurança, incluindo o cancelamento de férias de fim de ano para milhares de funcionários de TI em todo o mundo. As empresas que levam a sério a segurança (tanto deles quanto de seus clientes) tiveram que desembolsar somas consideráveis ​​para localizar a vulnerabilidade em seus sistemas e software e eliminá-la.

A seguir, destacamos alguns dos incidentes Log4Shell mais ​​conhecidos:

• Em 20 de dezembro de 2021, o Ministério da Defesa belga confirmou um ataque à sua infraestrutura que utilizou a vulnerabilidade. Compreensivelmente, os detalhes não foram divulgados.
• Em 29 de dezembro de 2021, relatos da mídia disseram que uma determinada instituição científica nos Estados Unidos havia sido atacada por meio do Log4Shell. De acordo com a CrowdStrike, o grupo APT, Aquatic Panda, explorou um VMware Horizon sem patch. A atividade suspeita foi interrompida a tempo, mas o próprio incidente indica que grupos de hackers sérios adotaram a vulnerabilidade.
• Também em dezembro de 2021, surgiram notícias sobre uma exploração do Log4Shell nos servidores do Minecraft: Java Edition, não hospedado pelo editor do jogo (Microsoft). A empresa confirmou o relato e chamou a atenção para a simplicidade da implementação do ataque: os cibercriminosos transmitiram códigos maliciosos em um chat normal do jogo, o suficiente para rodar tanto no lado do servidor quanto no cliente vulnerável. Este caso interessa menos do ponto de vista das vítimas e mais em termos de implementação técnica. Sob certas condições, um ataque pode ser realizado simplesmente por meio de um chat interno. Isso é preocupante, pois os chats agora vão muito além do mundo dos jogos. Para muitas empresas, eles são o método preferido de comunicação com os clientes. Em muitas fintechs e outras aplicações, é assim que o suporte ao cliente é fornecido.
• Em junho de 2022, a Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) e o Comando Cibernético da Guarda Costeira dos EUA (CGCYBER) emitiram um alerta de que a vulnerabilidade ainda estava sendo explorada ativamente. O comunicado afirmou que os cibercriminosos usaram uma brecha no mesmo VMware Horizon para penetrar nas redes internas de duas agências governamentais não identificadas. Além disso, os invasores teriam obtido acesso a 130 GB de dados confidenciais relacionados aos serviços prestados pelas instituições.
• Em novembro de 2022, a CISA, em conjunto com o FBI, emitiu outro alerta sobre um ataque Log4Shell a mais uma agência governamental. Os invasores penetraram no sistema em fevereiro, foram detectados em abril e permaneceram ativos de junho a julho. Durante esse período, eles criaram uma conta com privilégios de administrador, alteraram a senha de um administrador legítimo e carregaram o software de mineração no servidor. Acredita-se que o ataque seja obra de hackers patrocinados pelo governo iraniano, então alguns especialistas consideram a mineração apenas uma cortina de fumaça para esconder seus verdadeiros motivos.

Como proteger sua infraestrutura

Qualquer empresa pode ser vítima do Log4Shell, muitas vezes simplesmente por não conhecer vulnerabilidades em seus sistemas e software. Se você não tiver certeza se seus sistemas, ferramentas, produtos ou serviços usam a biblioteca Log4j, faz sentido conduzir uma [security assessment services placeholder]auditoria completa de segurança[/security assessment services placeholder]. Fora isso, para se manter seguro, siga estas dicas de nossos especialistas.

• Se o Log4j estiver presente em seu software, use a versão mais recente da biblioteca disponível na página do projeto.
• Leia o guia oficial do Apache Logging Services e siga-o quando necessário.
• Se o Log4j foi usado em produtos de terceiros, atualize todos os softwares vulneráveis.
• Use [KESB placeholder] soluções de segurança[/KESB placeholder] capazes de detectar tentativas de explorar vulnerabilidades em servidores e estações de trabalho.
• Monitore atividades suspeitas dentro do perímetro corporativo usando soluções de classe EDR ou serviços externos como o gerenciador de detecção e resposta. Isso permitirá que você encontre e mitigue ataques nos estágios iniciais.