Архив метки: BSODStrike

Неограниченный прямой доступ вендора к инфраструктуре клиентов это плохо

Неограниченный прямой доступ вендора к инфраструктуре клиентов это плохо

Неограниченный прямой доступ вендора к инфраструктуре клиентов это плохо. Алексей Лукацкий продолжает не соглашаться со мной в том, что "облачность" решения CroudStrike Falcon повлияла на масштабность BSODStrike. Он приводит "безоблачный" контр-пример: бажное обновление Google Chrome заблокировало работу со встроенным менеджером паролей для ~15 млн. пользователей. Имхо, кейсы разные и по сути, и по критичности.

🔻 Облачный вендор с прямым доступом к инфре клиентов через агентов это "ужас-ужас". И в случае сбоев (что мы наблюдали), и в случае его компрометации. Он может заявлять "у нас есть возможность творить в вашей инфре любую дичь, но мы обещаем делать только то, что вы накликаете в вебгуе", но, имхо, это неубедительно. 😐

🔻 Автообновление онпрем решений без тестирования (кейс Google Chrome) это "ужас". Если автообновления можно отключить и тестировать / накатывать обновления постепенно, а вы это не делаете, то кто ж вам виноват? 😏

Смешивать и уравнивать это не стоит. 😉

No Boot - No Hacker!

No Boot - No Hacker! Обновлённый трек. Кажется кейс с инцидентом CrowdStrike BSODStrike подходит к логическому завершению. По причинам уже всё более-менее понятно. Остались только долгие судебные тяжбы клиентов с вендором. Поэтому закрываю для себя эту тему обновлённым треком, сделанным в Suno.

Добавил свою позицию, что дело не столько в проблемах конкретной компании, сколько в проблемах облачных ИБ сервисов с агентами, архитектура которых уязвима, и которым клиенты слишком доверяют. 🤷‍♂️ Замалчивать это мне не кажется правильным, нужно пытаться хоть как-то это компенсировать. Следует понимать, что сейчас был всего лишь небольшой и относительно безобидный сбой, но когда-нибудь мы увидим кейс с полномасштабной атакой злоумышленников через облачного вендора. И, как мне кажется, в настоящий момент онпрем решения имеют свои преимущества.

CrowdStrike - это успех!
Поверь мне, это так.
Защищает он лучше всех
От любых кибератак.
Проактивный подход,
Секретное оружие:
Не справится хакер,
Если ОСь не загружена!

Припев:
Синий экран отражает атаки!
No boot - No Hacker!
No boot - No Hacker!

CrowdStrike работает по лучшей из схем,
С которой не может быть никаких проблем!
На ваших хостах Falcon сенсоры. Их привилегии максимальны.
А CrowdStrike управляют ими из своих облаков. И это нормально!
(Якобы…)
Команда CrowdStrike даже ночью не спит,
Автоматом заливает вам Rapid Response Content "at operational speed".
(Когда захочет…)

И если вам кажется, что всё это как-то страшновато,
Не переживайте: CrowdStrike пропускает контент через валидатор!
(Великий ВАЛИДАТОР!)

Не работает биржа, не летают самолёты - это всё детали…
Всего лишь маленький баг в апдейтах, злодеи через вендора вас не атаковали
(Пока что…)
За полтора часа сломать 8.5 миллионов хостов - задача нелегка…
С таким не справится устаревший онпрем, для такого нужны облака…

А если серьёзно… В 22-ом CrowdStrike из России ушёл…
И, как по мне, это очень, очень, ну просто ооочень хорошо!

MP3 файл

Какие меры предлагает CrowdStrike, чтобы BSODStrike не повторился?

Какие меры предлагает CrowdStrike, чтобы BSODStrike не повторился?

Какие меры предлагает CrowdStrike, чтобы BSODStrike не повторился? Во всё том же официальном посте.

🔻 Констатируют, что обновления самого агента они не пушат. Пользователи могут обновлять агенты с задержкой версии (N-1, N-2).

🔻 Обещают лучше тестить Rapid Response Content (RRC). Ожидаемое, но малоконтролируемое бла-бла. 🤷‍♂️

🔻 Обещают дать пользователям больше контроля над раскаткой RRC. Вендорам подобных сервисов следует к этому присмотреться ❗️:

🆕 Реализуют стратегию поэтапного развертывания (ПР), начиная с канареечного.
🆕 Улучшат мониторинг производительности cенсоров и системы для управления ПР.
🆕 Предоставят пользователям гранулярный выбор когда и где обновления будут развёрнуты.
🆕 Будут выпускать RRC release notes. 😏

В общем, вольницу с обновлениями слегка прикрутят. Однако это улучшения на уровне Web-GUI. 😉 Вендор облачного сервиса продолжит сидеть агентами в инфре клиентов. Риски аналогичного сбоя и риски компрометации вендора останутся. 🤷‍♂️

Вышел официальный пост о причинах BSODStrike

Вышел официальный пост о причинах BSODStrike

Вышел официальный пост о причинах BSODStrike.

🔻 Хосты ломало обновление Rapid Response Content. Это интерпретируемый бинарь с конфигурационными данными ("поведенческими эвристиками"). Это не код и не драйвер ядра. Эти обновления инициировал сам вендор "at operational speed".

🔻 В посте масса подробностей по устройству CrowdStrike Falcon. Суть же в том, что при подготовке контента валидатор работал неправильно: "Due to a bug in the Content Validator, one of the two Template Instances passed validation despite containing problematic content data." При интерпретации контента на хосте возникала ошибка out-of-bounds memory read и BSOD.

🔻 Обновление катали 19 июля с 04:09 UTC по 05:27 UTC на Windows хосты с сенсорами версии 7.11, которые были в онлайне.

В общем, всё как в моих предыдущих постах про вендоров облачных сервисов и безусловное доверие к обновлениям контента. Вендор пушил обновление контента из облака по собственному усмотрению и умудрился ушатать хосты. 🤷‍♂️

Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обнаружения"

Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление контента обнаружения

Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обнаружения". Дальше процитирую блогпост Алексея Лукацкого про CrowdStike (весьма годный 👍):

"Да и вообще, признайтесь, кто из вас проверяет прилетающий контент обнаружения в любом из ваших средств защиты — антивирусу, EDR, IDS, WAF, NGFW, SIEM, NTA, XDR?.. Ведь никто же!"

Я бы ещё и VM сюда добавил до кучи. 😉

И это беда. Почему-то считается, что "контенту обнаружения", который зачастую представляет собой те же мутные бинари, можно слепо доверять и автоматом пробрасывать его на хосты. BSODStrike показал к чему это может привести.

Имхо, необходимо разбираться, что же это за "контент обнаружения" такой и, при любой непрозрачности, также прогонять его на тестовом скоупе. А как иначе, если они и контентом хосты ушатывают. 🤷‍♂️🤦‍♂️ А на убеждения вендоров, что у них всё "просчитано до муллиметра", вестись не следует.

Компрометация ИБ вендора облачного продукта с агентами в контексте инцидента с CrowdStrike

Компрометация ИБ вендора облачного продукта с агентами в контексте инцидента с CrowdStrike

Компрометация ИБ вендора облачного продукта с агентами в контексте инцидента с CrowdStrike. Продолжаю размышлять о преимуществах онпрема.

🔹 Взлом вендора облачного ИБ продукта с агентами - джекпот для злоумышленника. 🎰 Доступ в инфру всех клиентов в реальном времени. 😱 BSODStrike продемонстрировал насколько быстро может быть нанесён ущерб и насколько массово (8.5 млн. Windows хостов по оценке Microsoft). Это не будет просто BSOD и блокировка загрузки, тривиально исправляемые. В лучшем случае там будет слив данных и wipe/шифровальщик, а скорее будет развитие атаки и компрометация всей инфраструктуры клиентов.

🔹 Если же вендора онпрем-продукта сломают, то это только начало квеста по незаметному внедрению НДВ в обновление продукта, которое клиент должен ещё установить. И тогда злодей попробует скомпрометировать некоторых клиентов пока это всё не вскроется. Возможно ли это? Конечно. Но это будет гораздо дольше, сложнее (дороже), точечнее, а вероятность успеха будет ниже. 🤷‍♂️

Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike

Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike

Контроль над обновлением on-prem продуктов в контексте инцидента с CrowdStrike. В комментах к посту про переосмысление облачных агентов Алексей Лукацкий спрашивает: "а причем тут облачные агенты? У онпрем такого не может случиться?"

Я вижу 2 момента. Начнём с контроля над обновлением.

Если решение о функциональном обновлении компонентов продукта (включая агенты) принимает клиент и у него есть возможность протестировать новую версию, то в случае проблемы с агентом а-ля BSODStrike:

🔹 Её можно было бы обнаружить во время раскатки агентов на тестовой группе активов. 👷‍♂️

🔹 Её можно было бы переждать, если не обновляться сразу, а посмотреть недельку не всплывёт ли что-нибудь в других компаниях. 😏

Но это только если контроль над обновлением продукта со стороны клиента предусмотрен и выполняется. Если же в настройках продукта стоит галка "устанавливать все обновления автоматически" и "обновлять все агенты автоматически", то тогда здесь преимуществ онпрема не будет. 🤷‍♂️

Далее