Nota: O seguinte artigo irá ajudá-lo com: Ainda por aí, ainda perigoso e como proteger seus sistemas
Os pesquisadores do Barracuda notaram um fluxo constante de ataques tentando explorar a vulnerabilidade do Log4j desde que foi encontrada. O interessante é onde a maioria dos ataques se origina.
O Log4Shell, um exploit direcionado à biblioteca Apache Log4j comumente usada, não mostrou nenhum sinal de desaceleração como um alvo popular para hackers desde sua descoberta em dezembro, disseram pesquisadores da Barracuda Networks.
O Log4Shell é tão crítico quanto uma vulnerabilidade crítica pode ser. Ele marcou 10 de 10 na escala de gravidade do Instituto Nacional de Padrões e Tecnologia, e por um bom motivo: ele tem como alvo uma biblioteca que quase todos os aplicativos Java usam para registrar solicitações, e tudo o que é necessário para acioná-lo é uma string maliciosa do invasor .
VEJO: Google Chrome: dicas de segurança e interface do usuário que você precisa saber (TechRepublic Premium)
Desde sua descoberta em dezembro, disse Tushar Richabadas, gerente sênior de marketing de produtos da Barracuda para aplicativos e segurança na nuvem, “o volume de ataques que tentam explorar essas vulnerabilidades permaneceu relativamente constante, com algumas quedas e picos nos últimos dois meses”.
Aqui está a coisa estranha: 83% dos ataques que tentaram o exploit Log4Shell se originaram nos Estados Unidos.
A anatomia dos ataques Log4Shell
A Barracuda disse que extraiu dados de ataques que datam de 10 de dezembro de 2021, para obter uma visão completa de como o Log4Shell foi usado desde sua descoberta. Como mencionado acima, os pesquisadores encontraram alguns dados interessantes ao analisar os IPs dos invasores: a maioria vem dos EUA, enquanto o restante vem do Japão (10%), Alemanha e Holanda (3%) e Rússia (1%).
Richabadas observou que um ataque originado de um determinado IP não significa que o invasor esteja geograficamente localizado nesse local, especialmente porque a Barracuda descobriu que metade dos ataques originários dos EUA vieram da AWS, Azure e outros data centers em nuvem.
“Os serviços em nuvem apenas fornecem acesso fácil a IPs efêmeros que têm uma boa reputação e provavelmente não serão bloqueados geograficamente ou por reputação”, disse Richabadas. Além disso, ele observou que as cargas úteis reais provavelmente foram entregues de outros sites comprometidos ou servidores privados virtuais. Esses IPs geralmente são codificados em Base64 para ofuscá-los ainda mais, dificultando a determinação de onde a carga útil se origina.
Em termos do que os invasores estão fazendo depois de conseguirem usar com sucesso a exploração Log4Shell, Barracuda destacou quatro exemplos: uma brincadeira relativamente inofensiva, malware de mineração de criptografia, malware DDoS e malware direcionado a VMware.
A primeira é, dependendo de como você olha para isso, um truque bastante benigno, mas informativo: ele Rick-Rolls os usuários quando um determinado conjunto de condições é atendido. Ao contrário desse “ataque”, que poderia realmente ser considerado útil do ponto de vista de “obrigado por nos avisar”, os outros que Barracuda descreve são decididamente menos “úteis”.
VEJO: Violação de senha: por que cultura pop e senhas não se misturam (PDF grátis) (TechRepublic)
O malware de criptomineração Monero foi encontrado, assim como o malware que visa instalações VMware, inicia ataques DDoS e instala uma variedade de malware de botnet, sendo o mais comum o dispositivo IoT direcionado ao botnet Mirai.
Os tipos de ataques também podem fornecer uma pista sobre o que está por vir no futuro próximo da segurança cibernética, disse Richabadas. “A prevalência do malware DDoS botnet parece sugerir que os agentes de ameaças estão trabalhando para construir uma grande botnet para uso futuro, e deve haver uma expectativa de grandes ataques DDoS no futuro próximo.”
Proteger-se do Log4Shell é simples, realmente
Há uma correção simples que pode remover completamente esse risco de seu cálculo de segurança cibernética: patch para a versão mais recente do Log4j, que resolve o problema.
Isso nem sempre é possível em ambientes de produção, portanto, se você não conseguir corrigir agora, há etapas que você pode executar para determinar se seus sistemas são vulneráveis ao Log4Shell, bem como diferentes coisas que podem ser feitas para minimizar sua exposição ao Log4Shell… até que você possa realmente instalar o patch, que deve ser seu objetivo final.
