CrowdStrike: os 78 minutos que viraram dias de caos

Às 04:09 UTC de 19 de julho de 2024, uma atualização de conteúdo começou a chegar a computadores Windows que usavam o Falcon, da CrowdStrike. Às 05:27, o conteúdo defeituoso já havia sido revertido. Foram 78 minutos de distribuição. A recuperação, porém, levaria muito mais tempo. Fonte 2

A Microsoft estimou que cerca de 8,5 milhões de dispositivos Windows foram afetados. Era menos de 1% desse universo, mas as máquinas estavam concentradas em organizações das quais muita gente dependia. Aeroportos, hospitais e empresas sentiram as consequências. Fonte 3

A pergunta não é apenas como um programa falhou. É como uma alteração distribuída por pouco mais de uma hora conseguiu atravessar tantas defesas e produzir dias de interrupção.

Um segurança com acesso ao núcleo

O Falcon observa atividades nos computadores de uma organização para identificar ameaças. Parte desse trabalho acontece em um nível de privilégio que um aplicativo comum não possui. Esse acesso permite enxergar comportamentos profundos do sistema; também aumenta o impacto de uma falha.

O sensor instalado recebe conteúdos de resposta rápida: configurações que ajudam a reconhecer novos padrões sem exigir uma atualização completa do programa. O Channel File 291 transportava um desses conteúdos. Apesar da extensão .sys, ele não era um novo driver. Era um arquivo interpretado por código que já estava instalado. Fonte 6

Essa distinção ajuda a entender o incidente. Uma configuração pode ter pouco tamanho e ainda assim orientar um componente capaz de interromper o sistema operacional inteiro.

Vinte e um campos. Vinte valores.

Segundo a análise de causa raiz publicada pela CrowdStrike, o modelo usado para observar determinados canais de comunicação entre programas esperava 21 campos de entrada. O código de integração, no entanto, fornecia 20 valores. Fonte 1

A incompatibilidade existia havia meses. Nos testes e nas primeiras configurações distribuídas, o último campo usava um curinga. Esse comportamento não acionava o caminho que exporia o defeito.

Em 19 de julho, uma nova configuração pediu uma correspondência específica justamente naquele campo. O interpretador tentou consultar um valor fora dos limites da entrada recebida. Como a leitura ocorreu dentro de um componente privilegiado, o Windows interrompeu a execução.

Esse é o mecanismo imediato da tela azul. Para explicar o alcance mundial, precisamos acompanhar as outras barreiras.

As barreiras que deveriam conter a falha

O relatório permite reconstruir uma sequência de oportunidades de contenção. A síntese abaixo organiza as evidências em camadas; ela é uma leitura editorial do Causa Raiz, baseada na documentação técnica. Fonte 1

1. O contrato entre as partes. O modelo esperava 21 campos, enquanto a integração fornecia 20. A divergência chegou aos clientes.
2. A proteção durante a execução. A checagem de limites não impediu a leitura inválida quando o caso específico ocorreu.
3. A validação do conteúdo. Uma falha de lógica permitiu aprovar uma configuração que o sensor não processaria com segurança.
4. O teste representativo. O cenário fatal não havia percorrido integralmente o mesmo caminho que percorreria nos computadores reais.
5. A distribuição gradual. As instâncias problemáticas alcançaram muitos sistemas sem a contenção por grupos progressivos e observação que poderia limitar o impacto.

O fato de configurações anteriores terem funcionado não demonstrava que todas as combinações futuras seriam seguras. O cenário que importava era precisamente aquele que ainda não havia exposto a incompatibilidade.

A correção existia. A máquina não a alcançava.

Retirar o conteúdo defeituoso interrompeu sua distribuição. Isso não significou reparar automaticamente todos os dispositivos que já haviam falhado.

Parte deles travava cedo demais na inicialização para buscar a correção. Em determinados ambientes, era necessário acessar a máquina em modo de recuperação e remover o arquivo afetado. Discos criptografados e dispositivos remotos tornavam a operação mais trabalhosa. Fontes 2 e 6

Aqui aparece a assimetria central do caso: a distribuição era centralizada e rápida; a recuperação podia depender de intervenção em cada computador.

Uma alteração alcança milhares de equipamentos em minutos. Para repará-los, pode ser preciso localizar pessoas, obter acesso, recuperar chaves e trabalhar em diferentes instalações. O fim dos 78 minutos de distribuição marcou o começo de uma recuperação muito maior.

Menos de 1% não significa pouco impacto

Contar computadores não basta para medir a dependência que existe em torno deles. Um dispositivo pode operar um balcão. Outro, um serviço que sustenta muitas operações ao mesmo tempo.

Nos registros enviados à SEC, a Delta informou aproximadamente 7 mil voos cancelados em cinco dias, com 1,4 milhão de clientes afetados. A companhia estimou impacto de US$ 380 milhões na receita e US$ 170 milhões em despesas operacionais adicionais, parcialmente compensados por uma redução de US$ 50 milhões em combustível. São estimativas declaradas pela Delta, e essas parcelas têm naturezas diferentes. Fonte 4

Na Inglaterra, o NHS informou interrupções nos sistemas de agendamento e prontuários da maioria das clínicas de atenção primária. O órgão também declarou não ter conhecimento de impacto no número de emergência 999. Fonte 5

A concentração do mesmo software em organizações críticas fez com que uma parcela pequena do universo Windows representasse uma parcela muito relevante das atividades cotidianas. Fonte 3

A causa raiz vai além do último erro

O gatilho técnico foi a leitura de memória fora dos limites. A escala do incidente dependeu de uma cadeia maior: validação insuficiente, cenário de teste ausente, distribuição sem contenção gradual, acesso privilegiado e dificuldade de recuperação.

As defesas não eram proporcionais ao raio de impacto.

Essa é a conclusão editorial desta investigação. Ela não é uma citação literal da CrowdStrike, nem a atribuição de toda a responsabilidade a uma única pessoa. É a síntese do que acontece quando juntamos o mecanismo documentado à forma de distribuição e às consequências.

No relatório publicado após o incidente, a CrowdStrike anunciou verificações adicionais, ampliação de testes, distribuição em canários e anéis progressivos, períodos de observação e maior controle pelos clientes. São medidas anunciadas naquele documento, não uma garantia de que outro incidente seja impossível. Fonte 1

A história deixa uma pergunta que vai além deste caso: quando um sistema recebe poder para agir em grande escala, suas barreiras e seu caminho de recuperação acompanham esse poder?