ADG Оставить заявку
Блог Информационная безопасность 4 мин чтения

CrowdStrike: как конфигурационный файл положил 8,5 млн Windows-машин

19 июля 2024 - глобальный сбой: обновление канального файла CrowdStrike Falcon без нормального тестирования уронило критичные системы по всему миру. Разбираем механику.

Контекст момента

19 июля 2024 - некорректное обновление канального файла CrowdStrike Falcon вызвало BSOD на 8,5 млн Windows-машин по всему миру

19 июля 2024 года у множества компаний по всему миру - авиалинии, больницы, банки, ритейл, телеком - Windows-машины начали уходить в BSOD и не возвращаться. Причина оказалась обескураживающе простой: CrowdStrike выкатил обновление канального файла для своего агента Falcon, и этот файл оказался некорректным. Никакого взлома, никакой APT-группы, никакой уязвимости нулевого дня. Просто файл конфигурации без нормального тестирования.

Мы следили за происходящим в реальном времени и хотим зафиксировать механику - пока картина ещё не успела обрасти мифами.

Что именно произошло

CrowdStrike Falcon работает на уровне ядра Windows. Агент регулярно получает так называемые «канальные файлы» (channel files) - это не обновления самого агента, а конфигурационные файлы, которые управляют правилами обнаружения угроз. Обновляются они автоматически, без участия пользователя, и именно это делает продукт оперативным: новые сигнатуры и правила приходят быстро.

В канальном файле с идентификатором 291 оказалась ошибка, которую агент не смог корректно обработать. Falcon пытался прочитать файл при загрузке, падал с нарушением доступа к памяти и тянул за собой всю систему - классический BSOD с кодом 0x50 или 0x7E. Загрузиться в нормальном режиме не получалось, потому что драйвер подгружался ещё до пользовательской сессии.

Масштаб - 8,5 миллиона машин. Не потому что у CrowdStrike слабая защита, а потому что у него очень широкая инсталляционная база именно в корпоративном Enterprise-сегменте.

Где сломалась логика

Здесь нет одной точки отказа - есть несколько архитектурных допущений, которые сошлись в одном обновлении.

Первое - канальный файл не прошёл достаточного тестирования. Судя по тому, что известно, обновление контента для правил обнаружения проходило через менее строгий pipeline, чем обновления самого агента. Разница, которая на практике оказалась критичной: если баг в агенте может не дойти до прода из-за этапов QA, то баг в конфиге - дошёл.

Второе - агент не защитился от некорректного файла. Корректно написанный код должен валидировать входные данные и не позволять битому конфигу уронить весь процесс. Особенно - процесс на уровне ядра. Это не специфика CrowdStrike, это общий принцип: если твой компонент живёт в ring 0, у тебя нет права на необработанное исключение.

Третье - механизм автообновления не предусматривал возможности отката. Организации, которые использовали групповые политики или управляемые образы, оказались в ситуации, когда ни откатить файл, ни заблокировать обновление в моменте было нельзя - это не Windows Update с его галочками.

Четвёртое - восстановление требовало физического доступа. Рецепт от CrowdStrike - загрузиться в Safe Mode, зайти в C:\Windows\System32\drivers\CrowdStrike\, найти файл C-00000291*.sys и удалить его. На виртуальных машинах это ещё терпимо; на физических серверах в удалённых ЦОД или киосках без KVM - это человек с флешкой у каждой машины.

Что это означает для тех, кто занимается безопасностью инфраструктуры

Ирония ситуации в том, что никакой другой антивирус рядом с Falcon не спас бы. Это не тот класс угроз, от которых спасает многоуровневая защита. Это класс угроз, от которых спасают процессы: тестирование обновлений, кольца раскатки, возможность отложенного применения, механизмы быстрого восстановления.

Мы проводим аудит инфраструктуры и в числе прочего смотрим на то, как устроена схема обновления агентов безопасности. Этот инцидент хорошо иллюстрирует несколько вещей, которые стоит проверить прямо сейчас:

  • Контроль над автообновлением агентов. Есть ли у вас возможность заблокировать или задержать обновление контента агента - не только самого бинаря, но и конфигурационных файлов?
  • Кольцевая раскатка. Применяются ли обновления сначала к нескольким тестовым машинам, или сразу на весь парк?
  • Сценарий восстановления. Если агент безопасности ложит хост - как вы восстанавливаете машину без физического доступа? Есть ли преднастроенные WinPE-образы, доступ к гипервизору, консольный доступ к железу?
  • Зависимость критичных систем. Стоит ли агент на хостах, падение которых парализует ключевые процессы? Если да - отдельный вопрос о том, какой уровень изоляции там нужен.

Это не призыв убрать EDR с серверов. Это призыв относиться к агентам безопасности так же строго, как к любому другому системному ПО: с тестированием, с контролем версий и с планом отката.

Как обстоит дело сейчас

CrowdStrike выпустил исправленный файл в течение нескольких часов после начала инцидента. Те, у кого машины успели загрузиться до проблемного обновления или после исправленного, не пострадали. Те, кто поймал окно - восстанавливаются вручную.

Разбор первопричин со стороны CrowdStrike ещё не опубликован. Почему файл прошёл через pipeline в таком виде - картина неполная. Мы рассчитываем увидеть официальный post-mortem и посмотреть, какие именно процессные изменения будут анонсированы.

Пока же этот случай - хрестоматийный пример того, что безопасность инфраструктуры - это не только «поставить правильный продукт», но и понять, что произойдёт, когда этот продукт сам станет источником проблемы.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.