0
0
Agora que a poeira se instalou tanto na temporada de férias quanto na vulnerabilidade log4j que viu muitos de nós trabalhando através dele (CVE-2021-44228), faz sentido olhar para trás e fazer um balanço de como as coisas aconteceram. Que estratégias funcionaram diante de uma das vulnerabilidades mais notáveis da última década?
Para começar, vamos olhar brevemente para a questão em si. Log4j é um utilitário de registro Java usado por quase todos os produtos, ferramentas e serviços baseados em Java na internet. Se você já viu uma página de erro em um site ou errou suas credenciais, é provável que você tenha gerado um evento processado pelo Log4j em algum momento. Injetar uma sequência especificamente trabalhada em um evento processado pelo Log4j faria com que o Log4j consultasse uma URL externa arbitrária e a carregasse como um objeto Java. Um invasor poderia então usar essa vulnerabilidade (apelidada de Log4Shell) para forçar uma vítima a baixar, instalar e executar cargas maliciosas hospedadas externamente com relativa facilidade.
Havia algumas práticas comuns em organizações que sentiam que tinham preparado ou respondido ao Log4Shell efetivamente.
Boa gestão de ativos
Organizações com sistemas abrangentes e atualizados de gerenciamento de ativos acharam mais fácil identificar sistemas vulneráveis rapidamente, avaliar o potencial “raio de explosão” da exploração bem-sucedida e quantificar seu risco global. Eles também acharam mais fácil aplicar medidas de remendos de emergência, quarentena ou monitoramento em hospedeiros vulneráveis.
Entendendo a cadeia de fornecimento de software
Com uma boa compreensão de suas inclusões, bibliotecas, dependências e cadeia geral de fornecimento de software, as organizações poderiam identificar rapidamente códigos de terceiros vulneráveis. Essa visibilidade aprimorada em sua base de código permitiu que eles relatassem a vulnerabilidade para mantedores de código a montante e pares.
Registro centralizado
No caso do Log4Shell, o registro centralizado é reconhecidamente um pouco de uma espada de dois gumes. Por um lado, ter registros de eventos enviados fora do host fornece uma medida de garantia de que um atacante astuto não poderia remover os sinais de uma exploração bem sucedida antes que um analista do SOC os visse. Por outro lado, o registro centralizado inevitavelmente fornece uma superfície de ataque mais ampla para ataques baseados em registro, como o Log4Shell.
Em equilíbrio, porém, ter uma localização central para armazenar e visualizar os registros de todos os dispositivos potencialmente impactados melhorou significativamente a velocidade e a facilidade de resposta a incidentes, fazendo com que a superfície de ataque aumentada valesse o risco.
Inteligência sólida de ameaças
As tentativas de explorar o Log4Shell foram (pelo menos inicialmente) facilmente detectáveis tanto por autômatos quanto por analistas. A capacidade de adquirir e distribuir rapidamente indicadores de compromisso (IOCs) foi vital nos dias após o anúncio da vulnerabilidade. À medida que os atacantes se tornaram mais sofisticados, implantando métodos variados de ofuscação de código, o rápido compartilhamento de novos IOCs tornou-se ainda mais crítico. Organizações que mantiveram inteligência de ameaças atualizadas saíram no topo em relação à velocidade de reação e eficácia.
Pesquisando e alertando
O registro centralizado e a boa inteligência de ameaças não seriam nada sem a ferramenta e o treinamento corretos para aproveitá-los. As organizações que implantaram soluções EDR/NDR/SIEM, juntamente com uma equipe bem treinada no console, estavam bem posicionadas para detectar e automatizar a detecção de tentativas de explorar o Log4Shell.
Filtragem de rede Egress
Apesar dos efeitos de longo alcance do Log4Shell, a mitigação da vulnerabilidade foi surpreendentemente fácil e acessível para aqueles adequadamente preparados. A técnica mais simples para garantir que um invasor não explorasse a vulnerabilidade era bloquear o tráfego HTTPS ou LDAP deixando a rede.
Bloquear a solicitação de saída não resolve a causa raiz do problema, mas impede que os invasores instalem cargas maliciosas em hosts vulneráveis. Configurada corretamente, a filtragem de rede de saída tem o bônus de registrar tentativas de exploração bloqueadas, ajudando a orientar analistas do SOC e respondentes de incidentes para sistemas impactados.
Políticas restritivas de DNS
Entrar em contato com hosts externos maliciosos é um pré-requisito para um ataque Log4Shell bem sucedido. Ao restringir a resolução de nomes de rede a recursos exclusivamente internos, as organizações poderiam bloquear algumas (mas não todas) tentativas de baixar cargas maliciosas.
Embora não seja perfeita – essa técnica defensiva pode ser subvertida pelo invasor usando endereços IP ou hospedando o objeto Java malicioso em recursos internos já comprometidos – é um método barato e surpreendentemente eficaz de tornar as coisas mais difíceis para os atacantes.
Conclusão
Log4Shell foi um excelente (se aterrorizante) estudo de caso no valor de “defesa em profundidade”. A camada de múltiplas estratégias de detecção e mitigação menos que perfeitas em toda a rede foi totalmente maior do que a soma de suas partes.
As organizações que gastaram o tempo e o esforço para entender sua infraestrutura de forma inicial através da gestão de ativos e da exploração madeireira centralizada estavam melhor posicionadas para reagir de forma rápida e abrangente a uma nova e inédita vulnerabilidade.
A capacidade de adquirir e distribuir rapidamente indicadores de compromisso internamente dentro da organização, com pares externos à organização e, em alguns casos, até mesmo concorrentes, foi vital para possibilitar uma resposta global rápida e abrangente.
Nem todo problema requer uma nova solução. Bons “olhos ligados” combinados com algumas mudanças simples nos sistemas existentes, como firewalls externos e servidores de nomes, muitas vezes deram às equipes soc a cobertura de ar necessária para corrigir sistemas com calma e metodicamente (em vez de puxar pessoas em pânico todas as noites).
O Log4Shell afetou todos nós até certo ponto, mas as organizações que tinham seus patos em uma fileira antes da vulnerabilidade ser anunciada poderiam atenuá-la de forma rápida, abrangente e metodicamente.
FONTE: HELPNET SECURITY