Correção para a falha Log4j não protege totalmente contra ataques DoS e roubo de dados

Os especialistas em segurança agora estão pedindo às organizações que atualizem rapidamente para uma nova versão da estrutura de registro Log4j que a Apache Foundation lançou na terça-feira, porque sua correção original para uma falha crítica de execução remota de código na ferramenta de registro não protege adequadamente contra ataques em algumas situações.

A fundação atribuiu um novo identificador de vulnerabilidade ( CVE 2021-45046 ) para o problema e lançou uma nova versão (Apache Log4j 2.16.0) da ferramenta que, segundo ela, resolve o problema DoS .

Enquanto isso, o fornecedor de segurança Praetorian, um dos primeiros a explorar a falha do Log4j na sexta-feira passada, disse hoje que a versão 2.15.0 do Log4j da semana passada também estava vulnerável a outro problema: exfiltração de dados sob certas condições.

Praetorian não compartilhou os detalhes técnicos da pesquisa e disse que a empresa havia repassado sua descoberta à Fundação Apache. “Nesse ínterim, recomendamos fortemente que os clientes atualizem para 2.16.0 o mais rápido possível“, disse o CEO da Praetorian, Nathan Sportsman, em um blog postado esta tarde.

Anthony Weems, pesquisador principal da Praetorian, diz que a descrição da Apache Foundation sobre a versão Log4j 2.15.0 que restringe pesquisas JNDI LDAP para localhost por padrão está incorreta. “Temos um desvio para essa restrição de host local que significa que quando um host é afetado por CVE-2021-45046, você pode exfiltrar [variáveis ​​de ambiente] via DNS“, diz Weems.

Os novos desenvolvimentos significam que as organizações que já baixaram o Log4j 2.15.0 para corrigir a falha original (CVE-2021-44228) agora precisarão implementar a versão 2.16.0 para mitigar o problema de DoS vinculado ao CVE-2021-4506. 

“Se alguém possui uma rede ou aplicativo e precisa corrigir o Log4j para o 2.15, precisa atualizar para o 2.16 agora“, disse Vikram Thakur, diretor técnico da Symantec, uma divisão da Broadcom Software.

Especialistas em segurança descreveram a falha do Log4j como uma das piores da história recente devido ao seu amplo escopo e facilidade de exploração. Quase todos os aplicativos Java usam a ferramenta de registro, o que significa que a vulnerabilidade está presente em quase todos os lugares em que um aplicativo Java é usado. 

“É frequentemente incluído como um gerenciador de log padrão em aplicativos Java corporativos e é comumente incluído como um componente de dependência em outros projetos Java (incluindo em mais de 470.000 outros projetos de código aberto )“, disse ShadowServer esta semana. A ferramenta de registro está presente em quase todos os ambientes de software como serviço e de provedor de serviços em nuvem, bem como em sistemas internos e voltados para a Internet. 

Uma análise da Sonatype no início desta semana mostrou mais de 28,6 milhões de downloads do Log4j nos últimos quatro meses.

Aumento da atividade de ataque

Os invasores – incluindo um número crescente de grupos de ameaças persistentes avançadas do Irã, Coreia do Norte e Turquia – têm tentado explorar a falha desde o momento em que foi divulgada pela primeira vez. A Microsoft disse na terça-feira que seus pesquisadores observaram o ator de ameaças iraniano Phosphorous adquirindo um exploit para o Log4j e fazendo modificações, presumivelmente em preparação para ataques visando a falha. Hafnium, o grupo baseado na China por trás de vários ataques de dia zero ao conjunto de falhas ProxyLogon no Exchange Server, começou a usar o Log4j para atingir a infraestrutura de virtualização, disse a Microsoft. 

Outros descreveram os agentes de ameaça visando a falha para tentar distribuir mineradores de moedas de criptomoeda, Trojans de acesso remoto, ransomware e shells da web para exploração futura.

O provedor de serviços de nuvem Edge , Fastly , que rastreia a ameaça, disse na quarta-feira que observou invasores visando a falha em grande escala. Muitos começaram a descobrir maneiras de tentar escapar das mitigações para a falha. Como exemplo, Fastly apontou para atacantes usando instruções aninhadas para tornar mais difícil para os defensores criarem regras simples para detectar um ataque. Também tem havido um número crescente de ataques em que os agentes de ameaças tentam extrair dados, como chaves de acesso da AWS, tokens de sessão da AWS e detalhes da versão do sistema operacional. Na verdade, 35% dos ataques observados por Fastly envolviam tentativas de roubo de dados.

“Os modelos aninhados usados ​​em ataques Log4j permitem que os invasores ofuscem as strings incluídas e também tentem roubar informações“, disse Mike Benjamin, vice-presidente de pesquisa de segurança da Fastly. 

A ofuscação torna mais difícil para os defensores bloquearem ou alertarem sem falsos positivos, diz ele.

“Para o roubo de informações, os defensores precisam estar atentos a quaisquer variáveis ​​de ambiente ou outras informações disponíveis para o tempo de execução Java que podem ser roubadas por um invasor”, explica Benjamin.

Fastly também descobriu que 91% dos retornos de chamada exclusivos – ou respostas de máquinas vulneráveis ​​a varreduras de invasores – apontavam para quatro sites amplamente associados a ferramentas de segurança conhecidas, às vezes usadas para fins legítimos, como o teste de caneta. 

“Testadores de penetração e pesquisadores de recompensa de bugs costumam usar essas ferramentas para fazer callbacks fora da banda”, diz Benjamin. “Eles se tornam um lugar fácil para entregar cargas úteis e testar contra serviços potencialmente vulneráveis.“

Fonte Dark Reading