Detalhes iniciais sobre a causa da falha do CrowdStrike CSAgent.sys
(twitter.com/patrickwardle)- A análise inicial indica que as falhas globais no Windows ocorreram em um fluxo no qual o CSAgent.sys da CrowdStrike referenciou um endereço de memória inválido
- A instrução problemática era
mov r9d, [r8], eR8continha um endereço não mapeado retirado por índice de um array de ponteiros - Os arquivos
C-00000291-...xxx.sysnão pareciam ser drivers de kernel, mas dados ofuscados lidos pelo CSAgent.sys; a CrowdStrike confirmou que eram arquivos de configuração chamados Channel Files - A CrowdStrike afirmou que
C-00000291-causou um erro lógico que levou à falha do sistema operacional, e negou a hipótese de que a causa fosse um null byte dentro do Channel File - Esta distribuição foi tratada como uma atualização de conteúdo, não como atualização de versão, e houve casos em que ela contornou o controle de staging de alguns clientes; o crash report se tornou uma pista central para a análise da causa
Fluxo da falha do CSAgent.sys
- A análise inicial foi uma análise estática baseada em engenharia reversa do CSAgent.sys da CrowdStrike e em um único crash dump
- O material foi compartilhado sem um sistema Windows ou VM, com um pedido de investigação adicional
- O CSAgent.sys foi analisado com base em um arquivo enviado ao VirusTotal: amostra no VirusTotal
- O ponto da falha era a instrução
mov r9d, [r8]R8era um endereço não mapeado- Esse valor era um endereço obtido do array de ponteiros em
RAXusando o índiceRDX(0x14 * 0x8)
- Outros arquivos
.sys, comoC-00000291-...32.sys, não pareciam ser drivers reais, mas sim dados ofuscados- Havia indícios de que o CSAgent.sys referenciava ou lia esses arquivos
- Como apagar o arquivo resolvia a falha, levantou-se a possibilidade de que o conteúdo do arquivo afetasse a falha do CSAgent.sys
- Foi acrescentado que isso poderia ser confirmado mais facilmente com depuração
- O
.zipcompartilhado incluía várias versões do CSAgent.sys, um IDB e vários arquivosC-....sys- Havia a observação de que um dos arquivos mais recentes parecia conter a “correção”
- Link compartilhado: zip no Google Drive
Channel Files e confirmações da CrowdStrike
- Kevin Beaumont escreveu que os arquivos
.sysque causaram o problema eram channel update files e que um formato incorreto fez o driver CS de nível superior falhar- Link: post de Kevin Beaumont
- A explicação técnica da CrowdStrike confirmou a mesma direção da análise inicial
- Os arquivos
C-...sysnão são drivers de kernel, mas arquivos de configuração chamados Channel Files C-00000291-disparou um erro lógico e, como resultado, ocorreu uma falha do sistema operacional por meio do CSAgent.sys- Link: explicação técnica da CrowdStrike
- Os arquivos
- Alguns suspeitaram que a causa fosse um Channel File vazio
0x0, mas a CrowdStrike negou que o problema estivesse relacionado a um null byte dentro do Channel File- Malware Utkonos apontou uma verificação segundo a qual o arquivo deveria começar com
0xaaaaaaaa: post relacionado
- Malware Utkonos apontou uma verificação segundo a qual o arquivo deveria começar com
- Foi confirmado que o channel update foi distribuído contornando o controle de staging de alguns clientes
- Alguns responsáveis de TI confirmaram que tinham configurado a política da CrowdStrike para ignorar a versão mais recente, mas que esta atualização contornou isso porque não era uma atualização de versão, e sim uma atualização de conteúdo
- Post relacionado: thread no ResetEra
- A expressão channel files também aparece várias vezes em patentes da CrowdStrike
- US11822515B2 e US11645397B2 foram citadas como exemplos
- O termo de busca é
channel file assignee:(Crowdstrike, Inc.)
Crash report e pistas sobre System Extensions do macOS
- O crash report foi um meio para entender a falha da CrowdStrike e também foi usado para revelar outro 0day no macOS
- O título da palestra relacionada na Black Hat é “The Hidden Treasure of Crash Reports?”
- Link: página da palestra na Black Hat
- Foi avaliada positivamente a decisão da Apple de abandonar kexts de terceiros e migrar para System Extensions em modo de usuário
- No entanto, foi escrito que, durante essa transição, houve problemas de kernel panic, elevação de privilégios e descarregamento de ferramentas de segurança
- O código de kernel que dá suporte às System Extensions em modo de usuário no macOS tinha muitos bugs, e houve casos em que ferramentas de segurança migradas para o modo de usuário causaram kernel panics amplos em kexts centrais da Apple
- O CVE-2019-8805 foi citado como um problema de elevação de privilégios no framework central de System Extensions do macOS
- Apresentação relacionada: Endpoint Security and Insecurity
- Devido a falhas no processamento de System Extensions, código sem privilégios ou malware pode provocar o descarregamento de ferramentas de segurança
- Como exemplo, foi escrito que, mesmo nas versões recentes do macOS, é possível encerrar o LuLu, firewall que opera como uma System Extension confiável
- Esse bug não é um problema específico do LuLu
1 comentários
Opiniões no Hacker News
Assim que vi a frase “é uma atualização de conteúdo que causa BSOD, e apagar resolve”, pensei que poderia apostar £100 que era uma combinação de dados binários corrompidos com um parser mal escrito
Venho levando computação bastante a sério há uns 10 anos, e não trabalho nada com cibersegurança, mas acho que quase todo CVE, crash, bug, degradação de desempenho e sofrimento vem do processo de desserializar dados binários de volta para estruturas de dados legíveis pela máquina
Isso acontece porque programadores humanos deixam passar casos de borda, e linguagens imperativas permitem isso. Inclui algoritmos de descompressão, leitores de contornos de fontes, parsers de imagem, vídeo e áudio, parsers de dados de jogos, parsers de XML/HTML, parsers de certificados, assinaturas e chaves do OpenSSL, até o parser de conteúdo do EDR da CrowdStrike neste caso
Eu poderia colocar mais £50 considerando uma segunda hipótese
Parece que o arquivo corrompido passou nos testes internos, ou que não havia testes internos, e também foram ignoradas as configurações individuais sobre quando aplicar atualizações. Além disso, distribuíram para o mundo todo ao mesmo tempo, sem limitar o dano, e ainda não se sabe por que a corrupção do arquivo aconteceu em primeiro lugar
Desserialização de dados não confiáveis (CWE-502) ficou em 15º lugar, enquanto o 1º foi escrita fora dos limites (CWE-787), e o 4º foi uso após liberação (CWE-416). As fraquezas que apareceram na lista todas as vezes desde 2019 estão reunidas em https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
Para referência, trabalho na área de segurança da informação há mais de 30 anos
Por outro lado, uma variante de Scheme que usei há 20 anos era funcional, mas não verificava se todos os casos estavam cobertos, e o ghc do Haskell também não tinha essa verificação ativada por padrão alguns anos atrás. Não sei se isso mudou hoje
Alguns responsáveis de TI confirmaram que, mesmo tendo configurado a política do CS para ignorar a versão mais recente, isso foi contornado porque não era uma “atualização de versão”, mas uma “atualização de conteúdo”. Se uma atualização de conteúdo pode quebrar o cliente, ela não deveria poder contornar controles de staging nem políticas
Separadamente da questão de softwares de monitoramento de endpoint baseados em rootkit, como o CS, serem realmente necessários, uma alternativa open source poderia ser poderosa para levar essa área a padrões mais éticos
Se a ferramenta central fosse open source, haveria transparência sobre exatamente o que ela faz, e o público poderia auditá-la para verificar se não há backdoors ou bugs graves. Enquanto isso, a forma de as equipes de segurança fornecerem assinaturas de malware ainda poderia ser um modelo de negócio
Do ponto de vista do usuário, não dá para ficar tranquilo achando que um rootkit de monitoramento open source foi melhor testado e desenvolvido, ou que leva meus interesses em conta. O problema é a categoria inteira de software de monitoramento. Ela não deveria existir. Empresas que usam isso não entendem segurança, não confiam nos funcionários e também não são bons lugares para trabalhar
Está em todos os dispositivos cliente do Google
Essas ferramentas oferecem proteções essenciais contra ameaças sofisticadas e de fato as detectam. Se um teste inclui máquinas Windows, meu trabalho fica 90% mais fácil quando não há EDR
Também existem EDRs open source como o OpenEDR, mas estão defasados e a qualidade da telemetria é ruim: https://github.com/ComodoSecurity/openedr. Reunir vários códigos de prova de conceito do GitHub para criar um EDR de produção é irrealista e inseguro
O próprio sensor de EDR vira alvo de ataque. Do ponto de vista do atacante, muitas vezes o EDR é o único obstáculo, então, ao torná-lo open source, aumenta o risco de atrasarem o desenvolvimento com contribuições maliciosas ou implantarem vulnerabilidades. O desenvolvimento de sensores de segurança é um ambiente extremamente hostil, em que não se pode ter certeza de quem está do outro lado
Na prática, é quase o contrário. Existem regras open source de heurística de malware, como as regras de detecção do Elastic Security: https://github.com/elastic/detection-rules. A Elastic também oferece EDR com driver de kernel e, pela minha experiência, costuma ser mais difícil de burlar. Se você criar um EDR sem driver no Windows, meu trabalho fica mais fácil
Sensores de EDR já são “auditados” por pesquisadores de segurança e atacantes. Engenharia reversa e depuração acontecem continuamente para encontrar fraquezas. Se encontrarem um problema no nível de o EDR aceitar e executar diretamente shellcode em modo kernel, é claro que isso será divulgado
É muito mais complexo do que um simples programa de consulta de hashes
É difícil entender por que isso não foi detectado na implantação de testes. Fico curioso sobre qual foi a diferença que fez o problema surgir só quando foi implantado no mundo externo
É difícil acreditar que não tenham testado antes da implantação, e as empresas também deveriam ter um ambiente de testes antes de implantar componentes de terceiros. Durante o desenvolvimento, é comum instalar pacotes e eles falharem ou causarem problemas, mas ninguém acha uma boa ideia colocar direto em produção sem testes. Não sei por que este caso seria diferente
No pipeline 1, uma atualização do código do software teria sido tratada como uma mudança importante, passando por ambientes não produtivos e testes canário antes de uma nova “versão” ser implantada globalmente
No pipeline 2, atualizações de conteúdo/canal podem ter sido tratadas de outra forma. Por esse caminho, só seriam distribuídas coisas como novas assinaturas de malware, então talvez tenham presumido que o novo arquivo fosse um arquivo de dados em formato padrão, apenas lido e não “executado”
Esse pipeline em si provavelmente foi testado no início e considerado satisfatório, mas talvez não houvesse uma etapa de teste para verificar a integridade dos arquivos de dados gerados ou, mais importante, confirmar que funcionavam sem erro quando implantados na versão mais recente do software em uso
O software agente que lê diariamente os arquivos de canal deve ter sido testado “exaustivamente” no pipeline 1 com todos os tamanhos possíveis de arquivos de dados e conteúdos simulados. Claro que arquivos de dados inválidos deveriam ser rejeitados como erro
O cenário exato aqui pode ter sido que o pipeline quebrado do segundo caminho gerou um arquivo de dados inválido de um formato incomum, e esse caso específico não foi imaginado nem testado no pipeline de desenvolvimento, teste e implantação da versão do software
Se isso estiver correto, a lição é clara. Mesmo para implantações apenas de “dados”, por mais padronizado e estável que o pipeline seja, testes antes de uma implantação em larga escala são indispensáveis. Isso aumenta custo e atraso, mas é algo a aceitar. É parecido com o motivo pelo qual as pessoas pagam por software de “segurança” em primeiro lugar
Clientes corporativos, da mesma forma, deveriam testar novos artefatos de implantação em áreas não produtivas de seus ambientes de TI ou ter uma implantação canário antes de liberá-los para toda a frota de produção
Quando a empresa tentou entrar em segurança de endpoints e detecção de anomalias de rede, vários clientes em potencial exigiam um SLA de 4 horas para diversos tipos e severidades de CVE. Ou seja, isso exigia engenheiros de segurança em plantão 24/7 e criação/implantação de definições em menos de 4 horas, sendo que essas 4 horas significavam que deveria ser possível implantar em 100% dos alvos
Escrever e distribuir uma definição de alta qualidade para um zero-day em 4 horas já é difícil; fazê-la passar por um pipeline de testes é ainda mais difícil, sem falar em escrever novos testes que de fato cubram o caso. Naquele setor, isso era considerado “normal”, então desistimos rapidamente. Não me surpreenderia se a CS estivesse trabalhando de forma parecida aqui
Ainda assim seria péssimo, mas se tiverem lançado sem teste algum, seria um nível realmente chocante de negligência
O que eu não entendo é uma parte muito menos técnica, mas mais importante: por que o raio de impacto foi tão grande
Já implantei serviços muito menos críticos com monitoramento automático e rollback, de forma muito mais lenta. Primeiro em um beta sem tráfego de clientes; se não houvesse problema, em uma pequena parte da frota; depois aumentando lentamente a porcentagem de hosts que recebiam a atualização
Com esse método, o problema teria sido interrompido imediatamente; eu achava que isso era uma prática comum
Quando você fica sabendo de um novo vírus, ele já está solto por aí, então cada minuto conta. Você não quer atrasar um dia e descobrir que seu servidor foi comprometido 20 horas antes
A expectativa provavelmente era: não quero mudanças potencialmente quebradoras, mas ainda quero as regras mais recentes de detecção de vírus. O caso de borda que escapou foi uma configuração não testada quebrar o código existente
Fonte: pura especulação, não citem isso em uma notícia
Havia muitas maneiras de evitar esse problema, ou pelo menos reduzir o risco de ele acontecer, mas, como sempre, o lucro veio antes das pessoas
É surpreendente que quase não se discuta o papel da Microsoft neste incidente. A Microsoft não é a responsável pelo bug que causou diretamente o crash, mas criou um ambiente sem incentivos — isto é, lucro e concorrência — para tornar o Windows resiliente a esse tipo de situação
A Microsoft tem, na prática, uma posição monopolista no campo da computação em estações de trabalho e, como agora se assemelha a infraestrutura, tem um dever de cuidado para garantir a segurança, a confiabilidade e os recursos do produto
Por falta de concorrência, a Microsoft largou mão da inovação no Windows, e parte disso poderia ter evitado esta falha. Por exemplo, no macOS e no Linux o CrowdStrike roda no espaço de usuário; será que o Windows não consegue oferecer recursos para que o CrowdStrike rode no espaço de usuário?
Inovações em sandboxing de aplicações não poderiam ter reduzido a necessidade do nível de controle exigido pelo CrowdStrike?
A Microsoft detém, praticamente sem concorrência, as chaves da infraestrutura computacional do mundo, e quase não é supervisionada. O Windows já representou mais de 80% da receita da Microsoft, mas agora caiu para algo em torno de 10%
Não há problema em uma empresa privada buscar dinheiro, mas se o produto é essencial para a operação de hospitais, companhias aéreas e infraestrutura crítica, ela não pode ficar obcecada apenas com assistentes de IA e anúncios para aumentar a lucratividade
A Microsoft deixou de cumprir seu dever de cuidado para com os consumidores, e vejo o CrowdStrike como um sintoma disso. O governo deveria incentivar seriamente a concorrência no mercado de desktop workspace ou então regular o produto Microsoft Windows
Uma vantagem da queda da participação do Windows na receita é que talvez a MS não continue tratando o Windows como um santuário intocável
Não uso o CrowdStrike diretamente e, até onde sei, nunca o instalei no meu sistema. No último equipamento da empresa parecia rodar algo parecido, então me corrijam se eu estiver errado
O driver da CS é instalado primeiro e não pode ser removido; provavelmente um monitor remoto detecta isso e, por ser um driver assinado, devem ter feito um esforço considerável para dificultar adulterações
Mas então esse driver carrega arquivos de dados não assinados que o usuário final pode apagar à vontade? Um usuário final também poderia adicionar arbitrariamente esse tipo de arquivo e fazer o driver se comportar de uma forma que não deveria?
Fico me perguntando o que impediria um agente malicioso de usar um arquivo de dados malicioso para causar outra falha em grande escala ou, pior, obter privilégios de kernel
Só dá para fazer isso montando o sistema de arquivos a partir de outro sistema operacional, mas normalmente o BitLocker impede isso
Os clientes do CrowdStrike têm alguma voz sobre esse tipo de atualização ser distribuída, ou simplesmente aceitam que o CrowdStrike tenha execução remota de código completa em todas as máquinas da empresa?
Espero que, pelo menos, o pessoal de autoridades certificadoras e de criptografia possa deixar esse tipo de coisa fora de seus sistemas
O fato de o CrowdStrike automatizar essa parte é justamente o núcleo do produto
Talvez nem cheguemos a ver isso. Porque podemos estar entre esses milhões
Fico curioso se alguém sabe se esses “arquivos de canal” são assinados e verificados pelo driver da CS. Se não forem, parecem uma enorme brecha que poderia levar a um rootkit em ring 0
Seriam necessárias permissões para instalar um arquivo de canal, mas, uma vez possível, ele poderia se esconder em uma parte muito mais profunda do sistema. Se um arquivo de canal pode causar uma falha de segmentação, provavelmente também pode fazer muito mais
Toda entrada que vai para algo rodando com privilégios tão altos deveria, no mínimo, passar por verificação de integridade. Isso é básico. O simples fato de ser possível apagar arquivos de canal sugere que nem sequer há um mecanismo contra adulteração