CrowdStrike 2024: Channel File 291 derruba 8,5 milhões de máquinas

01 · CONTEXTO

Um sensor em kernel e dois caminhos de atualização

Em 19 de julho de 2024, uma atualização de conteúdo do sensor Falcon, da CrowdStrike, derrubou hosts Windows. A fonte deste caso é o relatório de causa raiz (RCA) publicado pela própria empresa, complementado por seu relatório preliminar de incidente. O sensor chega ao cliente por dois caminhos: o Sensor Content, enviado junto com o sensor, e o Rapid Response Content, entregue da nuvem para reagir rápido a novas ameaças.

O Rapid Response Content é configuração, não código. Já o Sensor Content segue uma liberação em estágios, com uso interno, adotantes iniciais e só depois disponibilidade geral, e o cliente escolhe qual versão instalar. O RCA trata justamente de levar essa disciplina de estágios ao caminho rápido.

1. Engenheiros de detecção criam novas regras, e o sistema de configuração as transforma em instâncias de template.

2. Antes da publicação, o validador confere o conteúdo contra a definição do tipo de template.

3. O channel file é publicado e entregue aos sensores online.

4. No host, o sensor roda como driver de kernel: um erro nele derruba o sistema inteiro, não só o aplicativo.

02 · O INCIDENTE

Uma janela curta, uma frota inteira de Windows

A atualização defeituosa foi publicada às 04:09 UTC de 19 de julho de 2024 e revertida às 05:27 UTC. Quem estava online nessa janela e recebeu o channel file foi afetado; quem conectou depois da reversão, ou não conectou durante a janela, não foi.

Em 29 de julho, a empresa informou que cerca de 99% dos sensores Windows estavam online em comparação com antes da atualização.

03 · A CAUSA RAIZ

Vinte valores entregues, vinte e um esperados

A causa não foi um único erro, e sim a combinação de três: a definição do tipo de template falava em 21 entradas enquanto o código de integração fornecia 20, o interpretador tinha uma leitura fora dos limites latente, e nenhum teste exercitava um critério não coringa no 21º campo.

1. A definição do tipo de template dizia que ele recebia 21 campos de entrada, e o validador conferia o conteúdo contra essa definição.

2. O código de integração do sensor entregava ao interpretador só 20 valores, um a menos do que a definição prometia.

3. Nos testes e nas primeiras instâncias, o 21º campo usava coringa, então o teste não expunha o valor ausente.

4. Em 19 de julho entrou uma instância com critério não coringa no 21º campo. O validador, que assumia 21 entradas, a aprovou.

5. O interpretador tentou ler o 21º valor, que não existia: leitura fora dos limites, exceção sem tratamento e queda do sistema.

A análise do dump de memória aponta o driver csagent.sys, um driver de kernel, como o autor da leitura inválida.

É um caso clássico de contrato inconsistente: duas partes do sistema discordavam sobre o formato do dado, e cada uma passava nas verificações que se baseavam na própria suposição.

04 · POR QUE NINGUÉM VIU

Testes que passavam e confiança herdada

Os testes automatizados usavam um conjunto estático de 12 casos, e o canal de teste incluía um critério coringa no 21º campo de todas as instâncias. Por isso a leitura fora dos limites nunca foi exercitada. Entre 8 e 24 de abril de 2024, três instâncias adicionais foram implantadas e funcionaram como esperado.

Na decisão de implantar as instâncias de julho pesaram os testes feitos antes do lançamento do tipo de template, a confiança nas checagens do validador e as implantações anteriores bem-sucedidas.

05 · O QUE MUDOU

Fechar a causa e reduzir o raio de impacto

Além de fechar a causa, o RCA trata de limitar o dano de uma próxima falha. O achado é direto: cada instância de template deve ser implantada em estágios. As instâncias aprovadas no canário são promovidas a anéis cada vez mais amplos, ou revertidas se surgirem problemas, e a promoção para o anel seguinte é acompanhada de um tempo extra de observação, em que se coleta telemetria.

1. O conteúdo validado vai primeiro a um anel canário, um grupo pequeno de sensores.

2. A telemetria do canário mostra se há quedas de sistema, alta no volume de detecções falsas ou problemas de desempenho.

3. Com sinais saudáveis, o sistema promove o conteúdo. Com sinais ruins, reverte.

4. A promoção segue anel a anel até a frota completa, e cada anel acumula tempo de observação antes do próximo.

5. O cliente também ganha controle sobre onde e quando o conteúdo é implantado.

06 · LIÇÕES

O que levar para o seu desenho

A primeira lição é de disponibilidade: todo caminho que atinge a frota inteira deve ter um estágio que limite o dano antes do sinal de falha, seja código, seja configuração. A segunda é de observabilidade: promover um conteúdo só faz sentido se a telemetria do estágio anterior puder dizer que ele está saudável.

A terceira é de recuperação: reverter o conteúdo na origem não conserta, por si só, as máquinas que já carregaram o arquivo defeituoso. Um plano de recuperação de desastres precisa prever o caso em que o agente que falhou está em todos os hosts ao mesmo tempo.