Há risco de um worm explorar a falha do Log4j?

Na opinião do chefe de estratégia de segurança cibernética da VMware, Tom Kellermann, a possibilidade de exploração da vulnerabilidade do Log4j usando um worm é o pior cenário para a cibersegurança nesse início de ano. “Um dos mais importantes [worms] do início dos anos 2000 foi o Code Red “, disse Kellermann à ZDNet . “Não vimos um impacto global generalizado como esse desde então.”

A possibilidade de um worm gerou conversas significativas na comunidade de segurança cibernética.  Na opinião do especialista em segurança cibernética Marcus Hutchins tais temores são exagerados porque “um worm precisaria de uma nova técnica de exploração para obter qualquer valor real sobre a vulnerabilidade. Em primeiro lugar, já existe uma exploração em massa (você pode espalhar a Internet inteira de um servidor). Em segundo lugar, os worms levam tempo e habilidade para se desenvolver, mas a maioria dos invasores está correndo contra o relógio (patching e outros invasores)”, escreveu Hutchins no Twitter. 

Já o CTO da BreachQuest, Jake Williams, acredita que embora alguém possa criar um worm que explore o Log4Shell, é improvável que seja como o WannaCry, NotPetya ou worms anteriores que exploram processos ao nível de sistema. 

Os ataques baseados na falha do Log4j continuam e especialistas em segurança cibernética alertam não haver fim à vista.Indícios recentes sugerem que os invasores estão tentando explorar a vulnerabilidade para expor as chaves usadas pelas contas do Amazon Web Service. Também há sinais de invasores tentando explorar a vulnerabilidade para instalar ferramentas de acesso remoto nas redes das vítimas, possivelmente Cobalt Strike, uma chave ferramenta em muitos ataques de ransomware.

Há centenas de software e produtos de rede que permanecem vulneráveis e nem todos já contam com correções ou alternativas. “Não vimos uma redução significativa nas tentativas de exploração desde o pico em 1 de dezembro, e essas sondagens e explorações vêm de uma infraestrutura distribuída globalmente”, disse Sean Gallagher, da Sophos. Na terça-feira, 21 de dezembro, a empresa revelou que a maioria dos ataques tem partido da China e da Rússia. Apenas um domínio, associado a uma organização de mineração de criptomoeda russa, foi responsável por 11% dos ataques registrados até o momento. Ainda há uma superfície de ataque extraordinariamente grande disponível e os especialistas se preocupam com o tempo que as organizações levarão para responder ao maior dos problemas de cibersegurança em anos.

Profissionais de DevSecOps se perguntam se este é finalmente o tão esperado momento divisor de águas da segurança cibernética. Talvez. Afinal, todo esse pânico com a segurança cibernética está perto de se tornar uma tradição anual. Em dezembro passado, começaram a surgir relatórios sobre outra crise de segurança maciça com a violação SolarWinds, que permanece um vetor de ataque. Antes disso, em janeiro de 2018, outro problema de cibersegurança de longo alcance ganhou as manchetes com as vulnerabilidades Meltdown e Spectre.

Mas, até aqui, o que temos visto são as empresas com dificuldades para compreender a urgência do DevSecOps.

Para piorar as coisas, algumas empresas – incluindo alguns grandes fornecedores de software de TI – ainda estão investigando se a versão vulnerável da biblioteca existe em seus produtos. Um filme que já vimos antes. Um relatório post-mortem detalhado sobre a violação de dados Equifax, em 2017, apontou para um cenário semelhante ao de agora, em que as equipes de TI do departamento de crédito procuraram em seus sistemas outra vulnerabilidade Java e não conseguiram encontrá-la antes dos invasores.

E não só os fornecedores de produtos e serviços de TI precisam se preocupar. A FDA alertou haver “exploração ampla e ativa” da vulnerabilidade do Log4j em várias indústrias, mas disse que não tem conhecimento de nenhum evento adverso confirmado que afete os dispositivos médicos. “Os fabricantes devem avaliar se são afetados pela vulnerabilidade, avaliar o risco e desenvolver ações de remediação”, disse a FDA. “Como este é um problema contínuo e em evolução, também recomendamos vigilância e resposta contínuas para garantir que os dispositivos médicos sejam devidamente protegidos.” O desafio agora é para hospitais e fabricantes de dispositivos lutando para avaliar o impacto da vulnerabilidade do Log4j em seus respectivos inventários de dispositivos. 

Para auxiliar as equipes de segurança de fornecedores e usuários, a US Cybersecurity and Infrastucture Agency lançou uma ferramenta de varredura de código aberto para ajudar empresas e agências a encontrar instâncias Log4j em seus sistemas. E a Apache Software Foundation tem sido incansável na busca de soluções. A atualização Log4j 2.17.0 é a terceira desde que o Log4Shell foi divulgado e a exploração em massa começou. As versões 2.15.0 e 2.16.0 corrigiram bugs de execução remota de código. Ela corrige uma nova vulnerabilidade relatada na semana passada que permite ataques de negação de serviço contra instâncias vulneráveis ​​da estrutura de registro Java. 

A melhor resposta é perfeitamente clara: corrigir ou mitigar seus próprios sistemas agora.