Hoje eu vou contar pra vocês sobre o caso do Log4J para explicar sobre as vulnerabilidades que podem acontecer no uso de bibliotecas terceiras dentro de um projeto. Esse caso, que aconteceu no ano passado, ficou super famoso. Eu vou deixar algumas matérias linkadas no final falando sobre o caso.
O Java é uma linguagem super conhecida e utilizada no mundo inteiro por diversas empresas, e ele possui uma ferramenta de log [registro de atividades] chamada Log4J, que é usada, segundo o Google, por mais de 35mil aplicações. O Log4J é mantido pela Apache Foundation, uma das maiores organizações de sistemas open source do mundo, que é extremamente reconhecida e tem centenas de milhares de desenvolvedores no mundo inteiro que colaboram com os projetos. Eu dei uma olhada rápida no GitHub do Log4J, eu vi que o projeto tem mais de 140 desenvolvedores contribuintes, e tem mais de 3 mil stars [o equivalente a uma curtida ou favoritada dentro do GitHub].
Mas o que é que aconteceu com o Log4J? Em 2021, uma empresa de auditoria de softwares detectou uma vulnerabilidade dentro do jogo Minecraft. Pra quem não sabe, o Minecraft é escrito em Java e utiliza o Log4J pra poder fazer o controle de logs. Pra vocês entenderem o nível de problema, essa falha no Log4J dava a possibilidade de, através de um texto inputado dentro do jogo, o invasor tomar conta por completo da máquina que estava hospedando daquele sistema. O nome dado para essa técnica de invasão foi Log4Shell, já que utiliza o Log4J como uma backdoor para os sistemas. Mas não foi só no Minecraft que encontraram essa falha, ela estava em diversos sistemas, em várias empresas, inclusive na Microsoft e na Apple.
Olha o nível do problema: Uma falha numa biblioteca terceira de log, que é mantida por uma empresa extremamente reconhecida, que é confiável, que passa por uma série de programadores no mundo inteiro analisando, que é utilizada em mais de 35 mil aplicações, ainda assim passou pela vista de todo mundo esse problema e afetou as maiores empresas do mundo. Outra empresa que usa o Java é o próprio Google, o Android é feito em Java, então olha o nível de problema que essa vulnerabilidade causa. E essa vulnerabilidade do Log4J justamente entra naquela categoria de vulnerabilidades de uso de bibliotecas terceiras que eu comentei no meu último post que eu fiz, analisando o relatório do Ministério da Defesa, eu vou deixar o link aqui:
Mesmo sendo extremamente bem feitas, bibliotecas terceiras podem conter algum tipo de vulnerabilidade e precisam ser analisadas. No caso, vamos supor [e isso é só um exemplo] que o sistema analisado foi criado com Java, que é uma possibilidade, e usa o Log4J numa versão que tem essa vulnerabilidade, já tem claramente uma possibilidade de risco.
Por que eu trouxe esse caso da Log4J? Porque ele é o mais recente e teve um alto nível de impacto. O impacto foi tão grande que a Oracle, a mantenedora do Java, soltou uma nota de nível 5 de risco quando a falha foi descoberta. Geralmente a gente classifica o risco de segurança entre 1 a 5, sendo 1 um risco pequeno, que não é tão importante, mas precisa eventualmente ser analisado, até o nível 5, que é o risco mais grave de todos. Eu não me aprofundei muito no caso, mas pelo que eu li, era uma falha que podia ser explorada por uma linha de código, um único comando que tinha dentro da biblioteca, que dava acesso ao shell da máquina, que dava acesso ao controle da máquina. Então, perceba, com apenas uma linha de código você pode tornar um sistema inteiro vulnerável e nem propriamente foi você o responsável, é uma vulnerabilidade de uma biblioteca que teoricamente era pra ser super simples, uma biblioteca para criar arquivos .txt de log, e tem esse nível de periculosidade. Então é só para deixar claro o quanto que precisa ser ampla essa discussão.
No meu ponto de vista, quanto mais pessoas estiverem olhando para essa situação, melhor, porque riscos grandes existem. De novo, eu gosto de uma frase muito boa de um dos instrutores de Microsoft TechNet, que inclusive foi colocada também no relatório do Ministério da Defasa, que fala o seguinte: “nenhum sistema é 100% seguro”. Isso tem que ser uma premissa básica, isso é o que a gente aprende no curso de segurança da informação, nenhum sistema é infalível, nem o sistema da maior empresa do mundo, a Apple, que vale trilhões de dólares e investe bilhões de dólares em segurança, está 100% seguro. Então a gente precisa levar isso sempre em consideração.
Se você estiver gostando do conteúdo, compartilhe com seus amigos. A gente se vê numa próxima. Valeu!
Matérias falando sobre o caso:
https://www.tecmundo.com.br/seguranca/230972-Log4J-entenda-falha-seguranca-gravidade.htm
https://www.alura.com.br/artigos/Log4J-entenda-sobre-vulnerabilidade
https://canaltech.com.br/seguranca/apache-lanca-correcao-para-nova-falha-do-Log4J-205523/
Este post foi criado a partir do conteúdo do vídeo “Vulnerabilidade em bibliotecas terceiras, caso Log4J”:
