Привет, Хабр! Меня зовут Анастасия Гаранжа, я аналитик SOC в МТС RED и разбираю много разных инцидентов ИБ. 19 июля 2024 года многие из нас проснулись и увидели новости, что Windows сломался, и все очень плохо. Новость тут же подхватили далекие от ИТ паблики. В образовавшемся шуме практически невозможно понять, что же произошло. Чтобы показать, как такой массовый сбой стал возможен, я пройду от общих моментов построения систем до конкретных нюансов сбоя.

Расскажу, почему некоторые программы загружают свои драйверы одновременно с операционной системой, кому Microsoft позволяет это делать, к чему приводят недопустимые данные в маленьком файлике и как он попадает пользователям в обход тестов и проверок. Спасет ли в такой ситуации Linux и другие подробности — под катом.

Почему нельзя пушить в прод по пятницам

О масштабах проблемы сообщили многие новостные издания — недооценить его невозможно. Под раздачу попали рекламные билборды, аэропорты, больницы и много кто еще. О последствиях и понесенных финансовых потерях нам вряд ли расскажут, поэтому я сосредоточусь на технических деталях.

В пятницу, 19 июля, в 04:09 UTC разработчик систем ИБ CrowdStrike обновил свою платформу Falcon. Компьютеры и системы, где она была установлена, начали в автоматическом режиме загружать это обновление и массово выдавать BSOD. Проблему выявили и исправили уже через час, но ошибка коснулась примерно 8,5 млн хостов и обеспечила горячие выходные множеству системных администраторов.

Официальное заявление компании и инструкции по устранению проблемы можно почитать тут, а я перейду к принципиальным моментам.

Что же такое CrowdStrike Falcon?

Falcon Platform — это экосистема ИБ-сервисов. В нее входит и EDR (Endpoint Detection and Response). Он устанавливается на компьютеры пользователей, мониторит все происходящие в системе события и сообщает в облако не только о найденных вредоносных файлах, но и о сбоях в настройках, подозрительных сетевых соединениях, сканирует уязвимости. Для такого глубокого анализа ему нужно работать на уровне ядра операционной системы.

Кто, кроме Microsoft, имеет доступ к ядру ОС

Falcon Sensor устанавливается на Windows как обычное ПО, но интегрируется в привилегированный режим (он же Kernel mode, режим супервизора). В общем виде схема Windows выглядит так:

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

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

Минус, конечно же, в том, что из-за ошибок и сбоев такого ПО падает и сама система. Это и произошло с Falcon Sensor.

Как можно официально уронить Windows

Драйверы получают доступ к привилегированному режиму, если у них есть подпись Windows Hardware Quality Labs (WHQL). Чтобы получить WHQL, разработчики тестируют драйвер на платформе Windows HCK и отправляют журналы тестов в веб-службы Windows Quality Online Services.

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

У Falcon Sensor есть два типа обновлений: Sensor Content и Rapid Response Content. Первый тип обновлений содержит новые функции, модели машинного обучения. Он проходит множество тестов и оценок, выпускается последовательно внутри компании, на ограниченную группу пользователей и уже потом на всех.

Rapid Response Content позволяет предотвращать угрозы без изменения кода сенсора. Это обновление несет поведенческие шаблоны, соответствующие конкретным угрозам. Каждый шаблон — это бинарные файлы, которые проверяются и развертываются через файлы каналов (файлы конфигурации). С ними как раз работает драйвер сенсора.

Обновление от 19 июля включало как раз такой файл канала. Когда драйвер его интерпретировал, возникла ошибка, роняющая всю систему.

Почему падал драйвер Falcon Sensor?

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

Сейчас объяснение выглядит так. Всему виной был файл конфигурации под названием C-00000291-00000000-00000032.sys, который располагался в директории Windows/System32/drivers/crowdstrike. В обновлении от 19 июля этот файл состоял из нулей. Неизвестно, почему файл оказался в таком состоянии. Возможно, разработчик скопировал не тот файл, или в процессе его перемещения между системами он затерся.

При этом в самом драйвере была инструкция по перемещению данных через указатель в область памяти, где прописан не реальный адрес, а значение 000000000000009c. То есть инструкция 0x%p указывала на память 0x%p, а адрес памяти не мог быть %s. При обращении к несуществующему адресу могла возникнуть ошибка, а вкупе с подачей на вход файла, состоящего из нулей, произошел непредвиденный поворот событий.

Проблема усугубилась тем, что у драйвера не было прописано поведение на такой случай — ему оставалось только выпасть в синий экран смерти. Тут у меня, конечно, возник вопрос, почему у драйвера есть лицензия WHQL, если он берет в работу непроверенный тип данных (нули из C-00000291*) и просто умирает, а не завершает ошибочную функцию, чтобы начать все сначала и сохранить работоспособность.

Из такого поведения драйвера и вытекает рекомендация по исправлению ошибки: загрузить «безопасный режим» и удалить проблемный файл. В «безопасном режиме» система использует только драйверы Windows, сторонние игнорируются.

Мораль: от подобных глобальных сбоев не застрахован никто

Примеров нелепых ошибок в программном обеспечении история знает много, вот несколько моих любимых:

• 21 апреля 2010 года после обновления антивирус McAfee начал удалять из Windows svchost.exe. В те времена распространилась практика маскировки вирусов под легитимные процессы системы, но антивирус ударил не того.

• 9 февраля 2012 года произошло массовое отключение облачных хостингов Azure. Ошибка заключалась в том, что сертификаты для «общения» гостевой ОС с гипервизором, выданные 29 февраля 2012 года, должны были истечь 29 февраля 2013 года. В коде генерации сертификатов был строго прописан 1 год. Дело в том, что в 2013 году такой даты не существовало. Поэтому генерация нового сертификата стала невозможной. Это привело к тому, что гостевые ОС не могли инициализировать подключение к гипервизору, а гипервизор посчитал, что произошла физическая поломка оборудования. В связи с этим гипервизоры переносили инициализацию на другие серверы, где проблема повторялась. Так последовательно из строя вышла большая часть кластеров.

• В январе 2015 года в Linux версии Steam был обнаружен баг. Ошибка проявлялась, если папка Steam была перенесена в другую директорию. После запуска Steam по старой ссылке происходило удаление всех пользовательских файлов в директории root. Причиной было то, что в скрипте запуска Steam содержалась команда rm -rf "$STEAMROOT/"*. При этом переменная STEAMROOT содержала $PWD, что в итоге распознавалось системой как rm -rf "/"*.

В общем, у любого ПО хоть раз за свой жизненный цикл были фейлы.

Превентивных мер против таких ситуаций нет. И дело тут не в Windows или Linux. ИТ-продукты настолько разнообразны, так тесно переплетаются, что учесть абсолютно все детали невозможно, а человеческий фактор — это риск, от которого не застрахуешься. Не пренебрегайте бэкапами, имейте запасные каналы связи, тестируйте обновления перед запуском в прод. Ну и, конечно же, установите антивирус на Linux :)