Log4j: como funciona o bug que faz a internet tremer

Notícias do bug Log4j começaram a circular na Internet já em 9 de dezembro, inicialmente como uma vulnerabilidade dos servidores do Minecraft. Em pouco tempo, porém, percebemos o poder do bug e a extensão da propagação que fazia com que o nível de risco subisse para 10 (em uma escala de 1 a 10). Na verdade, a biblioteca Java Log4j está amplamente difundida em muitas plataformas e servidores da web em todo o mundo.

Provavelmente depois de Heartbleed e ShellShock, pode ser a vulnerabilidade mais perigosa atualmente presente, tanto que a própria Apache Software Foundation tentou remediá-la lançando um patch que pode resolver o problema. A vulnerabilidade conhecida como CVE-2021-44228 afeta a versão 2 da biblioteca e foi corrigida com a versão 2.15.0 .

O que é Log4j e onde ele é usado

Log4j é uma das bibliotecas de registro mais usadas em Java e é extremamente útil e difundida. Na origem da vulnerabilidade, há um recurso introduzido no Log4j em 2013: o plug-in de pesquisa JNDI. Antes de entender como o bug funciona, é necessário dar um passo atrás e analisar o propósito da biblioteca e do JNDI. Java Naming and Directory Interface está presente no Java desde os anos 90 e é um serviço que permite encontrar dados (objetos Java) através da estrutura de pastas. Os serviços de diretório podem variar de CORBA COS (Common Object Service) a Java RMI (Remote Method Interface) Registry até LDAP, o serviço usado no CVE.

O poder desse bug está no fato de que também pode ser explorado por sistemas não expostos diretamente à Internet. Na verdade, algumas informações (como o User-Agent ou o nome de usuário) normalmente também são registradas nos sistemas de back-end que podem ser gravados em Java. Se você conseguir obter esses dados corrompidos do front-end para o back-end, poderá assumir o controle dos sistemas com relativa facilidade.

Log4j: como funciona o bug

O serviço de pesquisa JDNI LDAP permite que você recupere objetos por meio de URLs do tipo ldap: // localhost: 389 / o = JavaObject . No entanto, também é possível passar estruturas do tipo $ {prefixo: nome} e realizar uma consulta JDNI em qualquer servidor da Internet contido em nome . A partir daqui entendemos o tipo de vulnerabilidade, classificada como Remote Code Execution (RCE). Na verdade, passando esse campo corretamente, é possível carregar um objeto Java de um servidor sob o controle dos invasores .

Provas de Conceitos (POC) já estão disponíveis na web e há muitas reportagens relatando campanhas massivas de varredura em busca dessa vulnerabilidade.

Impactos e possíveis soluções

O impacto desse ataque é enorme, para dizer o mínimo, considerando a disseminação do Java no mundo e entre as empresas. Muitos estão correndo para se proteger com grandes campanhas de patching em seus servidores. Na verdade, as versões do Log4j desde 2.10 podem ser facilmente corrigidas definindo a propriedade do sistema log4j2.formatMsgNoLookups ou a variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS como true .

Sempre que possível, também é possível atualizar a biblioteca para a versão 2.15.0 que resolve definitivamente o problema e protege os aplicativos. Em vez disso, as versões de 2.0 a 2.10 precisam remover a classe JndiLookup para serem seguras.

Alguns pesquisadores relatam que a resolução dessa vulnerabilidade pode durar meses, senão anos, devido à enorme popularidade da biblioteca. Obviamente, sua melhor aposta é seguir as instruções da Apache Software Foundation o mais rápido possível e certificar-se de que seus sistemas estão atualizados.

Artigo Log4j: Como funciona o bug que agita a Internet vem do Tech CuE | Engenharia de close-up .