A crise de segurança do Log4j agravou-se esta semana, com os investigadores a descobrirem que a primeira correção para a falha crítica do Log4Shell não eliminou completamente o comportamento perigoso, os fornecedores de software lançaram atualizações repetidas e o governo dos EUA ordenou às agências federais civis que identificassem e corrigissem os sistemas vulneráveis num calendário de emergência.
A vulnerabilidade original, CVE-2021-44228, permite aos atacantes, em muitas circunstâncias, executar código remotamente através de textos especialmente criados e processados pelo Apache Log4j, um componente de registo (logging) incorporado em todo o ecossistema de software Java. A Apache Software Foundation afirmou na terça-feira que o Log4j 2.15.0, lançado para corrigir a falha inicial, não oferecia proteção completa contra determinadas configurações de ataque, o que levou a uma segunda vulnerabilidade, CVE-2021-45046, e à recomendação de migração para versões mais recentes.
Uma emergência transforma-se numa corrida contra o tempo para resolver os problemas de forma improvisada
O problema técnico é particularmente complexo porque o Log4j encontra-se frequentemente em várias camadas abaixo das aplicações que as organizações efetivamente compram e operam. Uma empresa pode não estar ciente da necessidade de implementar a biblioteca, mesmo utilizando produtos comerciais, aplicações internas ou serviços na nuvem que a contenham. Isto torna os inventários de software e a comunicação com os fornecedores tão importantes como a própria correção.
O alerta de segurança da Oracle foi revisto à medida que a empresa avaliava os seus produtos e lançava correções. O aviso contínuo da Cisco sobre os seus produtos também ilustra a dimensão do trabalho: um grande fornecedor precisa de examinar portfólios extensos, determinar quais os produtos que contêm versões vulneráveis e, em seguida, fornecer aos clientes soluções específicas para cada produto.
As distribuições Linux também tiveram de responder à falha subsequente. O aviso CVE do Ubuntu, publicado na terça-feira, documenta os pacotes e atualizações afetados pela CVE-2021-45046. A rápida sequência de divulgações significa que os administradores que aplicaram as correções antecipadamente não podem assumir que a primeira atualização resolveu o problema.
CISA transforma orientação numa diretriz federal
Na sexta-feira, a Agência de Segurança Cibernética e de Infraestruturas (CISA) emitiu uma diretiva de emergência exigindo que as agências civis federais tomassem medidas. No seu boletim de 17 de dezembro, a CISA orientou as agências para identificar os produtos afetados, aplicar as mitigações e correções fornecidas pelos fornecedores e remover o software vulnerável de serviço quando as correções não estão disponíveis.
A directiva reflecte a evidência de que a exploração não é hipotética. Os atacantes começaram a procurar sistemas expostos quase imediatamente após a divulgação pública, e as empresas de segurança relataram tentativas que vão desde a mineração de criptomoedas até à instalação de software malicioso adicional. Uma reportagem da CyberScoop sobre a directiva de emergência descreveu a preocupação do governo com o facto de a prevalência da vulnerabilidade e a facilidade de exploração criarem uma oportunidade excepcionalmente ampla para agentes criminosos e ligados a Estados.
A Cloudflare, que começou a bloquear as tentativas de exploração na semana passada, continuou a publicar orientações de mitigação à medida que a situação evolui. Os fornecedores de Internet e as empresas de segurança podem bloquear padrões de exploração conhecidos nas extremidades da rede, mas estas defesas não substituem a remoção de código vulnerável, uma vez que os atacantes podem alterar os payloads e chegar aos sistemas por caminhos que as proteções de fronteira não detetam.
A deteção continua a ser importante mesmo depois de os sistemas serem atualizados
As organizações enfrentam duas questões distintas: se ainda estão vulneráveis e se já foram comprometidas. A aplicação de patches responde apenas à primeira. Como a verificação e a exploração começaram muito rapidamente, os responsáveis pela segurança também precisam de examinar registos, ligações de saída, novos processos, ficheiros inesperados e atividades de identidade em busca de provas de que um atacante obteve acesso antes da correção.
A complexidade aumenta devido à possibilidade de um servidor explorado se tornar apenas o primeiro ponto de acesso. Uma vez que os atacantes executam o código, podem tentar o roubo de credenciais, a movimentação lateral ou mecanismos de persistência que sobrevivam à correção do Log4j. Isto significa que as equipas de resposta a incidentes não podem simplesmente encerrar uma investigação porque a biblioteca vulnerável foi atualizada.
Um relatório contemporâneo do Register descreveu a ordem da CISA como parte de um esforço mais amplo para forçar uma rápida remediação nas redes federais, enquanto as organizações do sector privado enfrentam o mesmo problema de inventário sem um único mandato central.
A crise expõe uma fragilidade estrutural no software
O Log4j tornou-se um estudo de caso sobre o risco de dependência. O software moderno é montado a partir de camadas de bibliotecas, frameworks e pacotes de código aberto, uma vez que a reutilização torna o desenvolvimento mais rápido e fiável. No entanto, as organizações carecem frequentemente de um registo completo e continuamente atualizado destes componentes. Quando uma biblioteca fundamental falha, a ausência deste inventário transforma a resposta à vulnerabilidade num exercício de pesquisa.
A lição já está a ir além do próprio Log4j. As equipas de segurança necessitam de listas de materiais de software, um rastreio de dependências mais robusto, uma divulgação mais rápida por parte dos fornecedores e a capacidade de localizar um componente em diferentes aplicações sem investigação manual. Os programadores precisam de processos para atualizar bibliotecas profundamente incorporadas sem desestabilizar os sistemas de produção.
Por ora, porém, o problema mantém-se imediato. A divulgação inicial da vulnerabilidade Log4Shell transformou-se numa campanha contínua de correção, o primeiro patch foi substituído e as agências federais estão a operar sob ordens de emergência. A característica definidora do incidente já não é apenas a gravidade de uma única vulnerabilidade. É a constatação de que uma pequena componente de infraestrutura de código aberto está presente em tantos softwares que a sua correção exige coordenação em praticamente toda a cadeia de fornecimento de tecnologia.
