Análise técnica da Microsoft sobre o incidente da CrowdStrike

Análise técnica da pane da CrowdStrike

• O problema fundamental foi uma falha de segurança de memória no driver CSagent, especialmente uma violação de acesso por leitura fora do intervalo
• A análise foi realizada com o depurador de kernel WinDBG da Microsoft e várias extensões oferecidas gratuitamente

Função do driver CSagent.sys

• O módulo CSagent.sys está registrado como um driver de filtro de sistema de arquivos, comumente usado em agentes antimalware
• Ele é usado para receber notificações sobre operações de arquivo, como criação ou modificação de arquivos
• É usado para que produtos de segurança façam varredura sempre que um novo arquivo é salvo no disco, como em downloads de arquivos pelo navegador
• Também pode ser usado como sinal para soluções de segurança que desejam monitorar o comportamento do sistema
• A CrowdStrike explicou que parte da atualização de conteúdo foi uma mudança na lógica relacionada à criação de named pipes do sensor
• A API de driver de filtro de sistema de arquivos permite que o driver receba chamadas quando há atividade de named pipe no sistema, como criação de named pipe, possibilitando a detecção de comportamento malicioso

Diferentes módulos de driver da CrowdStrike

• A CrowdStrike carrega quatro módulos de driver: CSBoot, CSDeviceControl, CSAgent e CSFirmwareAnalysis
• Um deles recebe atualizações frequentes de controle dinâmico e de conteúdo, de acordo com a linha do tempo da revisão pós-incidente da CrowdStrike

Mudança no número de relatórios de falha relacionados ao driver da CrowdStrike

• Foi identificado o número de relatórios de falha do Windows gerados por esse erro específico de programação da CrowdStrike
• O número de dispositivos que geraram relatórios de falha é menor do que o número de dispositivos afetados que a Microsoft compartilhou em uma postagem anterior no blog
• Isso ocorre porque os relatórios de falha são amostrados e coletados apenas de clientes que optaram por enviar esses relatórios à Microsoft
• Clientes que optam por ativar o compartilhamento de dumps de falha ajudam os fornecedores de drivers e a Microsoft a identificar e corrigir problemas de qualidade e falhas

É possível implantar o Windows em um modo de alta segurança?

• O Windows pode ser bloqueado com ferramentas integradas e vem elevando continuamente seus padrões de segurança por padrão
• No Windows 11, dezenas de novos recursos de segurança são ativados por padrão
• Os recursos de segurança integrados incluem Inicialização Segura, Inicialização Medida, Integridade da Memória, lista de bloqueio de drivers vulneráveis, proteção da Autoridade de Segurança Local, Microsoft Defender Antivirus e outros
• Esses recursos de segurança fornecem camadas de proteção contra malware e tentativas de exploração nas versões mais recentes do Windows
• Empresas que seguem boas práticas, como executar usuários como padrão sem privilégios e elevar permissões apenas quando necessário, mitigam grande parte das técnicas do MITRE ATT&CK

Planos futuros

• A Microsoft trabalhará com o ecossistema para ajudar fornecedores de antimalware a modernizar sua abordagem com recursos integrados do Windows e aumentar segurança e estabilidade
• Fornecerá diretrizes, boas práticas e tecnologias para rollout seguro, tornando mais segura a aplicação de atualizações de produtos de segurança
• Reduzirá os casos em que drivers de kernel são necessários para acessar dados críticos de segurança
• Oferecerá isolamento aprimorado e proteção contra adulteração com tecnologias como VBS enclaves
• Habilitará abordagens de zero trust, como atestação de alta integridade, uma forma de determinar a postura de segurança de um dispositivo com base no estado dos recursos nativos de segurança do Windows
• O Windows anunciou seu compromisso com a linguagem de programação Rust como parte da Secure Future Initiative da Microsoft e está expandindo o suporte a Rust no kernel do Windows
• As informações desta postagem de blog são fornecidas como parte do compromisso de orientar os aprendizados e os próximos passos após o incidente da CrowdStrike

[GN⁺]

Comentários do Hacker News

• A Microsoft pretende colaborar com o ecossistema de antimalware para modernizar o software de segurança

  • Fornecer diretrizes, boas práticas e tecnologias para realizar atualizações com segurança
  • Reduzir a necessidade de drivers de kernel para acessar dados de segurança importantes
  • Listar funções executadas em modo de usuário para reduzir o que roda em modo kernel

• Parece que será preciso esperar pela análise da CrowdStrike

  • Explica por que o software de segurança historicamente rodava em modo kernel
  • A Microsoft está promovendo novas tecnologias para que fornecedores de segurança migrem para o modo de usuário
  • A CrowdStrike já roda em modo de usuário no Mac e no Linux
  • Rodar em modo de usuário também no Windows pode reduzir o risco de falhas fatais como tela azul
  • Se o Windows tivesse removido os fornecedores de segurança do modo kernel, como a Apple fez, esse problema não teria acontecido

• É notável que não haja menção ao eBPF

  • eBPF é padrão no Linux e também está disponível no Windows, mas ainda não foi adotado nos principais sistemas Windows
  • A análise estática talvez pudesse ter detectado o bug da Blue Friday, mas ela aumenta o nível de proteção em relação ao modelo atual de módulos de kernel

• Não surpreende que a própria Microsoft seja uma grande concorrente da CrowdStrike

• Isso provavelmente passou por revisão dos departamentos de marketing e jurídico

  • É importante escolher um sistema operacional/distribuição que melhore com base no que foi aprendido com o incidente

• A alternativa, em que só a Microsoft decide o que os usuários podem fazer, é pior

  • Há pessoas defendendo o totalitarismo digital

• Foi uma boa análise técnica, com o fluxo do processo de depuração e links de recursos

  • Seria bom se mais retrospectivas de depuração fossem assim

• Nem o comunicado da MS nem o da CrowdStrike explicam como esse crash passou pelo controle de qualidade

  • É difícil entender como um crash 100% reproduzível não foi detectado nas etapas iniciais do QC

• Tenho experiência com pesquisa em Control Flow Integrity (CFI/XFI)

  • Era possível fazer sandbox de módulos de kernel
  • Hoje é possível compilar o código com flags adequadas para excluir completamente erros de segurança de memória
  • É possível transformar um BSOD em uma mensagem de log educada e desativar o driver com defeito