A descoberta de uma vulnerabilidade crítica na biblioteca Log4j tem movimentado a vida de quem trabalha com desenvolvimento de software. A descoberta dessa falha de segurança também tem causado preocupação a diversas empresas e órgãos públicos.
O que exatamente significa Log4j?
O Log4j é uma biblioteca open source que faz parte do Apache Logging Services Project, mantida pela Apache Software Foundation. Essa biblioteca é amplamente utilizada em aplicações Java para fazer o processo de logging, que consiste em registrar dados dos envios de informações, processamentos, interações, resultados de operações ou outros dados da aplicação. Esses logs armazenados são usados geralmente para análises e monitoramento de alterações, inclusões, exclusões, erros e outras ações.
A falha de segurança ocorre pois permite que aplicativos registrem internamente uma string específica. Quando os logs são processados, essa string pode forçar o sistema a executar um script malicioso, permitindo que atacantes obtenham controle total, roubando dados, instalando malwares e realizando todo tipo de dano possível.
Como essa string se torna “o vilão”?
De maneira geral, o erro ocorre pois, ao incluir uma linha de código no log, utiliza-se algumas informações personalizadas, que normalmente estão armazenadas em variáveis.
O conteúdo dessas variáveis são concatenados numa string para serem inseridos no log através de recurso de interpolação, sendo identificados com uso de caracteres especiais (por exemplo, $$ {ctx: loginName}). Com isso, descobriu-se que, ao tentar inserir código malicioso num campo como esse que será concatenado, poderiam causar comportamentos indevidos nos servidores e aplicações, executando código remotamente.
Desde a descoberta da falha, a Fundação Apache já lançou diversas atualizações na tentativa de resolver o problema de vulnerabilidade. Essas atualizações atuam na JNDI (Java Naming and Directory Interface), que é uma API utilizada em aplicações que acessam recursos externos, permitindo que elas descubram e obtenham dados ou recursos através do nome. Na primeira atualização liberada do Log4J, a 2.15.0, apenas um aspecto da funcionalidade de recuperação de mensagem do JNDI foi desabilitado.
Na atualização 2.16.0, todo o suporte JNDI foi removido. Na atualização mais recente, a 2.17.0, novas proteções foram incluídas. A relação completa de correções pode ser vista diretamente na página de segurança da Apache. Lá também tem o link para o código da CVE, que é a Common Vulnerabilites and Exposures , uma iniciativa colaborativa de organizações e empresas de tecnologia para facilitar o acesso e compartilhamento de informações referentes a vulnerabilidades e exposições de segurança.
É difícil avaliar o impacto dessa vulnerabilidade, pois o Log4j é uma das bibliotecas de logging mais populares que existe, sendo usada em aplicações desenvolvidas em todas as linguagens e frameworks que rodam em uma JVM (Java Virtual Machine), como Java, Scala, Clojure, Spring e tantos outros. Mesmo que a aplicação não seja desenvolvida em Java ou alguma dessas linguagens, no contexto de um projeto arquitetural de software, é muito provável que algum dos outros serviços utilizados faça uso da biblioteca, o que pode acabar afetando a aplicação principal.
A recomendação é que se faça a atualização para a versão mais recente o quanto antes. As aplicações e serviços que usam versões inferiores à 2.15.0 da biblioteca continuam expostas à falha. Além disso, vale salientar a importância de realizar o máximo de testes de segurança possíveis na aplicação, para evitar ataques indesejados e prejuízos.
Para entender mais sobre vulnerabilidade e segurança, confira esses conteúdos que separamos para você!
Episódio 284 do Podcast Hipsters Ponto Tech sobre Log4j, bugs e segurança
Vídeo Ataques Hacker, vulnerabilidade, segurança de dados - SI
Curso de Segurança web em Java: Evitando SQL Injection, força bruta e outros ataques
Curso de Segurança web em Java parte 2: XSS, Mass Assignment e Upload de arquivos
O podcast você já pode ouvir direto aqui:
spotify:17EzlmHBsVuPeVPRTvVJNx:episode
