A vulnerabilidade Log4j e seu impacto na segurança da cadeia de suprimentos de software

Nota do editor (28 de dezembro de 2021, às 19h35 GMT): A equipe do Log4j lançou uma nova atualização de segurança que identificou a versão 2.17.0 como vulnerável à execução remota de código, registrada como CVE-2021-44832. Recomendamos atualizar para a versão mais recente, que no momento é a 2.17.1. Saiba mais aqui.

Nota do editor (18 de dezembro de 2021, às 18h55 GMT): A situação do Log4j está mudando rapidamente, e estamos atualizando nossos artigos à medida que novas informações são disponibilizadas. Recomendamos atualizar para a versão 2.17.1 ou posterior. Essa versão contém correções de segurança para duas vulnerabilidades de execução remota de código, corrigidas nas versões 2.15.0 (CVE-2021-44228) e 2.16.0 (CVE-2021-45046), além da vulnerabilidade de DoS mais recente, corrigida na versão 2.17.1 (CVE-2021-45105). Saiba mais aqui.

A esta altura, você já conhece — e provavelmente está em processo de corrigir — a vulnerabilidade conhecida como Log4Shell, registrada como CVE-2021-44228. Pesquisadores de segurança divulgaram essa vulnerabilidade na sexta-feira (10 de dezembro de 2021), no framework de logging Log4j do Apache.

Neste artigo, vamos apresentar alguns fatos importantes sobre o Log4j e ações que você pode tomar para proteger a si mesmo e sua empresa:

• O Log4j é uma vulnerabilidade crítica que exige ação urgente

• O Log4j é amplamente usado e terá um enorme impacto

• O Log4j tem um impacto significativo na segurança da cadeia de suprimentos e será difícil de corrigir

• É fundamental priorizar a correção de segurança do Log4j em meio a uma lista de pendências de segurança já extensa

• Responder rapidamente a problemas críticos como o Log4j é essencial para os negócios

O Log4j é uma vulnerabilidade crítica que exige ação urgente

Não dá para enfatizar o suficiente a importância dessa vulnerabilidade do Log4j. Trata-se de uma vulnerabilidade crítica de segurança, com pontuação CVSS 10 (a mais alta possível), que permite que invasores executem código remotamente em qualquer ambiente vulnerável. É um problema grave que exige ação urgente para ser corrigido.

Leia as seções abaixo para saber quais ações imediatas você deve tomar, de acordo com as versões do Log4j que está usando em suas aplicações.

Estou usando o Log4j v1. O que devo fazer?

O risco aqui é muito menor em comparação com a vulnerabilidade que afeta a versão 2.x. No entanto, em circunstâncias muito específicas, o Log4j v1 permite pesquisas (lookups), semelhantes às que vimos afetar o log4j2, que não protegem contra LDAP ou outros endpoints resolvidos via JNDI. Esses vetores de ataque (e possivelmente outros) podem levar a ataques de execução remota de código (RCE). Se você usa uma versão do Log4j v1 com o JMSAppender ativado, pode estar vulnerável. Vale lembrar que o JMSAppender vem desativado por padrão e, por isso, provavelmente não está ativado na maioria das instâncias do Log4j v1 usadas em aplicações.

Essa é uma atualização crítica e recente, lançada há pouco (13 de dezembro de 2021, por volta das 17h UTC) e identificada pela Snyk pelo ID de vulnerabilidade SNYK-JAVA-LOG4J-2316893.

Por isso, recomendamos que, se possível, você atualize para a versão mais recente do Log4j v2, que inclui a correção para a vulnerabilidade recém-descoberta. Consulte o documento oficial do Apache sobre a migração do Log4j v1. Se não for possível fazer a atualização, desative o JMSAppender ou impeça que qualquer entrada do usuário chegue à configuração dele.

Estou usando o Log4j v2. O que devo fazer?

Se você usa o Log4j versão 2.x, atualize para a versão mais recente do Log4j v2 (atualmente, a 2.16.0), que corrige a vulnerabilidade.

Estou usando o Log4j v1 ou v2, mas não consigo atualizar rapidamente. Existe uma solução temporária imediata?

Se não for possível atualizar em curto prazo, leia nosso artigo sobre o Log4j, que explica como corrigir a vulnerabilidade definindo propriedades do sistema e parâmetros do Java.

O Log4j é amplamente usado e terá um enorme impacto

O logging é comum

Ao desenvolver aplicações, os desenvolvedores quase sempre registram dados em logs para ter informações úteis para depuração, análise e auditoria. Além de serem úteis nas atividades cotidianas de desenvolvimento, os logs também são exigidos por muitas equipes de segurança para criar trilhas de auditoria que ajudem a rastrear e correlacionar possíveis atividades suspeitas.

O logging é uma prática essencial no desenvolvimento

O fato de o logging ser tão onipresente e de a vulnerabilidade do Log4j poder ser acionada pelo registro de entradas de usuários aumenta muito a gravidade do ataque e amplia os possíveis vetores. Por exemplo, usuários começaram a usar publicamente, nas redes sociais, payloads de exploração do Log4j como endereços de e-mail e nomes de usuário em formulários da web.

Ainda vai demorar para conhecermos todo o impacto da vulnerabilidade do Log4j. Mas, desde que ela foi divulgada, já houve relatos de centenas de tentativas de explorar essa vulnerabilidade em ambientes reais, tanto em ataques aparentemente oportunistas quanto em botnets mais sofisticadas.

A biblioteca open source Log4j é amplamente usada

Como você pode imaginar pela repercussão dessa vulnerabilidade, o Log4j é muito usado por fornecedores, projetos open source, frameworks e projetos de alto nível de fundações.

Além dos milhões de aplicações Java que usam Log4j, muitos projetos da própria Apache Software Foundation também utilizam a biblioteca, como Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift e outros.

A biblioteca também é amplamente usada em muitos outros projetos populares, como Redis, Elasticsearch, Spring Framework, Netty e outros.

Até mesmo o Ghidra, ferramenta de engenharia reversa da Agência de Segurança Nacional dos EUA (NSA), disponibilizada ao público como projeto open source, foi identificado como vulnerável a esse problema de segurança do Log4j.

Fornecedores também foram bastante afetados por essa vulnerabilidade. Entre eles estão serviços da própria AWS, como AWS CloudHSM e Amazon OpenSearch, além de outros produtos de serviço possivelmente afetados. O problema também atinge produtos da Red Hat, como Red Hat JBoss Fuse 7, Red Hat CodeReady Studio 12, Red Hat OpenShift Logging e outros. Como você pode imaginar, muitos outros fornecedores, como VMware, Cisco e outros, também foram bastante afetados.

Também constatamos um impacto significativo entre os próprios usuários da Snyk. Cerca de um terço dos clientes da Snyk foi afetado pela vulnerabilidade do Log4j, que representa dezenas de milhares de vulnerabilidades detectadas em projetos importados ou monitorados pela Snyk.

A crise envolvendo a biblioteca Java open source Log4j, fornecida por terceiros, reforça ainda mais a necessidade de acompanhar a lista de materiais de software (SBOM) em toda a organização e integrar uma ferramenta de análise de composição de software que permita às equipes de desenvolvimento e segurança responder rapidamente.

O Log4j tem um impacto significativo na segurança da cadeia de suprimentos e será difícil de corrigir

Com base nos dados de projetos importados, monitorados e analisados pela Snyk, conseguimos compreender a fundo os padrões de uso da biblioteca Log4j nos projetos.

Até o momento, descobrimos que 60% dos projetos Java que monitoramos na Snyk e que usam a biblioteca Log4j a utilizam como dependência indireta. Dependências indiretas são aquelas usadas indiretamente por um projeto (ou seja, uma das dependências do seu projeto usa Log4j, o que deixa você vulnerável mesmo sem usar Log4j diretamente). Isso significa que uma busca simples para verificar se você está usando uma versão vulnerável do Log4j talvez não encontre todas as ocorrências da biblioteca nos seus projetos. Você precisará de uma ferramenta de análise de composição de software (SCA), como a Snyk, para percorrer recursivamente um grafo de dependências profundamente aninhado e correlacionar versões com um banco de dados de vulnerabilidades, identificando os riscos à segurança da cadeia de suprimentos.

Na verdade, no Relatório sobre o estado da segurança do open source de 2020 da Snyk, descobrimos — e confirmamos — que a maioria das vulnerabilidades tem origem em dependências indiretas nos ecossistemas Java, Ruby e JavaScript:

Esse é um dos muitos motivos pelos quais, como desenvolvedor, você precisa usar ferramentas de segurança como a Snyk para ajudar a identificar vulnerabilidades nos seus projetos, como log4j. Saber apenas se você está usando uma dependência vulnerável não basta: também é preciso verificar recursivamente se as dependências dela são vulneráveis.

Em resumo, corrigir a nova vulnerabilidade do Log4j será complicado, pois muitas bibliotecas open source precisarão ser atualizadas para resolver o problema e garantir que os projetos que dependem delas não continuem vulneráveis. E isso vai levar algum tempo.

A vulnerabilidade do Log4j representa uma ameaça global iminente. Assim como a pandemia de COVID-19 nos afetou e exigiu a colaboração de organizações de saúde e empresas de pesquisa médica do mundo todo, vemos uma colaboração semelhante acontecendo agora — e ela é essencial para enfrentar os riscos gerais decorrentes da vulnerabilidade do Log4j e encontrar uma solução abrangente para a comunidade.

É fundamental priorizar a correção de segurança do Log4j em meio a uma lista de pendências de segurança já extensa

Para muita gente, a vulnerabilidade do Log4j é mais um problema urgente de segurança a ser resolvido em meio a uma lista já extensa de pendências relacionadas à dívida de segurança.

Com o aumento das vulnerabilidades de segurança em diferentes ecossistemas de linguagens, além de configurações incorretas, componentes open source de sistemas operacionais e outras preocupações com a segurança de aplicações, por onde as equipes de segurança devem começar? Qual é a vulnerabilidade mais importante e urgente a ser tratada quando a equipe já está sobrecarregada?

A priorização é essencial não apenas para que as equipes de segurança trabalhem com eficiência, mas também para reduzir o risco geral para os negócios. Para serem eficazes, essas equipes precisam entender os riscos das vulnerabilidades de segurança não só em um projeto, mas em toda a organização.

Para ajudar desenvolvedores e equipes de segurança a responder rapidamente e avaliar os riscos de segurança considerando toda a organização, introduzimos o conceito de pontuações de prioridade na Snyk.

As práticas tradicionais de segurança se baseavam no fator CVSS de uma vulnerabilidade, que geralmente não considerava o contexto. A pontuação de prioridade da Snyk leva em conta informações contextuais sobre a vulnerabilidade, como o nível de maturidade da exploração, tendências nas redes sociais, a pontuação de gravidade CVE atribuída, a disponibilidade de uma correção e se a vulnerabilidade foi divulgada recentemente.

Nossa pontuação de prioridade vai de 0, a menor possível, a 1000, a maior possível, e destaca as vulnerabilidades de segurança mais urgentes que uma empresa precisa resolver. A vulnerabilidade de segurança do Log4j é um exemplo perfeito de como essa pontuação permite que as equipes priorizem a correção corretamente. A imagem abaixo, do painel da Snyk, mostra como, em alguns casos, a CVE específica do Log4j recebeu a pontuação máxima de 1000, em meio a milhares de vulnerabilidades que uma organização precisa tratar em centenas de projetos, abrangendo diferentes ecossistemas e linguagens de programação:

Guy Podjarny (fundador e presidente da Snyk) desenvolveu ainda mais esse conceito e explicou a diferença entre o que é importante e o que é urgente, além de como isso se aplica à priorização de segurança. Na verdade, ampliamos esse conceito para o desenvolvimento de aplicações cloud native, oferecendo às equipes mais insights com a priorização contextual nas implantações do Kubernetes.

Responder rapidamente a problemas críticos como o Log4j é essencial para os negócios

A vulnerabilidade do Log4j pressionou as equipes de resposta a incidentes a identificar as causas raiz e começar a analisar — e corrigir — o inventário de aplicações Java implantadas.

Não há dúvida de que as equipes de resposta a incidentes precisaram agir rapidamente diante de vulnerabilidades críticas como a do Log4j. Mas essa responsabilidade também recai sobre desenvolvedores e equipes de segurança de aplicações, que cuidam da segurança das aplicações.

O DNA da Snyk é focado em uma segurança que prioriza os desenvolvedores e é fácil de usar para eles. Ajudar desenvolvedores e equipes de segurança a encontrar e corrigir vulnerabilidades com rapidez e facilidade não é apenas um dos nossos principais objetivos: é o que nos define.

Em meio ao caos de segurança causado pela vulnerabilidade do Log4j, ficamos felizes e honrados em ver outras pessoas tendo sucesso com a Snyk na correção da vulnerabilidade:

Não se trata apenas de corrigir vulnerabilidades de forma proativa e automática para os desenvolvedores, mas também de considerar os problemas de segurança em todos os seus repositórios de código-fonte — inclusive aqueles projetos legados antigos e esquecidos:

Próximas etapas para corrigir o Log4Shell

Há uma luz no fim desse túnel — basta dar alguns passos em direção a ela!

A Snyk pode ajudar de várias maneiras: desde entender o nível de exposição em suas diferentes aplicações e realizar testes desde o início e ao longo do SDLC até acionar pull requests de correção automatizados para corrigir rapidamente as vulnerabilidades identificadas.

Recomendamos muito que você leia nossas orientações sobre como encontrar e corrigir rapidamente o Log4Shell com a Snyk para receber conselhos práticos sobre como corrigir vulnerabilidades relacionadas ao Log4j em seus projetos. Se ainda não fez isso, crie sua conta gratuita na Snyk!

Como os acontecimentos ainda estão se desenrolando, é sempre bom acompanhar as notícias. Continuaremos publicando atualizações em nossa newsletter e neste blog. Fique de olho!

E, para terminar com uma nota mais leve, pelo menos essa vulnerabilidade crítica rendeu algumas risadas familiares. A tirinha XKCD “Little Bobby Tables” vem à mente (com algumas modificações recentes, como foi originalmente compartilhado nas redes sociais):