Polêmica das vulnerabilidades Log4Shell reacende uma velha discussão a respeito do nível de confiabilidade que as empresas podem depositar em softwares livres para desenvolver suas soluções comerciais; bugs e envenenamento de repositórios são comuns.
Enxergue-se no seguinte cenário: você decide morar em uma cidade de pequeno porte, cerceada por natureza, mas que possui seu próprio reservatório de água tratada da concessionária de saneamento estadual. Temos duas opções aqui — a primeira é contratar os serviços de tal concessionária, recebendo água tratada e devidamente armazenada de forma segura, mas obviamente pagando um preço por isso. A segunda opção é construir uma tubulação caseira até uma nascente próxima e ter água de graça diretamente da fonte.
Antes de explicarmos o que tal situação hipotética tem a ver com segurança da informação, vamos analisar os prós e os contras de cada uma das opções que fornecemos. Ao optar pela concessionária, você certamente teria maior segurança e tranquilidade de que estaria consumindo uma água de qualidade, devidamente tratada contra qualquer tipo de aditivos maléficos — mesmo que tenha que pagar por isso. Já canalizando a água direto da nascente, como você teria a garantia que esta não seria, por exemplo, envenenada?
Pois bem: esse drama é comum no cotidiano de quem opta por usar aplicações, APIs e bibliotecas de código aberto em seus projetos comerciais. A segurança do software livre sempre foi motivo para discussões acaloradas entre desenvolvedores e analistas de cibersegurança; porém, o recente escândalo do conjunto de vulnerabilidades Log4Shell, detectadas no célebre componente Log4j, acabou acendendo novamente os debates sobre uso seguro desse tipo de código para finalidades profissionais.
Uma biblioteca, milhões de vítimas
Antes de mais nada, vale a pena ressaltar que o objetivo deste artigo não é, de forma alguma, criticar ou condenar a comunidade open source, mas sim levantar algumas questões e cuidados que precisam ser observados de forma racional. Isto posto, é interessante retomarmos aqui o supracitado caso Log4Shell. Inicialmente uma única vulnerabilidade, ela foi identificada no finalzinho de 2021 na Log4j, famosa biblioteca de registro de logs para aplicações Java e mantida pela Fundação Apache.
Os pesquisadores responsáveis pela descoberta encontraram a falha no igualmente popular jogo “Minecraft: Java Edition”; porém, não demorou muito para que o caos fosse instaurado a nível internacional. Afinal, a Log4j é tão amplamente utilizada que muitos projetos estavam usando esse componente sem nem mesmo saber — e, consequentemente, seus servidores estavam vulneráveis a ataques de execução remota de código. Um invasor poderia fazer de tudo: desde lançar ataques de negação de serviço (DDoS) até infectar a máquina com um ransomware.
Ao longo do intervalo de duas a três semanas, mais vulnerabilidades similares foram sendo encontradas na Log4j e adicionadas ao pacote Log4Shell, causando pânico até mesmo em entidades governamentais. Embora boa parte do problema já tenha sido resolvido, o episódio nos faz lembrar que a descentralização e natureza “aberta” dos projetos open source os torna obviamente mais suscetíveis a brechas de segurança que podem desencadear ataques de cadeia de suprimentos. Ou seja, por conta do uso de um componente gratuito, todo o seu código e sistema corporativo se tornam vulneráveis.
Software envenenado
Os problemas vão além. No cenário hipotético, não usamos a palavra “envenenar” à toa. Ataques de envenenamento de projetos de código aberto são relativamente comuns, conforme confirmado por um estudo científico publicado em agosto de 2021 por especialistas da Universidade Cornell. Os pesquisadores contaram com o apoio da NSF International, da Schmidt Futures e até da Google através do programa Faculty Research Award.
Se levarmos em conta a facilidade de inserir códigos maliciosos em um repositório público ou até mesmo criar um repositório falso, basta um único commit para que uma versão maligna de uma biblioteca livre esteja disponível para dezenas, centenas ou milhares de aplicativos comerciais que a utilizam. Mesmo que a manobra seja identificada com “rapidez” pelos reais mantenedores do projeto, já pode ter sido tarde demais e muitas empresas possivelmente já estariam infectadas com a versão corrompida do software.
“Com muitas empresas e programadores usando modelos e bibliotecas de sites de código aberto na internet, esta pesquisa mostra o quão importante é revisar e verificar esses materiais antes de integrá-los ao seu sistema atual. Se os hackers forem capazes de implementar o envenenamento de código, eles poderão manipular modelos que automatizam as cadeias de suprimentos”, explica Eugene Bagdasaryan, coautor da pesquisa ao lado do professor Vitaly Shmatikov.
–
A Agility oferece uma solução completa de Proteção de Aplicações Multicloud (DevSecOps), saiba mais em: https://somosagility.com.br/xaas/protecao-de-aplicacoes-multicloud/