Log4j e a memória que sabia demais

Por Trellix · 19 de janeiro de 2022

Por Guilherme Venere, Ismael Valenzuela, Carlos Diaz, Cesar Vargas, Leandro Costantino, Juan Olle, Jose Luis Sanchez Martinez, AC3 Team

Colaboradores: Steve Povolny, Douglas McKee, Mark Bereza, Frederick House, Dileep Kumar Jallepalli

A indústria da segurança cibernética nunca descansa, e não há melhor momento do que agora para enxergar isso como uma vantagem e um catalisador para o empoderamento dos negócios.

Hoje, profissionais em todo o mundo continuam a combater a mais recente ameaça enfrentada pelas empresas, onde nenhum setor é imune. Vimos um aumento na análise e na correção da vulnerabilidade Log4Shell na plataforma de registro baseada em Java Apache Log4j por uma boa razão: o Log4j é um dos aplicativos de registro mais populares (talvez o mais popular) entre os desenvolvedores. Mas as empresas também precisam pensar além das correções, no momento em que vemos a Log4Shell mudar o que pensamos a respeito da superfície de ataque.

O potencial de proliferação de danos em larga escala e dessa vulnerabilidade é alto, por isso esse impacto deve ser levado a sério agora para que seja possível planejar e proteger melhor contra a próxima grande falha.

Embora a correção seja crítica, não se deve depender de uma correção estática ou única para garantir a segurança da infraestrutura. Em vez disso, uma abordagem sempre ativa combinando monitoramento extensivo, avaliação, varredura e análise forense deve ser implementada para fornecer a agilidade necessária contra as ameaças mais modernas de hoje.

Especificamente, nesta postagem mostramos como uma solução para terminais com recursos de varredura de memória performática pode detectar de maneira eficaz cenários de exploração ativa e complementar os recursos de segurança de rede da sua empresa para criar um novo tipo de resiliência para sua organização.

Contexto

Como todos os envolvidos no setor de segurança estão cientes, outra nova vulnerabilidade que afeta uma biblioteca amplamente utilizada foi lançada bem a tempo da temporada de festas de 2021. O CVE-2021-44228 relatou uma vulnerabilidade na biblioteca Java Log4j que afeta aplicativos e sites usando a biblioteca para realizar o registro.

A vulnerabilidade permitia que um atacante forçasse o site ou aplicativo vulnerável a carregar e executar um código Java malicioso de um local remoto não confiável. Os vetores de ataque são variados, mas o mais comum está associado ao envio de cadeias de caracteres trabalhadas pelo invasor como parte de um protocolo de rede para a máquina alvo, como por exemplo, um cabeçalho HTTP modificado enviado como parte de uma solicitação POST.

É por isso que muitos defensores estão agora concentrando seus esforços em detectar cadeias de caracteres maliciosas no tráfego de rede e reconhecer que a proatividade é fundamental para gerar resultados positivos. No entanto, as assinaturas de rede podem ser ignoradas e há relatos confirmando que os atores de ameaças estão adaptando seus ataques de rede com várias formas de ocultação para escapar da varredura da rede. A imagem abaixo mostra algumas das técnicas atuais de ocultação que foram observadas ou relatadas como relacionadas a esse ataque.

Fonte: https://github.com/mcb2Eexe/Log4j2-Obfucation

Isso não significa que as soluções de proteção de rede não sejam úteis contra esse ataque! Na verdade, o Log4j prova como é de suma importância para os defensores ser tão adaptáveis quanto os atacantes e entrar em uma nova era de segurança viva, adotando abordagem e mentalidade mais dinâmicas. As plataformas de segurança de rede fornecem uma primeira camada de defesa e devem ser usadas como parte de uma arquitetura de segurança incorporada (estratégia de tratamento de risco de segurança), reforçada por camadas adicionais de proteção, detecção, visibilidade e resposta.

As soluções modernas para terminais estão posicionadas de maneira única para complementar os recursos baseados na rede com visibilidade aprofundada e baseada em host de processos do sistema, como varredura de memória e orquestração de resposta rápida. Essa combinação resulta em uma defesa robusta contra ameaças como a Log4Shell e permite que as empresas recuperem a confiança através de segurança de ponta a ponta.

Estou vendo você: varredura de memória #FTW

A varredura de memória pode fornecer mais valor e ajudar as plataformas de segurança da rede quando uma conexão chega ao terminal depois de derrotar as camadas de ocultação. O diagrama abaixo mostra o fluxo de execução de um ataque Log4j comum baseado na Web.

Vamos descrever o que acontece:

• Etapa 1: Um atacante envia uma cadeia de caracteres criada especialmente para o servidor Web que hospeda o aplicativo vulnerável. Como constatamos, essa cadeia de caracteres pode ser ocultada para contornar as assinaturas baseadas na rede.
• Etapa 2: O aplicativo segue com a ocultação dessa cadeia de caracteres para carregá-la na memória. Uma vez carregado na memória, o aplicativo inicia uma conexão LDAP para solicitar o endereço de onde o arquivo de classe maliciosa está localizado.
• Etapa 3: O servidor LDAP controlado pelo atacante responde com a localização do arquivo de classe maliciosa, indicando o endereço URL HTTP de onde ele está hospedado.
• Etapa 4: O aplicativo vulnerável prossegue iniciando um download do arquivo de classe maliciosa.
• Etapa 5: O aplicativo vulnerável carrega e executa o arquivo de classe maliciosa da etapa 4. Nesse momento, o atacante consegue a execução de código no alvo, deixando rastros que podem fornecer visibilidade dessa atividade para o defensor. Isso pode incluir a geração de processos adicionais ou o acesso a arquivos e chaves de registro após uma exploração.

Imagine como seria se pudéssemos superar as táticas de ocultação? Acontece que você pode (e deve) fazer isso para se manter um passo à frente de ameaças como a do Log4j. Isso pode ser realizado acionando-se uma varredura de memória em algum ponto desse fluxo de execução para detectar a presença do arquivo de código malicioso. Nós teríamos uma alta probabilidade de encontrar a sequência de caracteres revelada usada na memória do processo naquele momento. Se realizássemos uma varredura da memória após o download do arquivo de classe maliciosa, esse conteúdo também estaria disponível para varredura em sua forma revelada.

Essas possibilidades fazem com que a assinatura de memória tenha bom desempenho e eficácia, dado que o tempo da detecção depende principalmente do gatilho usado para iniciar a varredura de memória.

Regras de especialistas para segurança de terminais combinadas com varredura de memória

Nossa solução permite que as organizações façam exatamente isso, fornecendo a capacidade de acionar uma varredura de memória a partir de uma regra de especialista.

Regras de especialistas são regras personalizáveis de controle de acesso que os usuários finais empregam para detectar atividades suspeitas que geralmente não são vistas por outros mecanismos de varredura. Também fornecemos regras de especialistas da comunidade mapeadas para a matriz MITRE ATT&CK através do nosso GitHub público.

Esses recursos nos permitem focar nos aplicativos vulneráveis à Log4j e identificar o momento em que estão sendo explorados. Considere a seguinte regra:

Aqui vemos uma seção definindo ATORES (dentro da seção Process {...} e ALVOS (dentro da seção Target {...}). ATORES são quaisquer processos que possam ser vulneráveis à exploração Log4j. Nesse caso, vemos JAVA.EXE para aplicativos Java autônomos e TOMCAT?.EXE para aplicativos Apache baseados na Web. Qualquer um desses processos precisa carregar tanto JAVA.DLL quanto JVM.DLL para garantir que o tempo de execução Java esteja ativo.

A seção Target inclui qualquer possível carga do ataque. Como regras de especialistas não estão focadas no tráfego de rede, precisamos nos concentrar na última etapa do fluxo de execução, que é quando a carga é executada. Gatilhos adicionais, como arquivos ou chaves de registro acessados, podem ser adicionados à medida que mais informações sobre explorações se tornam disponíveis. Também podemos incluir qualquer exclusão de comportamento válido, como mostrado no exemplo acima usando “Excluir” como parâmetro da linha de comando. Essa exclusão é algo que os clientes podem adaptar aos seus ambientes para evitar falsos positivos, criando maiores eficiências no combate a ameaças.

Essa regra de especialista será acionada quando qualquer processo ACTOR gerar qualquer uma das cargas de TARGET. É importante notar como certas nuances podem afetar resultados e falsos positivos. Veja esta linha no início da regra:

Essa instrução inicia uma varredura de memória contra o processo ACTOR que causou o acionamento da regra de especialista. Agora temos um gatilho confiável para uma varredura de memória de bom desempenho, evitando quaisquer problemas de desempenho que possam surgir de uma varredura de memória cega. Um bônus é que essa verificação é feita em um momento muito próximo da tentativa inicial de exploração, o que garante que a sequência revelada estará na memória.

Em seguida, fazemos uma varredura na memória do processo que acionou a regra de especialista, executada pelo mecanismo DAT AV. Uma vez que a sequência seja encontrada, a detecção ocorrerá no processo afetado, e a ação configurada na linha REACTION da regra de especialista será aplicada. Recomendamos que você use a ação REPORT inicialmente até que tenha resolvido quais processos você precisa monitorar.

O primeiro evento destacado acima é a regra de especialista acionada devido a uma geração de processo suspeita de JAVA.EXE, e o segundo mostra a detecção do DAT AV indicando que a memória desse processo tinha assinaturas da exploração.

Observação:

Se a detecção de regras de especialistas estivesse presente exclusivamente e NÃO o evento Java Naming and Directory Interface (JNDI)/Log4j-Exploit, isso indicaria que um programa executou processos filhos suspeitos, e os clientes seriam aconselhados a revisar o evento e melhorar a regra de especialista de maneira apropriada.

Porém, se os eventos da regra de especialista e JNDI/Log4j-Exploit forem ambos acionados para o mesmo programa, é certo que detectamos a presença do processo que está sendo explorado.

Fornecemos mais informações sobre nossa cobertura atual para a vulnerabilidade Log4j em KB95901: cobertura para execução remota de código CVE-2021-44228 do Apache Log4j. Este artigo contém links para fazer download da regra de especialista e de um EXTRA.DAT atualizado, bem como detalhes sobre como configurar o ePO para usá-los em seu ambiente.

Se você quiser implementar esta solução, nós o encorajamos a revisar as instruções na KB e na documentação associada. É altamente recomendável revisar a regra de especialista e personalizá-la para o seu ambiente para que você não esteja apenas frustrando ou respondendo a riscos ativos, mas também se adaptando dinamicamente para contar com proteção contra ameaças em evolução.

Conclusão

Para proteger um ambiente contra ataques como o Log4j, uma estratégia em camadas e incorporada, composta por segurança da rede e varreduras direcionadas de memória de terminais, permite que os defensores detectem e evitem de maneira eficaz o fluxo de execução de ataque contra sistemas vulneráveis expostos através de vetores de rede. As reações de varredura personalizada e regras de especialistas de nosso ENS são criadas para levar a você tais capacidades para que você possa aplicar contramedidas precisas contra essas ameaças emergentes e ganhar a vantagem e mais confiança para manter e expandir seus negócios.